Re: storing an explicit nonce

From: Sasasu <i(at)sasa(dot)su>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: storing an explicit nonce
Date: 2021-09-05 14:51:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

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.

Attachment Content-Type Size
OpenPGP_0x4E72AF09097DAE2E.asc application/pgp-keys 7.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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