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