Re: [RFC PATCH 3/7] crypto: hctr2 - Add HCTR2 support
From: Eric Biggers <ebiggers@kernel.org>
Date: 2022-01-27 06:41:42
Also in:
linux-crypto
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:quoted
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 [off-list ref] 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel