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: Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Amit Kapila <amit.kapila16@gmail.com>, 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-26T00:03:14Z
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-25 17:15:55 -0400, Stephen Frost wrote:
> > * Bruce Momjian (bruce@momjian.us) wrote:
> > > 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.
> 
> The page format for clog and that for relation data is unrelated.

Indeed they are, but that's not relevant to the thrust of this specific
debate.

Bruce is arguing that because clog is unprotected that it's not useful
to protect relation data, with regard to data integrity validation as
provided by AES-GCM using/storing tags.  I dispute this, as relation
data is primary data while clog, for all its value, is still metadata.
Yes, impacting the metadata has an impact on the primary data, but it
doesn't *change* that primary data at its core (and it's also more
likely to be detected than random bit flipping in the relation data
would be, which is possible if you're only encrypting and not providing
any integrity validation).

Thanks,

Stephen