On Thu, May 27, 2021 at 3:22 PM Stephen Frost <sfr...@snowman.net> wrote: > 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 > > 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. > > Perhaps there's an "XTS + some other data integrity approach" option > where we could preserve the page format by stuffing information into > another fork or maybe telling users to hash their data and store that > hash as another column which would allow us to avoid implementing GCM, > but I don't see a way to avoid having XTS if we are going to provide a > binary upgrade path. > > Perhaps AES-GCM-SIV would be interesting to consider in general, but > that still means we need to find space for the tag and that still > precludes a binary upgrade path.
Anything that decouples features without otherwise losing ground is a win. If there are things A and B, such that A does encryption and B does integrity validation, and A and B can be turned on and off independently of each other, that is better than some otherwise-comparable C that provides both features. But I'm going to have to defer to you and Andres and whoever else on whether that's true for any encryption methods/modes in particular. -- Robert Haas EDB: http://www.enterprisedb.com
