Kernel ML-KEM implementation plans

Kernel ML-KEM implementation plans

[Ryan Appel]

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? Just fork and code and pull request / review code?


Thank you,
    Ryan Appel

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

[Ryan Appel]

WireGuard was my big implementation user. 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. 


Thank you,
    Ryan Appel

> On Mar 30, 2026, at 7:15 PM, Eric Biggers <ebiggers@kernel.org> 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.
> 
> - 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

[Ryan Appel]

Another potential and likely use case is Wi-Fi. 

WPA3 supports both SAE-PK (which currently uses ECDSA-P256 and will likely migrate to ML-DSA or other,
And WPA3 enterprise supports EAP, which uses the IKE Diffie-Hellman groups, which already have added support for (pending finalization) ML-KEM groups.

Of course the spec will have to be updated, but it’s highly likely that at least ML-KEM-512 will be supported. 

The actual use of the algorithm is as simple as calling it instead of ECDH, but in theory, we typically care very much about the difference between key agreement and key exchange. 

The major difference on a code front is that with ECDH, you input a public and private key, and get out a shared key.
But with ML-KEM, you input a public key, and get out a shared key, and a cipher text.
Or you input a private key and a cipher text and get out the same shared key.

(Encapsulation -> one input, two outputs)
(Decapsulation -> two inputs, one output)

I understand that there is a chicken and egg scenario where there’s need to wait for the need before developing, but something at least to consider for the roadmap.


> On Mar 30, 2026, at 8:11 PM, Eric Biggers <ebiggers@kernel.org> wrote:
> 
> 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