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