On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > Uh, well, you have the WAL record, and you want to write it to an 8k
> > > page. You have to read the 8k page from disk into shared buffers, and
> > > you have to decrypt the 8k page to do that, right? We aren't going to
> > > store 8k pages encrypted in shared buffers, right?
> >
> > Oh, is that the idea? I was kinda assuming that the data was kept
> > as-stored in shared buffers, ie. it would be decrypted on access, not on
> > read from disk. The system seems very prone to leakage if you have it
> > decrypted in shared memory.
>
> Well, the overhead of decrypting on every access will make the slowdown
> huge, and I don't know what security value that would have. I am not
> sure what security value TDE itself has, but I think encrypting shared
> buffer contents has even less.
Sorry for the delay --- here is some benchmark info:
https://www.postgresql.org/message-id/4723a402-b14f-4994-2de9-d85b55a56b7f%40cybertec.at
as far as benchmarking is concerned: i did a quick test yesterday (not
with the final AES implementation yet) and i got pretty good results.
with a reasonably well cached database in a typical application I expect
to loose around 10-20%. if everything fits in memory there is 0 loss of
course. the worst I got with the standard AES (no hardware support used
yet) I lost around 45% or so. but this requires a value as low as 32 MB
of shared buffers or so.
Notice the 0% overhead if everything fits in RAM, meaning it is not
decrypting on RAM access. If it is 10-20% for a "reasonably well cached
database", I am sure it will be 10x that for decrypting on RAM access.
--
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 +
