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.
OpenPGP_0x4E72AF09097DAE2E.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
