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.
IMO that's a good argument against column encryption (at least when used
to reduce overhead), although 10% still quite a bit.
But I'm not sure it's what the document is saying. I'm sure if they
could, they'd use AES-NI even for column encryption, to make it more
efficient. Because why wouldn't you do that? But the doc explicitly
says:
Hardware cryptographic acceleration for TDE column encryption is
not supported.
So there has to be a reason why that's not supported. Either there's
something that prevents this mode from using AES-NI at all, or it simply
can't be sped-up.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services