On Fri, Oct 15, 2021 at 5:21 PM Andres Freund <and...@anarazel.de> wrote: > I don't find that line of argument *that* convincing. The reason XTS is the > de-facto standard is that for generic block layer encryption is that you can't > add additional data for each block without very significant overhead > (basically needing journaling to ensure that the data doesn't get out of > sync). But we don't really face the same situation - we *can* add additional > data.
Yes. The downside is that there is some code complexity, and also some runtime overhead even for cases that don't use encryption, because some things that now are compile time constants might need to be computed at runtime. That can probably be made pretty small, though. > With something like AES-GCM-SIV we can use the additional data to get IV reuse > resistance *and* authentication. And while perhaps we are ok with the IV reuse > guarantees XTS has, it seems pretty clear that we'll want want guaranteed > authenticity at some point. And then we'll need extra data anyway. > > Thus, to me, it doesn't seem worth going down the XTS route, just to > temporarily save a bit of implementation effort. We'll have to endure that > pain anyway. I agree up to a point, but I do also kind of feel like we should be leaving it up to whoever is working on an implementation to decide what they want to implement. I don't particularly like this discussion where it feels like people are trying to tell other people what they have to do because "the community has decided X." It's pretty clear that there are multiple opinions here, and I don't really see any of them to be without merit, nor do I see why Bruce or Stephen or you or anyone else should get to say "what the community has decided" in the absence of a clear consensus. I do really like the idea of using AES-GCM-SIV not because I know anything about it, but because the integrity checking seems cool, and storing the nonce seems like it would improve security. However, based on what I know now, I would not vote to reject an XTS-based patch and, as Stephen and Bruce have said, maybe with the right design it permits upgrades from non-encrypted clusters to encrypted clusters. I'm actually kind of doubtful about that, because that seems to require some pretty specific and somewhat painful implementation decisions. For example, I think if your solution for rotating keys is to shut down the standby, re-encrypt it with a new key, start it up again, and fail over to it, then you probably ever can't do key rotation in any other way. The keys now have to be non-WAL-logged so that the standby can be different, which means you can't add a new key on the master and run around re-encrypting everything with it, WAL-logging those changes as you go. Now I realize that implementing that is really challenging anyway so maybe some people wouldn't like to go that way, but then maybe other people would. Another thing you probably can't do in this model is encrypt different parts of the database with different keys, because how would you keep track of that? Certainly not in the system catalogs, if none of that can show up in the WAL stream. But, you know, still: if somebody showed up with a fully-working XTS patch with everything in good working order, I don't see that we have enough evidence to reject it just because it's XTS. And I would hope that the people favoring XTS would not vote to reject a fully working GCM patch just because it's GCM. I think what we ought to be doing at this point is combining our efforts to try to get some things committed which make future work in this area committed - like that patch to preserve relfilenode and database OID, or maybe some patches to drive all of our I/O through a smaller number of code paths instead of having every different type of temporary file we write reinvent the wheel. These discussions about what encryption type we ought to use are useful for ruling out options that we know are bad, but beyond that I'm not sure they have much value. AES in any mode could seem like a much less safe choice by the time we get a committed feature here than it does today - even if somehow that were to happen for v15. I expect there are people out there trying to break it even as I write these words, and it seems likely that they will eventually succeed, but as to when, who can say? -- Robert Haas EDB: http://www.enterprisedb.com
