Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Fri, Jun 14, 2019 at 9:12 AM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On Thu, Jun 13, 2019 at 07:49:48PM -0400, Bruce Momjian wrote:
> >On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
> >> On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
> >> IMHO we should implement the simplest system possible, and optimize the
> >> hell out of it without sacrificing any safety/security aspects. No smart
> >> tunables, no extra GUCs to trade security for performance, nothing.
> >>
> >> Then once we have this working, we can see what the impact is, and make
> >> informed choices based on that. It's really hard to make good choices
> >> based on speculation, which is all we have at this point. And the danger
> >> is we'll end up with overly complex system with many parameters - which
> >> is pretty bad when the configuration impacts security, because regular
> >> users may not reaslise the consequences (and we'll get blamed for it).
> >>
> >> Also, in my experience the deployments that really need this sort of
> >> encryption tend to be quite valuable, and the owners will be happy with
> >> higher hardware costs to compensate for the performance impact, if it
> >> gives them the feature. So even if the performance impact is 20% (worst
> >> case estimate), I'd say that may be acceptable.
> >
> >Totally agree.
> >
> >> I personally find the idea of encrypting tablespaces rather strange.
> >> Tablespaces are meant to define hysical location for objects, but this
> >> would also use them to "mark" objects as encrypted or not. That just
> >> seems misguided and would make the life harder for many users.
> >>
> >> For example, what if I don't have any tablespaces (except for the
> >> default one), but I want to encrypt only some objects? Suddenly I have
> >> to create a tablespace, which will however cause various difficulties
> >> down the road (during pg_basebackup, etc.).
> >
> >Yes, very good point.
> >
> >> > In addition, while the 8k blocks would use a block cipher, the WAL would
> >> > likely use a stream cipher, and it will be very hard to use multiple
> >> > stream ciphers in a single WAL file.
> >> >
> >>
> >> Umm, why? Why would WAL necessarily use stream cipher instead of a block
> >> cipher with a suitable mode (say, CBC or XTS)? And even if it did use
> >> some stream cipter, why would it be hard to use multiple ciphers?
> >
> >Well, the value of stream ciphers is that you can write as many bytes as
> >you want, rather than requiring all writes to be a multiple of the block
> >size. The idea of having multiple tablespaces with different keys, and
> >switching streaming ciphers while encrypting only the part of the WAL
> >that needs it, and leaving the relfilenode unencrypted so we know which
> >keys to use, seems very complex.
> >
>
> OK, that makes sense.
>
> FWIW my assumption was that we could just add an "encrypted" flag into
> the main XLogRecord header, and then an extra part with important
> encryption-related data - the key, and the important metadata needed by
> external tools (e.g. relfilenode/block, needed by pg_waldump).
>
> Then we wouldn't need to reshuffle the WAL, I think.
>

Hmm, IIUC pg_waldump reads the main data containing the info for redo
operation of each rmgrs such as xl_heap_insert, xl_heap_update. I
wonder if we would need to doubly write the same data.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center