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

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.

> I mean, we'd probably want/need to start new streams for each WAL
> segment anyway, so that tools can read and process each WAL segment
> independently. So we wouldn't get very long streams anyway.

Well, 16MB quite a long stream, considering that AES256 is 128-bits or
16 bytes.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +