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

[Herbert Xu]

On Wed, Jan 26, 2022 at 09:08:38PM -0800, Eric Biggers wrote:
>
> The optional parameters mentioned in the comment above don't appear to be
> implemented.  Also, the syntax described is ambiguous.  I think you meant for
> there to be only one set of square brackets?
> 
> xctr(blockcipher_name) should be xctr_name, since it would have to be a driver /
> implementation name, and those don't necessarily include parentheses like the
> algorithm names do.
> 
> Did you consider not allowing the single block cipher implementation to be
> overridden?  The single block cipher is a minor part compared to xctr.  This
> would simplify the "full" syntax slighty, as then it would be
> "hctr2(xctr_name, polyval_name)" instead of
> "hctr2(blockcipher_name, xctr_name, polyval_name)".
> 
> I suppose it does make sense to take the single block cipher parameter, given
> that it is used.  But you'll need to make sure to make hctr2_create() enforce
> that the same block cipher is used in both parameters.

For the single block cipher parameter, another option is to derive
it from the xctr_name.  That is, once you have the skcipher for
xctr_name, you extract its cra_name, assuming that it must be of
the form xctr(%s) then you just strip away the xctr() and get the
single block cipher name that way.

The purpose of having the parameter explicitly is so that the
instantiatied algorithm is automatically torn down when the
underlying algorithm is replaced with a better version.

This is in general unnecessary if you're simply using the
single block cipher to generate setup material.

Cheers,
-- 
Email: Herbert Xu <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt