On Tue, Aug 6, 2019 at 10:36 AM Bruce Momjian <bruce@momjian.us> wrote:
> OK, I think you are missing something. Let me go over the details.
> First, I think we are all agreed we are using CTR for heap/index pages,
> and for WAL, because CTR allows byte granularity, it is faster, and
> might be more secure.
>
> So, to write 8k heap/index pages, we use the agreed-on LSN/page-number
> to encrypt each page. In CTR mode, we do that by creating an 8k bit
> stream, which is created in 16-byte chunks with AES by incrementing the
> counter used for each 16-byte chunk. Wee then XOR the bits with what we
> want to encrypt, and skip the LSN and CRC parts of the page.
Seems reasonable (not that I am an encryption expert).
> For WAL, we effectively create a 16MB bitstream, though we can create it
> in parts as needed. (Creating it in parts is easier in CTR mode.) The
> nonce is the segment number, but each 16-byte chunk uses a different
> counter. Therefore, even if you are encrypting the same 8k page several
> times in the WAL, the 8k page would be different because of the LSN (and
> other changes), and the bitstream you encrypt/XOR it with would be
> different because the counter would be different for that offset in the
> WAL.
But, if you encrypt the same WAL page several times, the LSN won't
change, because a WAL page doesn't have an LSN on it, and if it did,
it wouldn't be changing, because an LSN is just a position within the
WAL stream, so any given byte on any given WAL page always has the
same LSN, whatever it is.
And if the counter value changed on re-encryption, I don't see how
we'd know what counter value to use when decrypting. There's no way
for the code that is decrypting to know how many times the page got
rewritten as it was being filled.
Please correct me if I'm being stupid here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
