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: Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, 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-27T18:43:52Z
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-27 13:26:11 -0400, Stephen Frost wrote:
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2021-05-27 12:49:15 -0400, Stephen Frost wrote:
> > > That's not really a reason to rule it out though and Bruce's point about
> > > having a way to get to an encrypted cluster from an unencrypted one is
> > > certainly worth consideration.  Naturally, we'd need to document
> > > everything appropriately but there isn't anything saying that we
> > > couldn't, say, have XTS in v15 without any adjustments to the page
> > > layout, accepting that there's no data integrity validation and focusing
> > > just on encryption, and then returning to the question about adding in
> > > data integrity validation for a future version, perhaps using the
> > > special area for a nonce+tag with GCM or maybe something else.  Users
> > > who wish to move to a cluster with encryption and data integrity
> > > validation would have to get there through some other means than
> > > replication, but that's going to always be the case because we have to
> > > have space to store the tag, even if we can figure out some other
> > > solution for the nonce.
> > 
> > But won't we then end up with a different set of requirements around
> > nonce assignment durability when introducing GCM support? That's not
> > actually entirely trivial to do correctly on a standby. I guess we can
> > use AES-GCM-SSIV and be ok with living with edge cases leading to nonce
> > reuse, but ...
> 
> Not sure if I'm entirely following the question

It seems like it might end up with lots of duplicated effort to go for
XTS in the short term, if we medium term then have to solve all the
issues around how to maintain efficiently and correctly nonces anyway,
because we want integrity support.


> but I would have thought the up-thread idea of generating a random
> part of the nonce for each start up and then a global counter for the
> rest, which would be written whenever the page is updated (meaning it
> wouldn't have anything to do with the LSN and would be stored in the
> special area as Robert contemplated) would work for both primaries and
> replicas.

Yea, it's not a bad approach. Particularly because it removes the need
to ensure that "global nonce counter" increments are guaranteed to be
durable.


> For one, we'd probably want to get agreement on what we'd use to
> construct the tweak, for starters.

Hm, isn't that just a pg_strong_random() and storing it encrypted?

Greetings,

Andres Freund