> -----Original Message----- > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Sent: Saturday, July 27, 2019 7:39 AM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: Horia Geanta <horia.geanta@xxxxxxx>; 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 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. > 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
