On Sat, 27 Jul 2019 at 00:43, Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > > > -----Original Message----- > > From: Horia Geanta <horia.geanta@xxxxxxx> > > Sent: Friday, July 26, 2019 9:59 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 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" > > > > (Unfortunately it seems that testmgr lost the capability of dumping > > the incorrect output.) > > > > IMO we can't rely on test vectors if they are not taken > > straight out of a spec, or cross-checked with other implementations. > > > > First off, I fully agree with your statement, which is why I did not post this as a straight > patch. The problem is that specification vectors usually (or actuaclly, always) don't cover > all the relevant corner cases needed for verification. And "reference" implementations > by academics are usually shady at best as well. > > In this particular case, the reference vectors only cover 5 out of 16 possible alignment > cases and the current situation proves that this is not sufficient. As we have 2 imple- > mentations (or actually more, if you count the models used for vector generation) > that are considered to be correct that disagree on results. > > Which is very interesting, because which one is correct? I know that our model and > hardware implementation were independently developed (by 2 different engineers) > from the IEEE spec and match on results. And our hardware has been used "out in > the field" for many years already in disk controllers from major silicon vendors. > But that's still not a guarantee .... So how do we resolve this? Majority vote? ;-) > Thanks for the additional test vectors. They work fine with my SIMD implementations for ARM [0], so this looks like it might be a CAAM problem, not a problem with the test vectors. I will try to find some time today to run them through OpenSSL to double check. [0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=xts-cts
