> On Tue, Aug 6, 2019 at 10:36 AM Bruce Momjian <bruce@momjian.us> wrote:
> 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.
In my implementation (I haven't checked whether Masahiko Sawada changed this in his patch) I avoided repeated encryption of different data using the same key+IV by omitting the unused part of the WAL page from encryption. Already written records can be encrypted repeatedly because they do not change.
Yeah my patch doesn't change this part. IV for WAL encryption consists of the segment file number, page offset within segment file and the counter for CTR cipher mode.
