Re: storing an explicit nonce

Greetings,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> 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?

You can't get to a GCM-based solution without changing the page format
and therefore you can't get there using streaming replication or a
pg_upgrade that does an encrypt step along with the copy.

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

Errrr, clearly a misunderstanding here- what I'm suggesting is that we'd
have initdb options where someone could initdb and say they want XTS, OR
they could initdb and say they want AES-GCM (or maybe AES-GCM-SIV). I'm
not talking about doing both in the cluster at the same time..

Or, with XTS, we could have an option to pg_basebackup + encrypt into
XTS to build an encrypted replica from an unencrypted cluster. There
isn't any way we could do that with GCM though since we wouldn't have
any place to put the tag.

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

Ok, that's a pretty clear fundamental disagreement between you and
Bruce. For my 2c, I tend to agree with you that the binary upgrade path
isn't that critical.

If we agree to forgo the binary upgrade requirement and are willing to
accept Robert's approach to use the special area for the nonce+tag, or
similar, then we could perhaps avoid the work of supporting XTS.

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

The above article, at least, suggested encrypting the sector number
using the second key and then multiplying that times 2^(block number),
where those blocks were actually AES 128bit blocks. The article further
claims that this is what's used in things like Bitlocker, TrueCrypt,
VeraCrypt and OpenSSL.

While the documentation isn't super clear, I'm taking that to mean that
when you actually use EVP_aes_128_xts() in OpenSSL, and you provide it
with a 256-bit key (twice the size of the AES key length function), and
you give it a 'tweak', that what you would actually be passing in would
be the "sector number" in the above method, or for us perhaps it would
be relfilenode+block number, or maybe just block number but it seems
like it'd be better to include the relfilenode to me.

OpenSSL docs:

https://www.openssl.org/docs/man1.1.1/man3/EVP_aes_256_cbc.html

Naturally, we would implement testing and use the NIST AES-XTS test
vectors to verify that we're getting the correct results from OpenSSL
based on this understanding. Still leaves us with the question of what
exactly we should pass into OpenSSL as the 'tweak', if it should be the
block offset inside the file only, or the block offset + relfilenode, or
something else.

Thanks,

Stephen