Ard, > -----Original Message----- > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Sent: Monday, July 22, 2019 6:43 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: Milan Broz <gmazyland@xxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; dm-devel@xxxxxxxxxx; linux- > crypto@xxxxxxxxxxxxxxx; Horia Geanta <horia.geanta@xxxxxxx> > Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support > > On Mon, 22 Jul 2019 at 12:44, Pascal Van Leeuwen > <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > > > > > -----Original Message----- > > > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > > Sent: Sunday, July 21, 2019 11:50 AM > > > To: Milan Broz <gmazyland@xxxxxxxxx> > > > Cc: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; dm-devel@xxxxxxxxxx; linux- > > > crypto@xxxxxxxxxxxxxxx; Horia Geanta <horia.geanta@xxxxxxx> > > > Subject: Re: [dm-devel] xts fuzz testing and lack of ciphertext stealing support > > > > > > On Sat, 20 Jul 2019 at 10:35, Milan Broz <gmazyland@xxxxxxxxx> wrote: > > > > > > > > On 20/07/2019 08:58, Eric Biggers wrote: > > > > > On Thu, Jul 18, 2019 at 01:19:41PM +0200, Milan Broz wrote: > > > > >> Also, I would like to avoid another "just because it is nicer" module dependence (XTS->XEX->ECB). > > > > >> Last time (when XTS was reimplemented using ECB) we have many reports with initramfs > > > > >> missing ECB module preventing boot from AES-XTS encrypted root after kernel upgrade... > > > > >> Just saying. (Despite the last time it was keyring what broke encrypted boot ;-) > > > > >> > > > > > > > > > > Can't the "missing modules in initramfs" issue be solved by using a > > > > > MODULE_SOFTDEP()? Actually, why isn't that being used for xts -> ecb already? > > > > > > > > > > (There was also a bug where CONFIG_CRYPTO_XTS didn't select CONFIG_CRYPTO_ECB, > > > > > but that was simply a bug, which was fixed.) > > > > > > > > Sure, and it is solved now. (Some systems with a hardcoded list of modules > > > > have to be manually updated etc., but that is just bad design). > > > > It can be done properly from the beginning. > > > > > > > > I just want to say that that switching to XEX looks like wasting time to me > > > > for no additional benefit. > > > > > > > > Fully implementing XTS does make much more sense for me, even though it is long-term > > > > the effort and the only user, for now, would be testmgr. > > > > > > > > So, there are no users because it does not work. It makes no sense > > > > to implement it, because there are no users... (sorry, sounds like catch 22 :) > > > > > > > > (Maybe someone can use it for keyslot encryption for keys not aligned to > > > > block size, dunno. Actually, some filesystem encryption could have use for it.) > > > > > > > > > Or "xts" and "xex" could go in the same kernel module xts.ko, which would make > > > > > this a non-issue. > > > > > > > > If it is not available for users, I really see no reason to introduce XEX when > > > > it is just XTS with full blocks. > > > > > > > > If it is visible to users, it needs some work in userspace - XEX (as XTS) need two keys, > > > > people are already confused enough that 256bit key in AES-XTS means AES-128... > > > > So the examples, hints, man pages need to be updated, at least. > > > > > > > > > > OK, consider me persuaded. We are already exposing xts(...) to > > > userland, and since we already implement a proper subset of true XTS, > > > it will be simply a matter of making sure that the existing XTS > > > implementations don't regress in performance on the non-CTS code > > > paths. > > > > > > It would be useful, though, to have some generic helper functions, > > > e.g., like the one we have for CBC, or the one I recently proposed for > > > CTS, so that existing implementations (such as the bit sliced AES) can > > > easily be augmented with a CTS code path (but performance may not be > > > optimal in those cases). For the ARM implementations based on AES > > > instructions, it should be reasonably straight forward to implement it > > > close to optimally by reusing some of the code I added for CBC-CTS > > > (but I won't get around to doing that for a while). If there are any > > > volunteers for looking into the generic or x86/AES-NI implementations, > > > please come forward :-) Also, if any of the publications that were > > > quoted in this thread have suitable test vectors, that would be good > > > to know. > > > > Unfortunately, these algorithm & protocol specifications tend to be very frugal when it > > comes to providing test vectors, barely scratching the surface of any corner cases, but > > at least there is one non-multiple-of-16 vector in the original IEEE P1619 / D16 > > specification in Annex B Test Vectors (last vector, "XTS-AES-128 applied for a data unit > > that is not a multiple of 16 bytes") > > > > Actually, that spec has a couple of test vectors. Unfortunately, they > are all rather short (except the last one in the 'no multiple of 16 > bytes' paragraph, but unfortunately, that one is in fact a multiple of > 16 bytes) > > I added them here [0] along with an arm64 implementation for the AES > instruction based driver. Could you please double check that these > work against your driver? That would establish a ground truth against > which we can implement the generic version as well. > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=xts-cts > I'm working on my XTS implementation now and I noticed something funny with the test vectors. The new CTS ones you added here, I can perfectly trace back to the IEEE spec, they match byte-for-byte. However, the ones that already existed puzzle me. The input data matches vectors from the IEEE spec, however the expected output cipher text does NOT ???? Case in point, the very first vector, which has a key of all zeroes, a sector number (IV) or all zeroes and an all zeroes plaintext of 32 bytes, which matches the 1st spec vector: testmgr.h expects: "\x4b\xc9\x44\x4a\x11\xa3\xef\xac" "\x30\x74\xe4\x44\x52\x77\x97\x43" "\xa7\x60\xb2\x45\x2e\xf9\x00\x90" "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0" But the specification expects: 917cf69ebd68b2ec9b9fe9a3eadda692cd43d2f59598ed858c02c2652fbf922e Which also happens to be what our hardware does ... Did you notice the same thing with your implementation? Am I missing something?? > > Besides that, I'd be happy to generate some testvectors from our defacto-standard > > implementation ;-) > > > > One or two larger ones would be useful, yes. Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
