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-25T21:15:55Z
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,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Tue, May 25, 2021 at 04:29:08PM -0400, Stephen Frost wrote:
> > 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.
> 
> We already discussed that there are too many other ways to break system
> integrity that are not encrypted/integrity-checked, e.g., changes to
> clog.  Do you disagree?

We had agreed that this wasn't something that was strictly required in
the first version and I continue to agree with that.  On the other hand,
if we decide that we ultimately need to use an independent nonce and
further that we can make room in the special space for it, then it's
trivial to also include the tag and we absolutely should (or make it
optional to do so) in that case.

Thanks,

Stephen