Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Vadim Fedorenko]

cc +bpf

On 07/07/2026 06:34, Eric Biggers wrote:
> BPF crypto was implemented using the lskcipher API, which doesn't seem
> to be going anywhere.  It supports only "arc4", "cbc(aes)", "ecb(aes)",
> and only with unoptimized implementations.
> 
> Library APIs also have been found to be a much better approach, for a
> variety of reasons, including reduced overhead, greater flexibility, and
> having to be explicit about the crypto algorithms that are supported.
> 
> We can safely ignore the theoretical "arc4" support in BPF crypto as
> unused, which leaves "cbc(aes)" and "ecb(aes)".  Why these algorithms
> were chosen, it's unclear.  Regardless, I'll assume that "cbc(aes)" and
> "ecb(aes)" need to continue to be supported for backwards compatibility.

That was done for single use case of decrypting small blocks in TC
layer with "cbc(aes)", with assumption of extending it later.

This change looks great, but it would be great to CC bpf folks just to
be aware of the refactoring.

> 
> There are library APIs for these now, which are much easier to use and
> more efficient.  Reimplement BPF crypto on top of them, greatly
> simplifying the code.  As part of this, the bpf_crypto_type abstraction
> layer is removed, as it's not useful.
> 
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

Re: [PATCH 30/33] bpf: crypto: Add AES-GCM support

[Vadim Fedorenko]

On 07/07/2026 06:35, Eric Biggers wrote:
> Add AES-GCM support as requested at
> https://lore.kernel.org/r/CAHAB8Wy1APeCcm7_OfrNYeZFcMXfZ5rUSeDX7-c7WO_rGg2Zig@mail.gmail.com/
> 
> With the library this is straightforward to do.
> 
> The associated data is assumed to be empty.  If control over that is
> needed, support would need to be added for it as well.
> 
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Eric Biggers]

On Tue, Jul 07, 2026 at 04:01:13PM +0100, Vadim Fedorenko wrote:
> cc +bpf
> 
> On 07/07/2026 06:34, Eric Biggers wrote:
> > BPF crypto was implemented using the lskcipher API, which doesn't seem
> > to be going anywhere.  It supports only "arc4", "cbc(aes)", "ecb(aes)",
> > and only with unoptimized implementations.
> > 
> > Library APIs also have been found to be a much better approach, for a
> > variety of reasons, including reduced overhead, greater flexibility, and
> > having to be explicit about the crypto algorithms that are supported.
> > 
> > We can safely ignore the theoretical "arc4" support in BPF crypto as
> > unused, which leaves "cbc(aes)" and "ecb(aes)".  Why these algorithms
> > were chosen, it's unclear.  Regardless, I'll assume that "cbc(aes)" and
> > "ecb(aes)" need to continue to be supported for backwards compatibility.
> 
> That was done for single use case of decrypting small blocks in TC
> layer with "cbc(aes)", with assumption of extending it later.

What protocol is using AES-CBC?  And is the kernel encrypting or
decrypting the data elsewhere, or it is just routing an encrypted packet
and only the BPF program decrypts it?

Does this mean the AES-ECB support is unnecessary and can be dropped?

> This change looks great, but it would be great to CC bpf folks just to
> be aware of the refactoring.

Sure.  I'm only looking to apply patches 1-13 for now; the rest (bpf,
fscrypt, keyrings, libceph, mac80211, macsec, mac802154, smb, ksmbd,
tipc) are proof of concept, showing how the library APIs can be used in
a wide range of kernel subsystems.  I didn't want to spam the entire
series to 20 mailing lists.  I'll resend them individually later.

Thanks!

- Eric

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Vadim Fedorenko]

On 07/07/2026 19:20, Eric Biggers wrote:
> On Tue, Jul 07, 2026 at 04:01:13PM +0100, Vadim Fedorenko wrote:
>> cc +bpf
>>
>> On 07/07/2026 06:34, Eric Biggers wrote:
>>> BPF crypto was implemented using the lskcipher API, which doesn't seem
>>> to be going anywhere.  It supports only "arc4", "cbc(aes)", "ecb(aes)",
>>> and only with unoptimized implementations.
>>>
>>> Library APIs also have been found to be a much better approach, for a
>>> variety of reasons, including reduced overhead, greater flexibility, and
>>> having to be explicit about the crypto algorithms that are supported.
>>>
>>> We can safely ignore the theoretical "arc4" support in BPF crypto as
>>> unused, which leaves "cbc(aes)" and "ecb(aes)".  Why these algorithms
>>> were chosen, it's unclear.  Regardless, I'll assume that "cbc(aes)" and
>>> "ecb(aes)" need to continue to be supported for backwards compatibility.
>>
>> That was done for single use case of decrypting small blocks in TC
>> layer with "cbc(aes)", with assumption of extending it later.
> 
> What protocol is using AES-CBC?  And is the kernel encrypting or
> decrypting the data elsewhere, or it is just routing an encrypted packet
> and only the BPF program decrypts it?

That's a "home-made" part of UDP encapsulation, the kernel routes it
further based on the info collected by BPF decrypt program.

> Does this mean the AES-ECB support is unnecessary and can be dropped?

Let's keep it if it doesn't hurt.

>> This change looks great, but it would be great to CC bpf folks just to
>> be aware of the refactoring.
> 
> Sure.  I'm only looking to apply patches 1-13 for now; the rest (bpf,
> fscrypt, keyrings, libceph, mac80211, macsec, mac802154, smb, ksmbd,
> tipc) are proof of concept, showing how the library APIs can be used in
> a wide range of kernel subsystems.  I didn't want to spam the entire
> series to 20 mailing lists.  I'll resend them individually later.

Ok, cool. But you can keep my Rb anyways - I checked the code and run
tests.

> 
> Thanks!
> 
> - Eric

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Eric Biggers]

On Tue, Jul 07, 2026 at 11:50:33PM +0100, Vadim Fedorenko wrote:
> > Does this mean the AES-ECB support is unnecessary and can be dropped?
> 
> Let's keep it if it doesn't hurt.

It kind of does.  It is "bad" crypto that would have to continue to be
maintained, and someone might start using it accidentally.

- Eric

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Vadim Fedorenko]

On 08/07/2026 00:16, Eric Biggers wrote:
> On Tue, Jul 07, 2026 at 11:50:33PM +0100, Vadim Fedorenko wrote:
>>> Does this mean the AES-ECB support is unnecessary and can be dropped?
>>
>> Let's keep it if it doesn't hurt.
> 
> It kind of does.  It is "bad" crypto that would have to continue to be
> maintained, and someone might start using it accidentally.

AES-ECB was introduced as a cipher to use in QUIC-LB draft,
draft-ietf-quic-load-balancers-21

I know it is expired draft, but it may be worth keeping this cipher
as QUIC WG github is still active

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Eric Biggers]

On Wed, Jul 08, 2026 at 12:47:43PM +0100, Vadim Fedorenko wrote:
> On 08/07/2026 00:16, Eric Biggers wrote:
> > On Tue, Jul 07, 2026 at 11:50:33PM +0100, Vadim Fedorenko wrote:
> > > > Does this mean the AES-ECB support is unnecessary and can be dropped?
> > > 
> > > Let's keep it if it doesn't hurt.
> > 
> > It kind of does.  It is "bad" crypto that would have to continue to be
> > maintained, and someone might start using it accidentally.
> 
> AES-ECB was introduced as a cipher to use in QUIC-LB draft,
> draft-ietf-quic-load-balancers-21
> 
> I know it is expired draft, but it may be worth keeping this cipher
> as QUIC WG github is still active

Sigh.  We shouldn't implement Internet-Drafts that have clear issues
with how they use cryptography.  They're likely to change when they
undergo cryptography review.  We went through this same thing with
TCP-AO, where I ended up joining the tcpm working group and getting the
draft fixed.  Do I need to do the same with this one too?

- Eric

Re: [PATCH 29/33] bpf: crypto: Use AES-CBC and AES-ECB libraries

[Vadim Fedorenko]

On 09/07/2026 16:47, Eric Biggers wrote:
> On Wed, Jul 08, 2026 at 12:47:43PM +0100, Vadim Fedorenko wrote:
>> On 08/07/2026 00:16, Eric Biggers wrote:
>>> On Tue, Jul 07, 2026 at 11:50:33PM +0100, Vadim Fedorenko wrote:
>>>>> Does this mean the AES-ECB support is unnecessary and can be dropped?
>>>>
>>>> Let's keep it if it doesn't hurt.
>>>
>>> It kind of does.  It is "bad" crypto that would have to continue to be
>>> maintained, and someone might start using it accidentally.
>>
>> AES-ECB was introduced as a cipher to use in QUIC-LB draft,
>> draft-ietf-quic-load-balancers-21
>>
>> I know it is expired draft, but it may be worth keeping this cipher
>> as QUIC WG github is still active
> 
> Sigh.  We shouldn't implement Internet-Drafts that have clear issues
> with how they use cryptography.  They're likely to change when they
> undergo cryptography review.  We went through this same thing with
> TCP-AO, where I ended up joining the tcpm working group and getting the
> draft fixed.  Do I need to do the same with this one too?

Looks like they need some crypto expert joining WG, but I'm not
currently following the group, unfortunately.