Re: Kernel ML-KEM implementation plans

WireGuard was my big implementation user. I also know that VMware uses the k=
ernel crypto space for many of its crypto operations. I do not know when the=
y will want ML-KEM and if they will want it only within BoringCrypto or Open=
SSL, but if there is need for it in the market before it can be developed th=
en that makes sense.=20


Thank you,
    Ryan Appel

> On Mar 30, 2026, at 7:15=E2=80=AFPM, Eric Biggers <[email protected]> wr=
ote:
>=20
> =EF=BB=BFOn Mon, Mar 30, 2026 at 06:41:46PM -0500, Ryan Appel wrote:
>> Hello all,
>>=20
>> 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.
>>=20
>> Is there a plan to implement a KEM interface at this point? Is this
>> something that needs support?  How could someone contribute to this?
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Also maybe Bluetooth, though it seems the spec for that is yet to be
> defined?
>=20
> Anyway, point is, before it makes sense to consider possible
> implementation strategies, there needs to be a plan to actually use it.
>=20
> - Eric