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

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

> -----Original Message-----
> From: Horia Geanta <horia.geanta@nxp.com>
> Sent: Wednesday, August 7, 2019 5:52 PM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> Cc: Milan Broz <gmazyland@gmail.com>; Herbert Xu <herbert@gondor.apana.org.au>; dm-
> devel@redhat.com; linux-crypto@vger.kernel.org
> Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support
> 
> On 7/26/2019 10:59 PM, Horia Geantă wrote:
> > On 7/26/2019 1:31 PM, Pascal Van Leeuwen wrote:
> >> Ok, find below a patch file that adds your vectors from the specification
> >> plus my set of additional vectors covering all CTS alignments combined
> >> with the block sizes you desired. Please note though that these vectors
> >> are from our in-house home-grown model so no warranties.
> > I've checked the test vectors against caam (HW + driver).
> >
> > Test vectors from IEEE 1619-2007 (i.e. up to and including "XTS-AES 18")
> > are fine.
> >
> > caam complains when /* Additional vectors to increase CTS coverage */
> > section starts:
> > alg: skcipher: xts-aes-caam encryption test failed (wrong result) on test vector 9,
> cfg="in-place"
> >
> I've nailed this down to a caam hw limitation.
> Except for lx2160a and ls1028a SoCs, all the (older) SoCs allow only for
> 8-byte wide IV (sector index).
>
I guess it's easy to say now, but I already suspected a problem with full 16 
byte random IV's. A problem with CTS itself seemed implausible due to the base
vectors from the spec running fine and I did happen to notice that all 
vectors from the spec only use up to the lower 40 bits of the sector number.
While my vectors randomize all 16 bytes.

So I guess that means that 16 byte multiples (i.e. not needing CTS) with
full 16 byte sector numbers will probably also fail on caam HW ...
	
As for the tweak size, with very close scrutiny of the IEEE spec I actually
noticed some inconsistencies:

- the text very clearly defines the tweak as 128 bit and starting from an 
*arbitrary* non-negative integer, this is what I based my implementation on

- all text examples and test vectors max out at 40 bits ... just examples,
but odd nonetheless (why 40 anyway?)

- the example code fragment in Annex C actually has the S data unit number
input as an u64b, further commented as "64 bits" (but then loops 16 times to
convert it to a byte string ...)

So I guess from this specification, a true HW engineer might implement a
full 128 bit tweak, while a SW engineer looking at the example code might
just implement 64 bits. And the latter would pass all provided test vectors.

> Will follow up with 16-byte IV support for the above-mentioned SoCs.
> 
> Pascal,
> 
> Could you also generate a few test vectors covering CTS with 8-byte IV?
> 
I can generate them in a format similar to what's in the IEEE spec, but I
don't feel much like typing them over into testmgr.h format again.
If you don't mind.

> Thanks,
> Horia

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