On Thu, 8 Aug 2019 at 16:11, Milan Broz <gmazyland@xxxxxxxxx> wrote: > > On 08/08/2019 12:37, Ard Biesheuvel wrote: > >>> True. Which is another historical mistake imo, since XTS is only > >>> specified for AES, but I digress ... :-) > >>> > >> Yes, I was also surprised by the use of XTS with other blockciphers. > >> It sort of violates the don't roll your own crypto paradigm ... > >> (although some might argue that XTS is supposed to be secure if the > >> underlying blockcipher is, regardless of what that cipher actually is) > >> > > > > That doesn't really matter. What matters is that nobody took a careful > > look whether XTS combined with other ciphers is a good idea before > > throwing it out into the world. > > Couldn't resist, but tell that to TrueCrypt authors (if you know them :) > > They used XTS for other AES candidates (Serpent, Twofish, also in > chained modes together). > > Older versions used LRW mode, doing the same. > Even implementing LRW over Blowfish that has 8-byte block size, so you > need GF(2^64) operations - that is luckily not implemented in Linux kernel > crypto API :-) > > VeraCrypt continued the tradition, adding the Camellia and > Kuznyetchik (actually discussed GOST standard) to the XTS mix. > > But without sarcasm, I do want to support this for users, > we can map (but not create) such images in cryptsetup, and it is partially > reason I want dm-crypt to be fully configurable... > The cat is already out of the bag, so we're stuck with it in any case. But going forward, I'd like to apply a bit more sanity to which combinations of modes we support, which is why I was skeptical about eboiv potentially being used by authenc(hmac(crc32),lrw(blowfish)) while it is only intended for use with cbc(aes).
