[dm-devel] xts fuzz testing and lack of ciphertext stealing support

[Ard Biesheuvel]

On Thu, 18 Jul 2019 at 09:22, Herbert Xu <herbert at gondor.apana.org.au> 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.
>

If we were adding XTS to the kernel today, then I would agree with
you. But xts() has an established meaning now, and I don't think it
makes sense to update all implementations for a theoretical use case,
given that no portable userland code can rely on the correct semantics
today, since CAAM is the only one that implements them correctly.

In any case, I won't have time to fix the ARM or arm64 implementations
(or review the changes if someone else steps up) until the end of
September.