On Thu, Oct 17, 2019 at 09:08:59PM +0200, Ard Biesheuvel wrote:
> +static inline void chacha_crypt(u32 *state, u8 *dst, const u8 *src,
> + unsigned int bytes, int nrounds)
> +{
> + if (IS_ENABLED(CONFIG_CRYPTO_ARCH_HAVE_LIB_CHACHA))
> + chacha_crypt_arch(state, dst, src, bytes, nrounds);
> + else
> + chacha_crypt_generic(state, dst, src, bytes, nrounds);
> +}
How about also providing chacha20_crypt() which calls chacha_crypt(..., 20)?
The 'nrounds' parameter is really for implementations, rather than users of the
library API. Users don't really have any business specifying the number of
rounds as an int.
> +static inline int chacha_setkey(struct crypto_skcipher *tfm, const u8 *key,
> + unsigned int keysize, int nrounds)
> +{
> + struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
> + int i;
> +
> + if (keysize != CHACHA_KEY_SIZE)
> + return -EINVAL;
> +
> + for (i = 0; i < ARRAY_SIZE(ctx->key); i++)
> + ctx->key[i] = get_unaligned_le32(key + i * sizeof(u32));
> +
> + ctx->nrounds = nrounds;
> + return 0;
> +}
At the end of this patch series there are 5 drivers which wrap chacha_setkey()
with chacha20_setkey() and chacha12_setkey() -- all 5 pairs identical. How
about providing those as inline functions here?
> +config CRYPTO_LIB_CHACHA
> + tristate "ChaCha library interface"
> + depends on CRYPTO_ARCH_HAVE_LIB_CHACHA || !CRYPTO_ARCH_HAVE_LIB_CHACHA
> + select CRYPTO_LIB_CHACHA_GENERIC if CRYPTO_ARCH_HAVE_LIB_CHACHA=n
> + help
> + Enable the ChaCha library interface. This interface may be fulfilled
> + by either the generic implementation or an arch-specific one, if one
> + is available and enabled.
Since this is a library for use within the kernel, and not a user-visible
feature, I don't think it should be explicitly selectable. I.e. it should just
be "tristate", without the prompt string.
- Eric
