On 8/7/2019 11:58 PM, Pascal Van Leeuwen wrote: >> -----Original Message----- >> From: Horia Geanta <horia.geanta@xxxxxxx> >> Sent: Wednesday, August 7, 2019 5:52 PM >> To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>; Ard Biesheuvel >> <ard.biesheuvel@xxxxxxxxxx> >> Cc: Milan Broz <gmazyland@xxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; dm- >> devel@xxxxxxxxxx; linux-crypto@xxxxxxxxxxxxxxx >> 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 ... > Yes, the limitation applies for all input sizes. It's actually mentioned in the commit that added xts support few years back: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)") sector index - HW limitation: CAAM device supports sector index of only 8 bytes to be used for sector index inside IV, instead of whole 16 bytes received on request. This represents 2 ^ 64 = 16,777,216 Tera of possible values for sector index. > 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 ...) > The input I received from our HW design team was something like: - some P1619 drafts used LRW (instead of XTS), where the tweak "T" was 16B-wide - at some point P1619 drafts switched (and eventually standardized) XTS, where "T" is no longer the tweak - "i" is the (public) tweak, "T" being an intermediate (hidden) result in the encryption scheme - since for XTS "i" is supposed to be the sector number, there is no need to support 16B values - 8B being deemed sufficient Agree, limiting "i" (XTS tweak) to 8B is out-of-spec - irrespective of the usefulness of the full 16B. That's why latest Freescale / NXP SoCs support 16B tweaks. Thanks, Horia