Re: storing an explicit nonce

Greetings,

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Oct 7, 2021 at 12:57 PM Stephen Frost <sfrost(at)snowman(dot)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.

Folks are shy about a page format change and I get that.

> > 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.

Part of the meeting was specifically about "why are we doing this?" and
there were a few different answers- first and foremost was "because
people are asking for it", from which followed that, yes, in many cases
it's to satisfy an audit or similar requirement which any of the
proposed methods would address. There was further discussion that we
could address *more* cases by providing something better, but the page
format changes were weighed against that and the general consensus was
that we should attack the simpler problem first and, potentially, gain
a solution for 90% of the folks asking for it, and then later see if
there's enough interest and desire to attack the remaining 10%.

As such, it's just not so simple as "what is 'secure enough'" because it
depends on who you're talking to. Based on the collective discussion at
the meeting, XTS is 'secure enough' for the needs of probably 90% of
those asking, while the other 10% want better (an AEAD method such as
GCM or GCM-SIV). Therefore, what should we do? Spend all of the extra
resources and engineering effort to address the 10% and maybe not get
anything because of the level of difficulty, or go the simpler route
first and get the 90%? Through that lense, the choice seemed reasonably
clear, at least to me, hence why I agreed that we should work on an XTS
based approach first.

(Admittedly, the overall discussion wasn't quite as specific as XTS vs.
GCM-SIV, but the gist was "page format change" vs. "no page format
change" and that seems to equate, based on this subsequent discussion
to the choice between XTS and GCM/GCM-SIV.)

Thanks!

Stephen