Re: [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support

Eric Biggers
2022-01-27T06:42:43Z

On Thu, Jan 27, 2022 at 04:44:48PM +1100, Herbert Xu wrote:
> On Thu, Jan 27, 2022 at 04:40:16PM +1100, Herbert Xu wrote:
> >
> > The question is is it performance-critical? Including it as a
> > parameter would be worthwhile if it is. But if its cost is dwarfed
> > by that of the accompanying operations then it might not be worth
> > the complexity.
>
> It looks like this is similar to the situation in XTS where I chose
> not to make it a full parameter during the skcipher conversion:
>
> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue Nov 22 20:08:19 2016 +0800
>
> crypto: xts - Convert to skcipher
>
> Cheers,

Sure, that makes sense.

Note that if the meaning of the first parameter to the template will differ
(blockcipher_name vs. xctr_name), the full syntax probably should be supported
by a separate template called "hctr2_base" rather than by "hctr2", to avoid
having the meaning of the first parameter be context-dependent. This would be
like gcm and gcm_base. So we'd have e.g.:

hctr2(aes)
hctr2_base(xctr-aes-aesni,polyval-pclmulqdqni)

cra_name would be set to the former, while cra_driver_name would be set to the
latter.

- Eric