On Thu, 14 Sept 2023 at 10:56, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 14, 2023 at 10:51:21AM +0200, Ard Biesheuvel wrote:
> >
> > So the intent is for lskcipher to ultimately supplant the current
> > cipher entirely, right? And lskcipher can be used directly by clients
> > of the crypto API, in which case kernel VAs may be used directly, but
> > no async support is available, while skcipher API clients will gain
> > access to lskciphers via a generic wrapper (if needed?)
> >
> > That makes sense but it would help to spell this out.
>
> Yes that's the idea. It is pretty much exactly the same as how
> shash and ahash are handled and used.
>
> Because of the way I structured the ecb transition code (it will
> take an old cipher and repackage it as an lskcipher), we need to
> convert the templates first and then do the cipher => lskcipher
> conversion.
>
> > I'd be happy to help out here but I'll be off on vacation for ~3 weeks
> > after this week so i won't get around to it before mid October. What I
> > will do (if it helps) is rebase my recent RISC-V scalar AES cipher
> > patches onto this, and implement ecb(aes) instead (which is the idea
> > IIUC?)
>
> That sounds good. In fact let me attach the aes-generic proof-
> of-concept conversion (it can only be applied after all templates
> have been converted, so if you test it now everything but ecb/cbc
> will be broken).
>
That helps, thanks.
...
> +static struct lskcipher_alg aes_alg = {
> + .co = {
> + .base.cra_name = "aes",
So this means that the base name will be aes, not ecb(aes), right?
What about cbc and ctr? It makes sense for a single lskcipher to
implement all three of those at least, so that algorithms like XTS and
GCM can be implemented cheaply using generic templates, without the
need to call into the lskcipher for each block of input.
