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 at 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