On Thu, 18 Jul 2019 at 08:52, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jul 17, 2019 at 08:08:27PM +0200, Ard Biesheuvel wrote: > > > > Since the kernel does not support CTS for XTS any way, and since no > > AF_ALG users can portably rely on this, I agree with Eric that the > > only sensible way to address this is to disable this functionality in > > the driver. > > But the whole point of XTS is that it supports sizes that are > not multiples of the block size. So implementing it without > supporting ciphertext stealing is just wrong. > > So let's fix the generic implementation rather than breaking > the caam driver. > 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.
