Hi,
On 2021-05-27 16:09:13 -0400, Stephen Frost wrote:
> * Andres Freund (andres@anarazel.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?
> 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.
Greetings,
Andres Freund