Horton

Re: storing an explicit nonce

Stephen Frost <sfrost@snowman.net>

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

On Tue, May 25, 2021 at 14:56 Bruce Momjian <bruce@momjian.us> wrote:

> On Tue, May 25, 2021 at 02:25:21PM -0400, Robert Haas wrote:
> > One question here is whether we're comfortable saying that the nonce
> > is entirely constant. I wasn't sure about that. It seems possible to
> > me that different encryption algorithms might want nonces of different
> > sizes, either now or in the future. I am not a cryptographer, but that
> > seemed like a bit of a limiting assumption. So Bharath and I decided
> > to make the POC cater to a fully variable-size nonce rather than
> > zero-or-some-constant. However, if the consensus is that
> > zero-or-some-constant is better, fair enough! The patch can certainly
> > be adjusted to cater to work that way.
>
> A 16-byte nonce is sufficient for AES and I doubt we will need anything
> stronger than AES256 anytime soon.  Making the nonce variable length
> seems it is just adding complexity for little purpose.


I’d like to review this more and make sure using the special space is
possible but if it is then it opens up a huge new possibility that we could
use it for both the nonce AND an appropriately sized tag, giving us
integrity along with encryption which would be a very significant
additional feature.  I’d considered using a fork instead but having it on
the page would be far better.

I’ll also note that we could consider possibly even find an alternative use
for the space used for checksums, or leave them as they are today, though
they’d be redundant at that point to the tag.

Lastly, if the special space is actually able to be variable in size and we
could, say, store a flag in pg_class which tells us what’s in the special
space, then we could possibly give users the option of including the tag on
each page, or the choice of the size of tag, or possibly for other
interesting things in the future outside of encryption and data integrity.

Overall, I’m quite interested in the idea of making the special space able
to be variable. I do accept that will make it so it’s not possible to do
things like have physical replication between an unencrypted cluster and an
encrypted one, but the advantages seem worthwhile and users would still be
able to leverage logical replication to perform such a migration with
relatively little downtime.

Thanks!

Stephen

>