RE: xts fuzz testing and lack of ciphertext stealing support

[Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>]

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of Milan Broz
> Sent: Thursday, July 18, 2019 9:40 AM
> To: Herbert Xu <herbert@gondor.apana.org.au>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Horia Geanta <horia.geanta@nxp.com>; linux-crypto@vger.kernel.org; dm-devel@redhat.com
> Subject: Re: xts fuzz testing and lack of ciphertext stealing support
> 
> 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!
> 

Full XTS is XEX-TCB-CTS so the proper terminology for "XTS without CTS" would be XEX-TCB.
But the problem there is that TCB and CTS are generic terms that do not imply a specific 
implementation for generating the tweak -or- performing the ciphertext stealing.
Only the *full* XTS operation is standardized (as IEEE Std P1619).

In fact, using the current cts template around the current xts template actually does NOT
implement standards compliant XTS at all, as the CTS *implementation* for XTS is 
different from the one for CBC as implemented by the current CTS template.
The actual implementation of the ciphertext stealing has (or may have) a security impact,
so the *combined* operation must be cryptanalyzed and adding some random CTS scheme
to some random block cipher mode would be a case of "roll your own crypto" (i.e. bad).

From that perspective - to prevent people from doing cryptographically stupid things -
IMHO it would be better to just pull the CTS into the XTS implementation i.e. make
xts natively support blocks that are not a multiple of (but >=) the cipher blocksize ...

> Reality check - nobody in block layer needs ciphertext stealing, we are always
> aligned to block. AF_ALG is a different story, though.

So you don't support odd sector sizes like 520 , 528, 4112, 4160 or 4224 bytes?
> 
> Milan

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com