Skip to content

Back to the catalog

Measuring Parallel Execution of Classical–PQC Component Pairs in Hybrid TLS 1.3
eprint.iacr.orgpaper

Measuring Parallel Execution of Classical–PQC Component Pairs in Hybrid TLS 1.3

An IACR ePrint paper benchmarks whether running the classical and post-quantum components of hybrid TLS 1.3 key exchange (ECDHE–ML-KEM) and Composite ML-DSA signatures in parallel on separate pthread worker threads reduces handshake latency versus sequential execution. Across three RFC 10024 ECDHE–ML-KEM groups with server and mutual authentication, parallelism sped up all six tested conditions on a standard ARM and x86 system (1.04×–1.28×), with the largest gains in signature stages where component times are balanced, but slowed every condition on a low-power x86 system (0.80×–0.92×) because thread wake/wait overhead outweighed savings. The authors conclude that component independence alone doesn't guarantee a speedup and that parallelization decisions must be validated per target environment.

TL;DR Parallelizing the classical/PQC halves of hybrid TLS 1.3 handshakes helps on ARM/x86 desktops but hurts on low-power x86, so gains depend entirely on the deployment hardware.
Open original ↗
Document

What it is

A benchmark study of parallelizing hybrid TLS 1.3 key exchange (ECDHE–ML-KEM) and Composite ML-DSA signatures across pthread worker threads, by Siwoo Eum, Minho Song, Seung-Won Lee, and Hwajeong Seo (eprint 2026/2341).

How it works

The paper isolates the cryptographic workload of a TLS handshake (not a full connection) and runs the classical and PQC component of each operation on two pthread workers simultaneously instead of sequentially, preserving operation order and timing the full synchronization cost. This is tested across all three RFC 10024 ECDHE–ML-KEM groups with matching Composite ML-DSA schemes, under both server-only and mutual (mTLS) authentication — six conditions per environment.

Preconditions / Affected

Results split by hardware, not just by stage:

  • ARM and standard x86: all six conditions sped up — 1.157×–1.281× on ARM, 1.041×–1.235× on x86.
  • Low-power x86: the identical source code slowed down in all six conditions — 0.800×–0.917×.

Gains were largest in signature stages, where the classical and PQC components take similar time; gains were small or negative in key-exchange stages, where one component dominates the other's runtime.

What to do

The paper's actionable conclusion is a measurement discipline, not a default: do not assume component independence implies a parallelization win. On the low-power x86 target, thread wake/wait overhead exceeded the time saved, and that overhead scaled with stage length rather than being a fixed per-pair cost — meaning it can't be amortized away by batching or predicted analytically. Anyone implementing parallel hybrid handshake components should benchmark the specific target CPU class (especially low-power/embedded x86) before enabling thread-based parallelism, and should expect the benefit to concentrate in signature stages with balanced component costs rather than key-exchange stages.

Caveats

The measurement is of the isolated crypto workload, not a full TLS connection, so real-world handshake gains may differ once network and protocol overhead are included. The negative result is tied to one specific low-power x86 environment; the paper does not generalize why that platform's thread overhead scales with stage length beyond noting it isn't a fixed cost.

Organisations named here

  • ECDHE
  • ML-DSA
  • ML-KEM
  • RFC 10024

Technologies named here

  • TLS 1.3
  • pthread
  • ECDHE-ML-KEM hybrid key exchange groups
  • ARM environment
  • x86 environment
  • Composite ML-DSA
  • Low-power x86 environment

Techniques named here

  • Parallel execution of classical-PQC component pairs
  • Mutual authentication

Related in other