On Fri, Jul 5, 2019 at 03:46:28PM -0400, Alvaro Herrera wrote: > On 2019-Jul-05, Bruce Momjian wrote: > > > What people really want with more-granular-than-cluster encryption is > > the ability to supply their passphrase key _when_ they want to access > > their data, and then leave and be sure their data is secure from > > decryption. That will not be possible since the WAL will be encrypted > > and any replay of it will need their passphrase key to unlock it, or the > > entire system will be unrecoverable. > > I'm not sure I understand why WAL replay needs the passphrase to work. > Why isn't the data saved in WAL already encrypted, which can be applied > as raw bytes to each data block, without needing to decrypt anything? > Only if somebody wants to interpret the bytes they need the passphrase, > no?
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? If you did want to do that, or wanted to write them to disk without decrypting the 8k page, it still would not work since AES is a 16-byte encryption cipher. I don't think we can break 8k pages up into 16-byte chunks and be sure we can just place data into those 16-byte boundaries. 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. You can use AES in stream cipher mode, but then the ordering of the encryption is critical and you can't move 16-byte chunks around --- they have to be decrypted in their encrypted order. -- 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 +