RE: XTS template wrapping question

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

> -----Original Message-----
> From: Eric Biggers <ebiggers@kernel.org>
> Sent: Friday, August 9, 2019 6:46 PM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> Cc: linux-crypto@vger.kernel.org; herbert@gondor.apana.org.au; davem@davemloft.net
> Subject: Re: XTS template wrapping question
> 
> On Fri, Aug 09, 2019 at 11:39:12AM +0000, Pascal Van Leeuwen wrote:
> > 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??)
> >
> 
> "xts(aes)" is the cra_name for AES-XTS, while everything else (e.g.
> "xts(ecb(aes-generic))", "xts-aes-aesni", "xts(ecb-aes-aesni)")
> is a cra_driver_name for AES-XTS.
> 
> "xts(ecb(aes))" doesn't make sense, as it's neither the cra_name nor does it
> name a specific implementation.
> 
Hmmm ... but if xts(aes) wants to wrap around an aes skcipher implementation,
it will have to search for "ecb(aes)". Since "aes" would give it a single
cipher block (generic) implementation that wouldn't work.
And it adds the "ecb(" somewhere under water in the wrapper, which is very
confusing if you don't know about that.
As it is confusing that there is an "aes" and an "ecb(aes)", aes being a
blockcipher and ecb not being a mode at all, but just the bare cipher.

Considering my hw driver actually exports ecb(aes) and NOT aes due to this,
xts(ecb(aes)) actually would have made MORE sense, IMNSHO.
(implementation wise, not semantically)

The whole thing would have been different if "ecb(aes)" had been just "aes".

> See create() in crypto/xts.c.  It allows the XTS template to be passed either
> the string "aes", *or* a string which names an *implementation* of "ecb(aes)",
> like "ecb(aes-generic)" or "ecb-aes-aesni".  In the first case it allocates
> "ecb(aes)" so it gets the highest priority AES-ECB implementation.
> 
> So in both cases the XTS template uses AES-ECB via the skcipher API.
> 
> - Eric
>
Yes, thanks I figured that out by now ...

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com