On Fri, Oct 4, 2019 at 11:48:19PM +0200, Tomas Vondra wrote:
> On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote:
> > > Oracle also has a handy "TDE best practices" document [2], which says
> > > when to use column-level encryption - let me quote a couple of points:
> > >
> > > * Location of sensitive information is known
> > >
> > > * Less than 5% of all application columns are encryption candidates
> > >
> > > * Encryption candidates are not foreign-key columns
> > >
> > > * Indexes over encryption candidates are normal B-tree indexes (this
> > > also means no support for indexes on expressions, and likely partial
> > > indexes)
> > >
> > > * No support from hardware crypto acceleration.
> >
> > Aren't all modern systems going to have hardware crypto acceleration,
> > i.e., AES-NI CPU extensions. Does that mean there is no value of
> > partial encryption on such systems? Looking at the overhead numbers I
> > have seen for AES-NI-enabled systems, I believe it.
> >
>
>
> That's a good question, I don't know the answer. You're right most
> systems have CPUs with AES-NI these days, and I'm not sure why the
> column encryption does not leverage that.
>
> Maybe it's because column encryption has to encrypt/decrypt much smaller
> chunks of data, and AES-NI is not efficient for that? I don't know.
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.
--
Bruce Momjian <br...@momjian.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 +
