On Thu, May 27, 2021 at 12:01 PM Andres Freund <andres@anarazel.de> wrote:
> What prevents us from using something like XTS? I'm not saying that that
> is the right approach, due to the fact that it leaks information about a
> block being the same as an earlier version of the same block. But right
> now we are talking about using CTR without addressing the weaknesses CTR
> has, where a failure to increase the nonce is fatal (the code even
> documents known cases where that could happen!), and where there's no
> error propagation within a block.
I spent some time this morning reading up on XTS in general and also
on previous discussions on this list on the list. It seems like XTS is
considered state-of-the-art for full disk encryption, and what we're
doing seems to me to be similar in concept. The most useful on-list
discussion that I found was on this thread:
https://www.postgresql.org/message-id/flat/c878de71-a0c3-96b2-3e11-9ac2c35357c3%40joeconway.com#19d3b7c37b9f84798f899360393584df
There are a lot of things that people said on that thread, but then
Bruce basically proposes CBC and/or CTR and I couldn't clearly
understand the reasons for that choice. Maybe there was some off-list
discussion of this that wasn't captured in the email traffic?
All that having been said, I am pretty sure I don't fully understand
what any of these modes involve. I gather that XTS requires two keys,
but it seems like it doesn't require a nonce. It seems to use a
"tweak" that is generated from the block number and the position
within the block (since an e.g. 8kB database block is being encrypted
as a bunch of 16-byte AES blocks) but apparently there's no problem
with the tweak being the same every time the block is encrypted? If no
nonce is required, that seems like a massive advantage, since then we
don't need to worry about how to get one or about how to make sure
it's never reused.
--
Robert Haas
EDB: http://www.enterprisedb.com