Re: [PATCH] crypto: ctr - Convert from skcipher to lskcipher

[Eric Biggers <ebiggers@kernel.org>]

On Mon, May 11, 2026 at 01:09:01AM +0200, Alexandre Knecht wrote:
> Replace the existing skcipher CTR template with an lskcipher version,
> following the pattern established by the CBC conversion (705b52fef3c7).
> 
> This enables BPF programs using the bpf_crypto kfuncs to use CTR mode
> ciphers like ctr(aes), which previously failed because
> crypto_alloc_lskcipher() could not find an lskcipher implementation.
> ECB and CBC already have lskcipher support; CTR was the missing piece.
> 
> The rfc3686 template remains as an skcipher and continues to work
> through the automatic lskcipher-to-skcipher bridge.
> 
> Tested with NIST SP 800-38A test vectors (AES-128/192/256-CTR),
> partial block handling, and rfc3686 compatibility. Kernel self-tests
> pass on instantiation (selftest: passed in /proc/crypto).
> 
> Signed-off-by: Alexandre Knecht <knecht.alexandre@gmail.com>
> Assisted-by: Claude:claude-opus-4-6 checkpatch

I'm confused.  Why was that BPF crypto feature even added with ECB mode
as the only supported encryption mode?  Who is using that, and why?

CTR isn't necessarily much better, either.

What is the use case for the BPF crypto?  The first step should be to
decide what *specific* algorithm(s) it needs.  It doesn't seem like that
has ever happened, and I'm not sure this patch helps much.

That needs to be done anyway.  But that would also be helpful for a
potential future switch to lib/crypto/, which would avoid all the weird
issues with lskcipher etc.

- Eric