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