> -----Original Message----- > From: Ard Biesheuvel <ard.biesheu...@linaro.org> > Sent: Saturday, July 27, 2019 7:39 AM > To: Pascal Van Leeuwen <pvanleeu...@verimatrix.com> > Cc: Horia Geanta <horia.gea...@nxp.com>; Milan Broz <gmazyl...@gmail.com>; > Herbert Xu <herb...@gondor.apana.org.au>; dm- > de...@redhat.com; linux-cry...@vger.kernel.org > Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing > support > > 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. > Thanks for the heads up! As the engineer actually responsible for our hardware implementation, I can now sleep at night again :-)
Not that I was too worried - the design has been in active use for nearly 12 years already without any known issues, but still ... > 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 Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
