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

[Eric Biggers <ebiggers@kernel.org>]

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.

- Eric