Hi Horia,

This is the best I can do on short notice w.r.t vectors with 8 byte IV.
Format is actually equivalent to that of the XTS specification, with
the sector number being referred to as "H".

Actually, the input keys, plaintext and IV should be the same as before,
with the exception of the IV being truncated to 64 bits, so that should
give you some reference regarding byte order etc.

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.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).
> 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?
> 
> Thanks,
> Horia