I completely agree with Viktor’s statement. While I don’t understand the protocols supporting high frequency trading, I find the claim that HFT is bound by the handshake time dubious. I also wasn’t able to support the claim that HFT traders even use TLS at all; my understanding is that HFT traders use private connections that don’t have any encryption, just raw TCP/IP. My understanding is that the vast majority of third-party service providers only perform a TLS handshake directly before logging on, and use a stream protocol like WebSockets for further messages.
It just doesn’t make sense to sell a high-frequency product where a TLS session
must be opened before every trade, as that would also imply logging
on/validating authentication before every trade, which would add extra latency
as well. Any product that does this wouldn’t be competitive compared to other
providers that optimize for latency.
I’d love to hear more from this trader because, as always, I could be wrong.
But it seems to me like there is no aspect of high frequency trading where
logon/session establishment latency is critical.
Best,
Joshua Nabors
-------- Original Message --------
On Tuesday, 02/17/26 at 09:22 Viktor Dukhovni <[email protected]> wrote:
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]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
