On Thu, May 27, 2021 at 12:01 PM Andres Freund <and...@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
