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

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.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services