Re: XTS cipher mode for cluster file encryption

On Fri, Oct 15, 2021 at 5:21 PM Andres Freund <andres(at)anarazel(dot)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