Re: storing an explicit nonce

Greetings,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2021-05-27 13:26:11 -0400, Stephen Frost wrote:
> > * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > > On 2021-05-27 12:49:15 -0400, Stephen Frost wrote:
> > > > That's not really a reason to rule it out though and Bruce's point about
> > > > having a way to get to an encrypted cluster from an unencrypted one is
> > > > certainly worth consideration. Naturally, we'd need to document
> > > > everything appropriately but there isn't anything saying that we
> > > > couldn't, say, have XTS in v15 without any adjustments to the page
> > > > layout, accepting that there's no data integrity validation and focusing
> > > > just on encryption, and then returning to the question about adding in
> > > > data integrity validation for a future version, perhaps using the
> > > > special area for a nonce+tag with GCM or maybe something else. Users
> > > > who wish to move to a cluster with encryption and data integrity
> > > > validation would have to get there through some other means than
> > > > replication, but that's going to always be the case because we have to
> > > > have space to store the tag, even if we can figure out some other
> > > > solution for the nonce.
> > >
> > > But won't we then end up with a different set of requirements around
> > > nonce assignment durability when introducing GCM support? That's not
> > > actually entirely trivial to do correctly on a standby. I guess we can
> > > use AES-GCM-SSIV and be ok with living with edge cases leading to nonce
> > > reuse, but ...
> >
> > Not sure if I'm entirely following the question
>
> It seems like it might end up with lots of duplicated effort to go for
> XTS in the short term, if we medium term then have to solve all the
> issues around how to maintain efficiently and correctly nonces anyway,
> because we want integrity support.

You and Robert both seem to be going in that direction, one which I tend
to share, while Bruce is very hard set against it from the perspective
that he doesn't view integrity as important (I disagree quite strongly
with that, even if we can't protect everything, I see it as certainly
valuable to protect the primary data) and that this approach adds
complexity (the amount of which doesn't seem to be agreed upon).

I'm also not sure how much of the effort would really be duplicated.

Were we to start with XTS, that's almost drop-in with what Bruce has
(actually, it should simplify some parts since we no longer need to deal
with making sure we always increase the LSN, etc) gives users more
flexibility in terms of getting to an encrypted cluster and solves
certain use-cases. Very little of that seems like it would be ripped
out if we were to (also) provide a GCM option.

Now, if we were to *only* provide a GCM option then maybe we wouldn't
need to think about the XTS case of having to come up with a tweak
(though that seems like a rather small amount of code) but that would
also mean we need to change the page format and we can't do any kind of
binary/page-level transistion to an encrypted cluster, like we could
with XTS.

Trying to break it down, the end-goal states look like:

GCM-only: no binary upgrade path due to having to store the tag
XTS-only: no data integrity option
GCM+XTS: binary upgrade path for XTS, data integrity with GCM

If we want both a binary upgrade path, and a data integrity option, then
it seems like the only end state which provides both is GCM+XTS, in
which case I don't think there's a lot of actual duplication.

Perhaps there's an "XTS + some other data integrity approach" option
where we could preserve the page format by stuffing information into
another fork or maybe telling users to hash their data and store that
hash as another column which would allow us to avoid implementing GCM,
but I don't see a way to avoid having XTS if we are going to provide a
binary upgrade path.

Perhaps AES-GCM-SIV would be interesting to consider in general, but
that still means we need to find space for the tag and that still
precludes a binary upgrade path.

> > but I would have thought the up-thread idea of generating a random
> > part of the nonce for each start up and then a global counter for the
> > rest, which would be written whenever the page is updated (meaning it
> > wouldn't have anything to do with the LSN and would be stored in the
> > special area as Robert contemplated) would work for both primaries and
> > replicas.
>
> Yea, it's not a bad approach. Particularly because it removes the need
> to ensure that "global nonce counter" increments are guaranteed to be
> durable.

Right.

> > For one, we'd probably want to get agreement on what we'd use to
> > construct the tweak, for starters.
>
> Hm, isn't that just a pg_strong_random() and storing it encrypted?

Perhaps it is, but at least in some other cases it's generated based on
sector and block (which maybe could be relfilenode and block for us?):

https://medium.com/asecuritysite-when-bob-met-alice/who-needs-a-tweak-meet-full-disk-encryption-437e720879ac

Thanks,

Stephen