On Tue, Feb 17, 2026 at 11:02:08AM -0500, Paul Wouters wrote:
> I was asked by a TLS participant to relay some information publicly
> regarding their pure PQ mlkem use case. I have rephrased their ontribution
> in my own words below.
>
> There is a use case for MLKEM in the market of high-frequency
> trading. Apparently there were complaints from those users (eg
> traders) in the past about the performane impact of migrating
> to TLS 1.2. If there is a performance drop with TLS 1.3 with an
> MLKEM hybrid, then migration to PQ (or TLS 1.3) would stall. If
> they can offer a (even tiny) performance gain of TLS 1.3 MLKEM
> over TLS 1.2 ECDHE, then this individual would have a strong
> case to deploy PQ security. Otherwise, the traders will insist
> on waiting until a CRQC is publicly known to exist.
>
> The individual stated they are in favour of adoption the pure mlkem
> document along with the hybrid document so people can pick either,
> depending in their use cases.
This does not look to me like a compelling rationale. A high-frequency
trading system that does not route trades over a connection that was
established well before market open, and expects to beat the competition
by minimising connection establishment latency, is perhaps doing it wrong.
For already established TLS connections latency does not depend on which
key agreement group was used in the initial handshake.
In environments where resumption is typically available, TLS 1.2 can
somtimes offer lower amortised connection latency than TLS 1.3, because
TLS 1.2 does not redo key agreement during resumption. While in TLS 1.3
interoperably negotiating "psk_ke", rather than "psk_dhe_ke" can be
quite challenging.
One might also point out that the payload of high-frequency trades is
not likely to be a long-term secret. Old news by market close, if not
in a matter of minutes or seconds. So harvest-now decrypt-later does
not look like a significant threat model in this use-case.
Why not just negotiate X25519, the smaller Client Hello packet size
likely more than makes up for any speed advantage from ML-KEM-768,
and its performance is quite competitive: (on my low-end CPU):
op/s
253 bits ecdh (X25519) 33494.6
keygens/s encaps/s decaps/s
ML-KEM-512 54360.7 80885.2 53943.8
ML-KEM-768 36473.2 60446.3 39872.6
Since for ML-KEM a client will do both keygen and decapsulation, X25519
may well be faster all around with little apparent reason to rush into
either pure or hybrid PQ in this use-case.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
