Horton

Re: storing an explicit nonce

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
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:58:11Z
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.

Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> 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.

The simple thought I had was masking them out, yes.  No, you can't
re-encrypt a different page with the same nonce.  (Re-encrypting the
exact same page with the same nonce, however, just yields the same
cryptotext and therefore is fine).

> 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.

Any other cases would have to be addressed if we were to use LSNs, of
course.

> 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.

I do agree that we'd want to avoid "butchering all kinds of aspects of
the system" if possible. :)

Thanks!

Stephen