PQC Performance

For most post-quantum schemes the bottleneck is not CPU — it is bandwidth. Lattice operations are blisteringly fast; the keys, ciphertexts, and signatures are what strain protocols and storage. Understanding that tradeoff is the key to a smooth migration.

CPU is usually not the bottleneck

In server TLS/KEM scenarios, CPU is usually not the primary bottleneck — but embedded, HSM, smartcard, and high-throughput signing services still need real-world measurement. The lattice-based standards are fast.ML-KEM key generation, encapsulation, and decapsulation all complete in microseconds on commodity hardware, and ML-DSA signing and verification are likewise fast. With optimized implementations on modern servers, ML-KEM/ML-DSA are generally fast enough that primitive computation is not the bottleneck in many scenarios; but the precise speed relationship versus ECDH/RSA must be confirmed by measurement on the target platform. For the everyday TLS/KEM case, the per-operation CPU cost of post-quantum crypto is usually not the primary bottleneck on modern servers.

The real cost is message size. A post-quantum handshake moves kilobytes where a classical one moved tens to hundreds of bytes, and a signature can be one to two orders of magnitude larger than an ECDSA signature. That extra data inflates handshake latency, certificate chains, and storage — and on lossy or constrained links it can force extra round trips or packet fragmentation.

Relative profile by scheme

Treat these as order-of-magnitude, qualitative comparisons; absolute numbers vary widely with hardware, compiler, and AVX2/hardware acceleration, so always benchmark on your target.

Where each scheme hurts

• ML-KEM / ML-DSA: usually modest CPU cost on modern servers; benchmark embedded, HSM, smartcard and high-throughput signing environments. The main visible cost is a few extra KB per handshake or signed object.
• SLH-DSA: signing is measured in milliseconds and signatures are large. Excellent for rarely-signed, long-lived artifacts (firmware, root certificates), poor for high-throughput online signing.
• Classic McEliece: encapsulation is fast and the security argument is decades old, but the public key is enormous and slow to generate — it taxes bandwidth and storage, not steady-state CPU.
• Falcon: small signatures and fast verification make it attractive for size-sensitive protocols, but constant-time signing is hard (see side channels).

Hardware acceleration

Optimized implementations use AVX2 (and increasingly AVX-512 and Arm NEON) to vectorize the polynomial arithmetic and NTT, giving large speedups over portable C. SHA-3/SHAKE hashing — used heavily by ML-KEM and ML-DSA — benefits from CPU SHA extensions and dedicated hardware. On embedded targets, lack of these features widens the gap, so benchmark on the actual deployment hardware rather than a development laptop.

How to benchmark honestly

Public benchmarking efforts such as SUPERCOP and the various PQC benchmarking suites measure cycle counts across platforms; use them for relative guidance, not as guarantees for your environment. When you benchmark:

1. Measure on your target CPU with the same compiler flags you ship.
2. Separate per-operation CPU cost from total bytes on the wire.
3. For protocols, measure end-to-end handshake latency including any added round trips, not just the crypto primitive.
4. Compare hybrid configurations (classical + PQ) against pure classical to size the real-world delta.

Related

Standards & references

• Open Quantum Safe — uniform harness for benchmarking schemes side by side.
• liboqs (GitHub) — the library and built-in speed tests behind such benchmarks.
• NIST PQC project — algorithm specifications and parameter sets.
• Resources — full standards register