On Sat, 27 Jul 2019 at 00:43, Pascal Van Leeuwen <pvanleeu...@verimatrix.com> wrote: > > > -----Original Message----- > > From: Horia Geanta <horia.gea...@nxp.com> > > Sent: Friday, July 26, 2019 9:59 PM > > To: Pascal Van Leeuwen <pvanleeu...@verimatrix.com>; Ard Biesheuvel > > <ard.biesheu...@linaro.org> > > Cc: Milan Broz <gmazyl...@gmail.com>; Herbert Xu > > <herb...@gondor.apana.org.au>; dm-devel@redhat.com; linux- > > cry...@vger.kernel.org > > 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
