Ants Aasma <ants@cybertec.at> wrote:
> On Mon, 7 Oct 2019 at 18:02, Bruce Momjian <bruce@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
