On 2019-Jul-27, Bruce Momjian wrote:
> I think using LSN and page number, we will _never_ reuse the IV, except
> for cases like promoting two standbys, which I think we have to document
> as an insecure practice.
Actually, why is it an insecure practice? If you promote two standbys,
then the encrypted pages are the same pages, so it's not two different
messages with the same key/IV -- they're still *one* message. And as
soon as they start getting queries, they will most likely diverge
because the LSNs of records after the promotion will (most likely) no
longer match. It takes one different WAL record length for the
"encryption histories" to diverge completely ...
You could have a sequence of post promotion events like:
# Replica 1
LSN=t+0 Operation A
LSN=t+1 Operation B
...
LSN=t+n Operation C
# Replica 2
LSN=t+0 Operation X
LSN=t+1 Operation Y
...
LSN=t+n Operation Z
If the LSN and modified page numbers of C and Z are the same
... and the net effect of Z is known (ex: setting a bunch of bytes on the row to zero)
... and you can read the encrypted pages of both replicas (ex: have access to the encrypted storage tier but not necessarily the live server)
... then you can XOR the encrypted pages to get the plain text for the bytes after operation C.
Yes, it's not likely and yes it has a lot of "if..." involved, but it is possible.
I don't think this will be an issue in practice, but it should be documented. Otherwise, it's not unreasonable for someone to expect that a promoted replica would use be using new keys for everything after each promotion.
Encryption for WAL can avoid this type of problem entirely by generating a new random salt and adding a "Use new salt XYZ for WDEK going forward" record. The two replicas would generate different salts so all subsequent encrypted WAL data would be different (even the exact same records). Unfortunately, that doesn't work for pages without a lot more complexity to keep track of which key version to use based upon the LSN.
Regards,
-- Sehrope Sarkuni
