Red Sift tested PQC in TLS 1.3 and found handshake data grew 180% with limited CPU impact; hybrid key exchange was more efficient than pure ML-KEM.
Cybersecurity vendor Red Sift recently tested the real-world performance of introducing post-quantum cryptography (PQC) into TLS 1.3. The results showed that when using the ECDSA-256 digital signature combined with the X25519MLKEM768 hybrid key establishment mechanism, the full TLS handshake data volume increased sharply by 180% compared with the baseline group. The baseline group used ECDSA-256 combined with X25519.Source
This test was announced on September 1 by Red Sift Chief Scientist Ivan Ristic. The focus of the test was not vulnerability exploitation, but observing the practical cost of PQC in an existing TLS 1.3 connection process, especially changes in handshake packet size and CPU time.Source
From a protocol design perspective, TLS 1.3 already shortens the handshake process as much as possible. However, after introducing PQC hybrid key establishment, the handshake must carry both traditional ECDHE and ML-KEM-related information, so the packet contents naturally become larger. Red Sift's data showed that when X25519MLKEM768 was used, the full TLS handshake data volume increased from 1,258 bytes to 3,522 bytes.Source
Notably, CPU costs did not rise significantly at the same time. According to the test results, client and server CPU time increased by only 0.074 milliseconds and 0.042 milliseconds, respectively, showing that at least under same-machine, low-latency conditions, PQC has a relatively limited impact on computing resources. This means the current bottleneck may not lie in encryption and decryption operations, but more likely in data transmission and the protocol layer of the handshake process.Source
If pure ML-KEM-1024 key establishment is used without X25519, the handshake data volume rises further to 4,323 bytes, a 243.7% increase over the baseline. Red Sift also pointed out that the extra handshake data on the server side may consume transmission space in TCP's initial congestion window, thereby affecting real-world connection setup performance. For practical deployment, this phenomenon deserves more attention than CPU time.Source
In addition, if the client does not provide ML-KEM-1024 key exchange information in the initial ClientHello, the server must respond with a retry request, adding one more network round trip to each full TLS connection. In the public internet environment, this extra RTT usually has a more noticeable impact on user experience and service latency than simple millisecond-level CPU costs.Source
However, this test was conducted with the client and server running on the same computer and with extremely low network latency, so the results should mainly be viewed as a relative comparison of different PQC key establishment methods, not as a direct measure of absolute performance in real network deployments. In other words, this data is more of a directional indicator than a final guarantee of production performance.Source
The most direct impact of this test is on TLS services that are evaluating or planning PQC adoption. If a service has frequent handshakes and dense connection establishment, packet bloat could translate into substantial latency and bandwidth costs, especially for portals, API gateways, edge nodes, and highly concurrent applications.Source
For end users, the risk may not show up as resource exhaustion, but as slower connection setup, longer time to first byte, or even more noticeable handshake delays when network quality is poor. For service operators, this may mean they need to reexamine the TLS stack, load balancing, certificates, and key establishment strategy.Source
For organizations already planning a gradual transition to PQC, this real-world test sends a clear signal: adopting PQC is not just an algorithm swap, but a recalibration of protocol size, network behavior, and infrastructure capacity. If only encryption strength is considered while handshake size is ignored, the total deployment cost may be underestimated.Source
First, a hybrid deployment strategy should be used as the starting point for transition, with priority given to evaluating solutions such as X25519MLKEM768 that balance compatibility and PQC, rather than jumping directly to higher-cost configurations that cause unnecessary handshake growth. Based on Red Sift's test results, the hybrid approach still maintains a relatively controllable balance between CPU impact and handshake size.Source
Second, stress testing should be performed under conditions close to the real environment, rather than relying only on single-machine or low-latency experimental data. During testing, particular attention should be paid to handshake packet size, the initial congestion window, retry count, and the impact of RTT on user experience so that the actual post-deployment risk can be estimated more accurately.Source
Third, if service traffic depends heavily on short-lived connections or a large number of new connections, priority should be given to checking whether connection reuse, pre-caching, TLS termination adjustments, or edge deployment can absorb handshake costs. These optimizations do not change cryptographic strength, but they can reduce the pressure that larger PQC handshakes place on the transport layer.Source
Finally, organizations should treat PQC as a long-term evolution project rather than a one-time upgrade. In addition to the algorithms themselves, the differences among key establishment methods in packet size, latency, and compatibility should be continuously tracked, and those results should be incorporated into architecture review and change management processes.Source