RE: XTS template wrapping question

[Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>]

> -----Original Message-----
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of
> Pascal Van Leeuwen
> Sent: Friday, August 9, 2019 1:39 PM
> To: linux-crypto@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net; Eric
> Biggers <ebiggers@kernel.org>
> 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).
- 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