Ants Aasma <a...@cybertec.at> wrote: > On Mon, 7 Oct 2019 at 18:02, Bruce Momjian <br...@momjian.us> wrote: > >> Well, do to encryption properly, there is the requirement of the nonce. >> If you ever rewrite a bit, you technically have to have a new nonce. >> For WAL, since it is append-only, you can use the WAL file name. For >> heap/index files, we change the LSN on every rewrite (with >> wal_log_hints=on), and we never use the same LSN for writing multiple >> relations, so LSN+page-offset is a sufficient nonce. >> >> For clog, it is not append-only, and bytes are rewritten (from zero to >> non-zero), so there would have to be a new nonce for every clog file >> write to the file system. We can store the nonce in a separate file, >> but the clog contents and nonce would have to be always synchronized or >> the file could not be properly read. Basically every file we want to >> encrypt, needs this kind of study.
> Yes. That is the reason why our current version doesn't encrypt > SLRU's. Actually there was one more problem: the AES-CBC cipher (or AES-XTS in the earlier patch version) process an encryption block of 16 bytes at a time. Thus if only a part of the block gets written (a torn page write), decryption of the block results in garbage. Unlike relations, there's nothing like full-page write for SLRU pages, so there's no way to recover from this problem. However, if the current plan is to use the CTR mode, this problem should not happen. -- Antonin Houska Web: https://www.cybertec-postgresql.com
