Re: Transparent Data Encryption (TDE) and encrypted files - Mailing list pgsql-hackers

On Mon, Oct 07, 2019 at 10:22:22AM -0400, Bruce Momjian wrote:
>On Sat, Oct  5, 2019 at 09:13:59PM +0200, Tomas Vondra wrote:
>> On Fri, Oct 04, 2019 at 08:14:44PM -0400, Bruce Momjian wrote:
>> > On Sat, Oct  5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
>> > > On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote:
>> > > > For full-cluster TDE with AES-NI-enabled, the performance impact is
>> > > > usually ~4%, so doing anything more granular doesn't seem useful.  See
>> > > > this PGCon presentation with charts:
>> > > >
>> > > >     https://www.youtube.com/watch?v=TXKoo2SNMzk#t=27m50s
>> > > >
>> > > > Having anthing more fine-grained that all-cluster didn't seem worth it.
>> > > > Using per-user keys is useful, but also much harder to implement.
>> > > >
>> > >
>> > > Not sure I follow. I thought you are asking why Oracle apparently does
>> > > not leverage AES-NI for column-level encryption (at least according to
>> > > the document I linked)? And I don't know why that's the case.
>> >
>> > No, I read it as Oracle saying that there isn't much value to per-column
>> > encryption if you have crypto hardware acceleration, because the
>> > all-cluster encryption overhead is so minor.
>> >
>>
>> So essentially the argument is - if you have hw crypto acceleration (aka
>> AES-NI), then the overhead of all-cluster encryption is so low it does
>> not make sense to bother with lowering it with column encryption.
>
>Yes, I think that is true.  Column-level encryption can be useful in
>giving different people control of the keys, but I think that feature
>should be developed at the SQL level so clients can unlock the key and
>backups include the encryption keys.
>

FWIW that's not how the column encryption (at least in Oracle works). It
uses the same encryption keys (with 2-tier key architecture), and the
keys are stored in a wallet. The user only supplies a passphrase (well,
a DBA does that, because it happens only once after the instance starts).

Not sure what exactly you mean by "SQL level" but I agree it's clearly
much higher up the stack than encryption at the block level.

>> IMO that's a good argument against column encryption (at least when used
>> to reduce overhead), although 10% still quite a bit.
>
>I think that test was a worst-case one and I think it needs to be
>optimized before we draw any conclusions.
>

What test? I was really referring to the PDF, which talks about 10%
threshold for the tablespace encryption. And in another section it says

  Internal benchmark tests and customers reported a performance impact of 4
  to 8% in end-user response time, and an increase of 1 to 5% in CPU usage.

Of course, this is not on PostgreSQL, but I'd expect to have comparable
overhead, despite architectural differences. Ultimately, even if it's 15
or 20%, the general rule is likely to remain the same, i.e. column
encryption has significantly higher overhead, and can only beat
tablespace encryption when very small fraction of columns is encrypted.


regards

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