In general, MLKEM is indeed faster than X25519. By a small amount yes, but I am not aware of any X25519 implementations that are faster than MLKEM. MLKEM KeyGen + Decaps is on the order of ~70,000 cycles (Encaps is approx 35000 cycles-ish) whereas the equivalent for X25519 (KeyGen + DH) is closer to 100,000 cycles. This does not control for variations that you will see in actual high performance deployments, but the 10,000+ cycle difference gives you an idea of the pecking order. These numbers were pulled from a hat (eBATS) and will of course vary.
I think a better way to phrase is is that MLKEM + X25519 is slightly better in performance than P-256, which indicates that the slowdown from hybridization is well outside of the range of fatality for adoption in any sense. Anyone able to afford P-256 can afford the hybrid (and will probably see a speedup, unless they pick the P-256 hybrid) If performance is really an issue, I’d be curious to see if there’s consensus to adopt eg. 4Q-MLKEM768 as a high performance alternative. I don’t think there will be, but while we’re on the topic of new things and performance, I think these two might go together nicely. Joshua -------- Original Message -------- On Saturday, 02/28/26 at 02:03 Nadim Kobeissi <[email protected]> wrote: > Dear Deirdre, > > This isn’t very important, but putting aside ML-KEM’s massive key size > increase over X25519, the claim that ML-KEM is almost twice as fast as X25519 > is highly dependent on hardware optimizations, as far as I’m aware, and is not > always true. > > It could become increasingly universally true over the coming years though, as > hardware optimizations to accommodate ML-KEM become more common. For example, > I think Apple hardware recently implemented SHA3 as a CPU instruction, and > that certainly would give ML-KEM a big speed boost! > > Nadim Kobeissi > Symbolic Software • https://symbolic.software > > > > On 28 Feb 2026, at 1:22 AM, Deirdre Connolly <[email protected]> > > wrote: > > > > > > > > In particular when the use of hybrid crypto comes with negligible > > overhead, as for ML-KEM + ECC. > > > > X25519 is almost twice as slow as MLKEM768 > > (https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519); P-256 is about > > the same > > > > On Fri, Feb 27, 2026, 5:25 PM Tibor Jager <[email protected]> wrote: > > > > > > > > > > > > Am 27.02.2026 um 21:16 schrieb Ilari Liusvaara > > > <[email protected]>: > > > > - There does not seem to be any evidence that ML-KEM is weak. I think > > > > that if ML-KEM gets badly broken, it will be for unforeseeable reasons > > > > (which is a risk for any cryptographic algorithm, including prime- > > > > field ECC). > > > > > > Except that for a hybrid mode, both ML-KEM and ECC must be broken > > > simultaneously. > > > > > > I think it is unwise to rely *only* on ML-KEM (or any other scheme based > > > on relatively new hardness assumptions), and currently do not support any > > > draft that does not use hybrid cryptography. In particular when the use of > > > hybrid crypto comes with negligible overhead, as for ML-KEM + ECC. > > > > > > For almost every broken cryptosystem there was a time when there seemed to > > > be no evidence that it is weak. ML-KEM still needs to stand the test of > > > time. > > > > > > Best regards, > > > Tibor > > > _______________________________________________ > > > TLS mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
