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. > If you keep it unencrypted in shared_buffers, you'd require WAL replay > and checkpointer to have every single key in the system. That sounds > nightmarish -- a single user can create a table, hide the key and block > WAL replay and checkpointing for the whole system. Yep, bingo! > I haven't read the whole thread, sorry about that -- maybe these points > have already been discussed. > > > Also, that assumes that we are only encrypting the WAL payload, and not > > the relation oids or other header information, which I think is a > > mistake because it will lead to information leakage. > > Well, that was part of my question. Why do you care to encrypt metadata > such as the relation OID (or really relfilenode)? Yes, I was assuming > that only the WAL payload is encrypted. Well, you would need to decide what WAL information needs to be secured. Is the fact an insert was performed on a table a security issue? Depends on your risks. My point is that almost anything you do beyond cluster-level encryption either adds complexity that is bug-prone or fragile, or adds unacceptable overhead, or leaks security information. -- 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 +