Re: storing an explicit nonce

Hi, community,

It looks like we are still considering AES-CBC, AES-XTS, and 
AES-GCM(-SIV). I want to say something that we don't think about.

For AES-CBC, the IV should be not predictable. I think LSN or HASH(LSN, 
block number or something) is predictable. There are many CVE related to 
AES-CBC with a predictable IV.

	https://cwe.mitre.org/data/definitions/329.html

For AES-XTS, use block number or any fixed variable as tweak still has 
weaknesses similar to IV reuse (in CBC not GCM). the attacker can 
decrypt one block if he knows a kind of plaintext of this block.
In Luks/BitLocker/HardwareBasedSolution, the physical location is not 
available to the user. filesystem running in kernel space. and they not 
do encrypt when filesystem allocating a data block.
But in PostgreSQL, the attacker can capture an encrypted 'ALL-ZERO' page 
in `mdextend`, with this, the attacker can decode the ciphertext of all 
following data in this block.

For AES-GCM, a predictable IV is fine. I think we can decrypt and 
re-encrypt the user data in pg_upgrade. this will allows us to use 
relfile oid + block number as nonce.