Horton

Re: storing an explicit nonce

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Stephen Frost <sfrost@snowman.net>
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:04:56Z
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 Tue, May 25, 2021 at 04:29:08PM -0400, Stephen Frost wrote:
> 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.

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?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.