> -----Original Message----- > From: Horia Geanta <[email protected]> > Sent: Friday, July 26, 2019 9:59 PM > To: Pascal Van Leeuwen <[email protected]>; Ard Biesheuvel > <[email protected]> > Cc: Milan Broz <[email protected]>; Herbert Xu > <[email protected]>; [email protected]; linux- > [email protected] > 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? ;-) > Horia > Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
