> -----Original Message----- > From: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Sent: Friday, August 9, 2019 4:18 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx>; linux-crypto@xxxxxxxxxxxxxxx; > herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Eric Biggers <ebiggers@xxxxxxxxxx> > Subject: RE: XTS template wrapping question > > > -----Original Message----- > > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf > Of > > Pascal Van Leeuwen > > Sent: Friday, August 9, 2019 1:39 PM > > To: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx; davem@xxxxxxxxxxxxx; Eric > > Biggers <ebiggers@xxxxxxxxxx> > > Subject: XTS template wrapping question > > > > Herbert, Eric, > > > > While working on the XTS template, I noticed that it is being used > > (e.g. from testmgr, but also when explictly exported from other drivers) > > as e.g. "xts(aes)", with the generic driver actually being > > "xts(ecb(aes-generic))". > > > > While what I would expect would be "xts(ecb(aes))", the reason being > > that plain "aes" is defined as a single block cipher while the XTS > > template actually efficiently wraps an skcipher (like ecb(aes)). > > The generic driver reference actually proves this point. > > > > The problem with XTS being used without the ecb template in between, > > is that hardware accelerators will typically advertise an ecb(aes) > > skcipher and the current approach makes it impossible to leverage > > that for XTS (while the XTS template *could* actually do that > > efficiently, from what I understand from the code ...). > > Advertising a single block "aes" cipher from a hardware accelerator > > unfortunately defeats the purpose of acceleration. > > > > I also wonder what happens if aes-generic is the only AES > > implementation available? How would the crypto API know it needs to > > do "xts(aes)" as "xts(ecb(aes))" without some explicit export? > > (And I don't see how xts(aes) would work directly, considering > > that only seems to handle single cipher blocks? Or ... will > > the crypto API actually wrap some multi-block skcipher thing > > around the single block cipher instance automatically??) > > > Actually, the above was based on observations from testmgr, which > doesn't seem to test xts(safexcel-ecb-aes) even though I gave that > a very high .cra_priority as well as that what is advertised under > /proc/crypto, which does not include such a thing either. > > However, playing with tcrypt mode=600 shows some interesting > results: > > WITHOUT the inside-secure driver loaded, both LRW encrypt and > decrypt run on top of ecb-aes-aesni as you would expect. > Both xts encrypt and decrypt give a "failed to load transform" > with an error code of -80. Strange ... -80 = ELIBBAD?? > (Do note that the selftest of xts(aes) using xts-aesni worked > just fine according to /proc/crypto!) > > WITH the inside-secure driver loaded, NOT advertising xts(aes) > itself and everything at cra_priority of 300: same (expected). > > WITH the inside-secure driver loaded, NOT advertising xts(aes) > itself and everything safexcel at cra_priority of 2000: > LRW decrypt now runs on top of safexcel-ecb-aes, but LRW > encrypt now runs on top of aes-generic? This makes no sense as > the encrypt datapath structure is the same as for decrypt so > it should run just fine on top of safexcel-ecb-aes. And besides > that, why drop from aesni all the way down to aes-generic?? > xts encrypt and decrypt still give the -80 error, while you > would expect that to now run using the xts wrapper around > safexcel-ecb-aes (but no way to tell if that's happening). > > WITH the inside-secure driver loaded, advertising xts(aes) > itself and everything at cra_priority of 2000: > still the same LRW assymmetry as mentioned above, but > xts encrypt and decrypt now work fine using safexcel-aes-xts > > Conclusions from the above: > > - There's something fishy with the selection of the underlying > AES cipher for LRW encrypt (but not for LRW decrypt). > Actually, this makes no sense at all as crypto_skcipher_alloc does not even see the direction you're going to use in your requests. Still, it is what I consistently see happening in the tcrypt logging. Weird! > - xts-aes-aesni (and the xts.c wrapper?) appear(s) broken in > some way not detected by testmgr but affecting tcrypt use, > while the inside-secure driver's local xts works just fine > Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
