| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Joe Conway <mail(at)joeconway(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
| Date: | 2019-07-05 21:07:21 |
| Message-ID: | 20190705210721.73pnvce4wpqzaxu4@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 <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 +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Doc comments form | 2019-07-05 21:20:07 | Postgres 11: Table Partitioning and Primary Keys |
| Previous Message | Thomas Munro | 2019-07-05 21:02:21 | Re: using explicit_bzero |