|Subject:||Re: storing an explicit nonce|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
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.
|Next Message||Tom Lane||2021-09-05 17:07:26||Re: pg_dump handling of ALTER DEFAULT PRIVILEGES IN SCHEMA|
|Previous Message||Masahiko Sawada||2021-09-05 13:58:32||Re: Skipping logical replication transactions on subscriber side|