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: 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-27T16:49:15Z
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-27 12:28:39 -0400, Robert Haas wrote:
> > All that having been said, I am pretty sure I don't fully understand
> > what any of these modes involve. I gather that XTS requires two keys,
> > but it seems like it doesn't require a nonce.
> 
> It needs a second secret, but that second secret can - as far as I
> understand it - be generated using a strong prng and encrypted with the
> "main" key, and stored in a central location.

Yes, I'm fairly confident this is the case.

> > It seems to use a "tweak" that is generated from the block number and
> > the position within the block (since an e.g. 8kB database block is
> > being encrypted as a bunch of 16-byte AES blocks) but apparently
> > there's no problem with the tweak being the same every time the block
> > is encrypted?
> 
> Right. That comes with a price however: It leaks the information that a
> block "version" is identical to an earlier version of the block. That's
> obviously better than leaking information that allows decryption like
> with the nonce reuse issue.

Right, if we simply can't solve the nonce-reuse concern then that would
be better.

> Nor does it provide integrity - which does seem like a significant issue
> going forward. Which does require storing additional per-page data...

Yeah, this is one of the reasons that I hadn't really been thrilled with
XTS- I've really been looking down the road at eventually having GCM and
having actual integrity validation included.

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.

Thanks,

Stephen