The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Alexandre Knecht <knecht.alexandre@gmail.com>
Cc: herbert@gondor.apana.org.au,
	"David S . Miller" <davem@davemloft.net>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	bpf@vger.kernel.org
Subject: Re: [PATCH] crypto: ctr - Convert from skcipher to lskcipher
Date: Sun, 10 May 2026 16:44:52 -0700	[thread overview]
Message-ID: <20260510234452.GB60510@quark> (raw)
In-Reply-To: <20260510233237.GA60510@quark>

On Sun, May 10, 2026 at 04:32:39PM -0700, Eric Biggers wrote:
> 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.

Also note that lskcipher doesn't provide access to the accelerated AES
mode implementations.  Indeed, almost nothing is supported by lskcipher.
The fact that you found something to be missing isn't surprising.

I think "lskcipher" is kind of a dead end, to be honest.  It's not clear
why it got added.  The path forwards is to get the AES encryption modes
added to lib/crypto/ and to just use that instead.

- Eric

  reply	other threads:[~2026-05-10 23:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-10 23:09 [PATCH] crypto: ctr - Convert from skcipher to lskcipher Alexandre Knecht
2026-05-10 23:32 ` Eric Biggers
2026-05-10 23:44   ` Eric Biggers [this message]
2026-05-11  0:02     ` Alexandre Knecht
2026-05-11  0:19       ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260510234452.GB60510@quark \
    --to=ebiggers@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=knecht.alexandre@gmail.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox