Re: Kernel ML-KEM implementation plans

Another potential and likely use case is Wi-Fi.=20

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=E2=80=99s highly =
likely that at least ML-KEM-512 will be supported.=20

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.=20

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=E2=80=99=
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=E2=80=AFPM, Eric Biggers =
<[email protected]> wrote:
>=20
> On Mon, Mar 30, 2026 at 07:44:55PM -0500, Ryan Appel wrote:
>> WireGuard was my big implementation user.
>=20
> 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.
>=20
> 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.
>=20
>> 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.
>=20
> 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.
>=20
> - Eric