Re: XTS cipher mode for cluster file encryption

On Mon, Oct 18, 2021 at 12:37:39PM -0400, Robert Haas wrote:
> > 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

Uh, our TODO has this list:

    Desirability -> Design -> Implement -> Test -> Review -> Commit

I think we have to agree on Desirability and Design before anyone starts
work since it is more likely a patch will be rejected without this.

> 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 don't see anyone saying we have agreed on anything, but I do hear
people say they are willing to work on some things, and not others.

> 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.

The design is to have a heap/index key and a WAL key.  You create a
binary replica that uses a different heap/index key but the same WAL
key, switch-over to it, and then change the WAL key.

`> 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

I don't think that would happen, but I do think patch size, code
maintenance, and upgradability would be reasonable considerations.

> 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?

Yes, we should start on things we know we need, but we will have to have
these discussions until we have desirability and design most people
agree on.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.