Horton

Re: storing an explicit nonce

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Bruce Momjian <bruce@momjian.us>, Ants Aasma <ants@cybertec.at>, Sasasu <i@sasa.su>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-10-07T19:00:21Z
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, Oct 7, 2021 at 12:57 PM Stephen Frost <sfrost@snowman.net> wrote:
> Yes, for integrity verification (also known as 'authenticated
> encryption') we'd definitely need to store a larger nonce value.  In the
> very, very long term, I think it'd be great to have that, and the patch
> proposed on this thread seems really cool as a way to get us there.

OK. I'm not sure why that has to be relegated to the very, very long
term, but I'm really very happy to hear that you think the approach is
cool.

> Having TDE, even without authenticated encryption, is certainly
> valuable.  Reducing the amount of engineering required to get there is
> worthwhile.  Implementing TDE w/ XTS or similar, provided we do agree
> that we can do so with an IV that we don't need to find additional space
> for, would avoid that page-level format change.  I agree we should do
> some research to make sure we at least have a reasonable answer to that
> question.  I've spent a bit of time on that and haven't gotten to a sure
> answer one way or the other as yet, but will continue to look.

I mean, I feel like this meeting that Bruce was talking about was
perhaps making decisions in the wrong order. We have to decide which
encryption mode is secure enough for our needs FIRST, and then AFTER
that we can decide whether we need to store a nonce in the page. Now
if it turns out that we can do either with or without a nonce in the
page, then I'm just as happy as anyone else to start with the method
that works without a nonce in the page, because like you say, that's
less work. But unless we've established that such a method is actually
going to survive scrutiny by smart cryptographers, we can't really
decide that storing the nonce is off the table. And it doesn't seem
like we've established that yet.

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