Re: storing an explicit nonce

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@anarazel.de>, 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-27T19:54:12Z
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.

On Thu, May 27, 2021 at 3:22 PM Stephen Frost <sfrost@snowman.net> wrote:
> Trying to break it down, the end-goal states look like:
>
> GCM-only: no binary upgrade path due to having to store the tag
> XTS-only: no data integrity option
> GCM+XTS: binary upgrade path for XTS, data integrity with GCM
>
> If we want both a binary upgrade path, and a data integrity option, then
> it seems like the only end state which provides both is GCM+XTS, in
> which case I don't think there's a lot of actual duplication.
>
> Perhaps there's an "XTS + some other data integrity approach" option
> where we could preserve the page format by stuffing information into
> another fork or maybe telling users to hash their data and store that
> hash as another column which would allow us to avoid implementing GCM,
> but I don't see a way to avoid having XTS if we are going to provide a
> binary upgrade path.
>
> Perhaps AES-GCM-SIV would be interesting to consider in general, but
> that still means we need to find space for the tag and that still
> precludes a binary upgrade path.

Anything that decouples features without otherwise losing ground is a
win. If there are things A and B, such that A does encryption and B
does integrity validation, and A and B can be turned on and off
independently of each other, that is better than some
otherwise-comparable C that provides both features.

But I'm going to have to defer to you and Andres and whoever else on
whether that's true for any encryption methods/modes in particular.

-- 
Robert Haas
EDB: http://www.enterprisedb.com