Re: storing an explicit nonce

Hi,

On 2021-05-27 15:22:21 -0400, Stephen Frost wrote:
> 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

Why would GCM + XTS make sense? Especially if we were to go with
AES-GCM-SIV or something, drastically reducing the danger of nonce
reuse?

And I don't think there's an easy way to do both using openssl, without
double encrypting, which we'd obviously not want for performance
reasons. And I don't think we'd want to implement either ourselves -
leaving other dangers aside, I don't think we want to do the
optimization work necessary to get good performance.


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

I honestly feel that Bruce's point about trying to shoot for the moon,
and thus not getting the basic feature done, applies much more to the
binary upgrade path than anything else. I think we should just stop
aiming for that for now. If we later want to add code that goes through
the cluster to ensure that there's enough space on each page for
integrity data, to provide a migration path, fine. But we shouldn't make
the binary upgrade path for TED a hard requirement.


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

My understanding is that you'd use
    tweak_secret + block_offset
or
    someop(tweak_secret, relfilenode) block_offset

to generate the actual per-block (in the 8192 byte, not 128bit sense) tweak.

Greetings,

Andres Freund