On 18/07/2019 09:21, Herbert Xu wrote: > On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote: >> >> Not just the generic implementation: there are numerous synchronous >> and asynchronous implementations of xts(aes) in the kernel that would >> have to be fixed, while there are no in-kernel users that actually >> rely on CTS. Also, in the cbc case, we support CTS by wrapping it into >> another template, i.e., cts(cbc(aes)). >> >> So retroactively redefining what xts(...) means seems like a bad idea >> to me. If we want to support XTS ciphertext stealing for the benefit >> of userland, let's do so via the existing cts template, and add >> support for wrapping XTS to it. > > XTS without stealing should be renamed as XEX. Sure you can then > wrap it inside cts to form xts but the end result needs to be called > xts. While I fully agree here from the technical point of view, academically XEX, XEX* is a different mode. It would create even more confusion. Couldn't resist, but this is a nice example of what happens when academic, standardization, and reality meets in one place :) XTS is already implemented in gcrypt and OpenSSL. IMO all the implementation should be exactly the same. I agree with Herbert that the proper way is to implement ciphertext stealing. Otherwise, it is just incomplete implementation, not a redefining XTS mode! See the reference in generic code - the 3rd line - link to the IEEE standard. We do not implement it properly - for more than 12 years! Reality check - nobody in block layer needs ciphertext stealing, we are always aligned to block. AF_ALG is a different story, though. Milan
