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.
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.
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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
