Horton

Re: storing an explicit nonce

Sasasu <i@sasa.su>

View thread
From: Sasasu <i@sasa.su>
To: pgsql-hackers@lists.postgresql.org
Date: 2021-09-05T14:51:42Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Rethink method for assigning OIDs to the template0 and postgres DBs.

  2. pg_upgrade: Preserve database OIDs.

  3. pg_upgrade: Preserve relfilenodes and tablespace OIDs.

  4. Fix for new Boolean node

  5. Improve error handling of HMAC computations

  6. Add macro RelationIsPermanent() to report relation permanence

  7. Enhance nbtree index tuple deletion.

Attachments

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.