Re: storing an explicit nonce

Greetings,

* Andres Freund (andres(at)anarazel(dot)de) wrote:
> On 2021-05-27 16:09:13 -0400, Stephen Frost wrote:
> > * 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
> > >
> > [...]
> > > 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..
>
> Ah, that makes more sense ;). So the end goal states are the different
> paths we could take?

The end goals are different possible things we could provide support
for, not in one cluster, but in one build of PG. That is, we could
add support in v15 (or whatever) for:

initdb --encryption-type=AES-XTS

and then in v16 add support for:

initdb --encryption-type=AES-GCM (or AES-GCM-SIV, whatever)

while keeping support for AES-XTS.

Users who just want encryption could go do a binary upgrade of some kind
to a cluster which has AES-XTS encryption, but to get GCM they'd have to
initialize a new cluster and migrate data to it using logical
replication or pg_dump/restore.

There's also been requests for other possible encryption options, so I
don't think these would even be the only options eventually, though I do
think we'd probably have them broken down into "just encryption" or
"encryption + data integrity" with the same resulting limitations
regarding the ability to do binary upgrades.

> > 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.
>
> I think it has to include the relfilenode as a minimum. It'd not be
> great if you could identify equivalent blocks in different tables. It
> might even be worth complicating createdb() a bit and including the
> dboid as well.

At this point I'm wondering if it's just:

dboid/relfilenode:block-offset

and then we hash it to whatever size EVP_CIPHER_iv_length(AES-XTS-128)
(or -256, whatever we're using based on what was passed to initdb)
returns.

Thanks,

Stephen