Re: Kernel ML-KEM implementation plans

Re: Kernel ML-KEM implementation plans

[Eric Biggers]

On Mon, Mar 30, 2026 at 06:41:46PM -0500, Ryan Appel wrote:
> Hello all, 
> 
> Looking through the mail archives I see no information on an
> implementation of ML-KEM that has been planned, except for leancrypto
> attempting to make a Key-Agreement Scheme a Key-Encapsulation
> Mechanism.
> 
> Is there a plan to implement a KEM interface at this point? Is this
> something that needs support?  How could someone contribute to this?

We don't add new algorithms preemptively, but rather only when an
in-kernel user comes along.  Otherwise there's a risk that the code will
never be used.

Do you have a specific in-kernel user in mind?  I haven't actually heard
anyone specifically say they need ML-KEM in the kernel yet.

I guess the obvious use case would be WireGuard.  But that would require
a new WireGuard protocol version that replaces X25519 with something
like X25519MLKEM768.  It's going to be up to the WireGuard author
(Jason) to decide whether that's in the roadmap for WireGuard.

Also maybe Bluetooth, though it seems the spec for that is yet to be
defined?

Anyway, point is, before it makes sense to consider possible
implementation strategies, there needs to be a plan to actually use it.

- Eric

Re: Kernel ML-KEM implementation plans

[Eric Biggers]

On Mon, Mar 30, 2026 at 07:44:55PM -0500, Ryan Appel wrote:
> WireGuard was my big implementation user.

Any more details on this?  Googling for research papers shows that there
have indeed been several proposals for quantum-resistant WireGuard.  But
some use algorithms other than ML-KEM.  Others don't modify the kernel
code but rather do the key establishment in userspace.  I haven't looked
into the details, but it also sounds like it's not as simple as swapping
out the algorithm, either.

I think step 1 is work out some plan with the WireGuard folks.  Which
may or may not turn out to involve in-kernel ML-KEM.

> I also know that VMware uses the kernel crypto space for many of its
> crypto operations.  I do not know when they will want ML-KEM and if
> they will want it only within BoringCrypto or OpenSSL, but if there is
> need for it in the market before it can be developed then that makes
> sense.

That code isn't upstream though, right?  So even if hypothetically they
(will?) need ML-KEM in the kernel (for what?), that doesn't count for
upstream purposes.

- Eric

Re: Kernel ML-KEM implementation plans

[Chris Leech]

On Mon, Mar 30, 2026 at 05:13:58PM -0700, Eric Biggers wrote:
> On Mon, Mar 30, 2026 at 06:41:46PM -0500, Ryan Appel wrote:
> > Hello all, 
> > 
> > Looking through the mail archives I see no information on an
> > implementation of ML-KEM that has been planned, except for leancrypto
> > attempting to make a Key-Agreement Scheme a Key-Encapsulation
> > Mechanism.
> > 
> > Is there a plan to implement a KEM interface at this point? Is this
> > something that needs support?  How could someone contribute to this?
> 
> We don't add new algorithms preemptively, but rather only when an
> in-kernel user comes along.  Otherwise there's a risk that the code will
> never be used.
> 
> Do you have a specific in-kernel user in mind?  I haven't actually heard
> anyone specifically say they need ML-KEM in the kernel yet.
> 
> I guess the obvious use case would be WireGuard.  But that would require
> a new WireGuard protocol version that replaces X25519 with something
> like X25519MLKEM768.  It's going to be up to the WireGuard author
> (Jason) to decide whether that's in the roadmap for WireGuard.
> 
> Also maybe Bluetooth, though it seems the spec for that is yet to be
> defined?
> 
> Anyway, point is, before it makes sense to consider possible
> implementation strategies, there needs to be a plan to actually use it.

The NVMe fabrics authentication protocol will need a PQC replacement for
it's FFDHE use. There is not a specification update for that yet.

- Chris