Re: Kernel ML-KEM implementation plans
Chris Leech <[email protected]> Mon, 6 Apr 2026 11:27:07 -0700
| Newsgroups | com.zx2c4.lists.wireguard,org.kernel.vger.linux-crypto |
|---|---|
| Message-ID | <[email protected]> |
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