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

[Eric Biggers <ebiggers@kernel.org>]

On Sun, May 10, 2026 at 05:19:35PM -0700, Eric Biggers wrote:
> On Mon, May 11, 2026 at 02:02:22AM +0200, Alexandre Knecht wrote:
> > Le lun. 11 mai 2026 à 01:44, Eric Biggers <ebiggers@kernel.org> a écrit :
> > > 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
> > 
> > Hi Eric,
> > 
> > Thanks for the review — you're asking the right questions.
> > 
> > I'm developing a VXLAN/EVPN-based CNI for Kubernetes (releasing in the
> > coming months), and the goal is to implement datapath encryption for
> > overlay traffic in a zero-trust datacenter model. The encryption
> > happens in BPF programs attached via TC on the VXLAN device (encrypt
> > inner frames on egress, decrypt on ingress).
> > 
> > The algorithm I actually need is AES-GCM (authenticated encryption of
> > VXLAN inner frames, with the outer headers as AAD). When I looked at
> > bpf_crypto, I found that:
> > 
> > 1. Only lskcipher ("skcipher" type) was implemented
> > 2. ecb(aes) was the only usable algorithm
> > 3. AEAD support was designed for (authsize field exists in
> >  bpf_crypto_params, setauthsize in bpf_crypto_type) but never
> >  implemented
> > 4. ctr(aes) wasn't available as lskcipher either
> > 
> > I looked at Herbert's history converting ECB and CBC to lskcipher and
> > assumed that was the path forward for CTR. But you're right, the
> > real goal is AEAD, not CTR. CTR alone doesn't give me integrity.
> > 
> > Your point about lib/crypto/ is interesting. If there's a path to
> > expose AES-GCM (or the building blocks) as direct library calls that
> > BPF programs in TC/XDP could use (avoiding the template/instance
> > machinery and getting hardware acceleration) that would be ideal for
> > this use case.
> > 
> > What would that look like? Is there existing lib/crypto/ work for
> > AES-GCM that could be wired up to BPF, or would that need to be
> > built?
> 
> Sure, it makes sense that AES-GCM is what you actually need.  There's
> actually a lot of demand for AES-GCM in lib/crypto/, and I've been
> working on it.
> 
> There's already an existing AES-GCM lib/crypto/ API (see
> include/crypto/gcm.h), and I optimized it a bit in 7.0 and 7.1.  For
> example, it now uses the architecture-optimized single-block AES code.
> 
> You might be able to go ahead and use that right now.
> 
> However, it currently supports only one-shot computation, and it doesn't
> yet take advantage of the fully optimized AES-GCM assembly code that
> interleaves the AES and GHASH computations.  I'm planning to address
> both of those limitations soon.
> 
> Anyway, that seems like the clear way forward.  The lskcipher thing
> seems like a dead end to me.

FYI, the following series adds new library APIs for AES-GCM and other
AES modes:
https://lore.kernel.org/linux-crypto/20260707053503.209874-1-ebiggers@kernel.org/

It also includes proof-of-concept patches to convert BPF crypto to use
the AES-ECB and AES-CBC library APIs, then add AES-GCM support.

I think that is roughly what you're looking for, and also what should
have been implemented in "BPF crypto" in the first place.  (Minus
AES-ECB, which is silly and should never have been supported in BPF
crypto.  And maybe minus AES-CBC too.)  But let me know what you think.

(I didn't Cc that series to everyone just for the proof-of-concept
patches, as I wrote them for lots of kernel subsystems.  For now they're
mainly for informing the API design and preparing for later.)

- Eric