Horton

Re: storing an explicit nonce

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Date: 2021-05-25T23:33:13Z
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.

Hi,

On 2021-05-25 17:04:50 -0400, Stephen Frost wrote:
> I do think it's reasonable to consider having hint bits not included in
> the encrypted part of the page and therefore remove the need to produce
> a new nonce for each hint bit change.

Huh. How are you going to track that efficiently? Do you want to mask
them out before writing? As far as I understand you can't just
re-encrypt a page with the same nonce, but different contents, without
leaking information that you can't have leaked, even if the differences
are not of a secret nature.

I don't think hint bits are the only way to end up with needing to
re-write a page with slightly different content, but the same LSN,
during recovery, after a crash.

I think it's just not going to fly to use LSNs as nonces, and that it's
not worth butchering all kinds of aspect of the system to make it appear
to work.

Greetings,

Andres Freund