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

[Eric Biggers]

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 at 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