The Classical Half Is Not the Cheap Half
What a hybrid post-quantum key exchange actually costs, measured
Audience: Engineers choosing a post-quantum key exchange for Rust or WASM Version: 1.0 | September 2026
The assumption
Most people picture a hybrid key exchange as the new post-quantum algorithm plus a small classical add-on. ML-KEM does the heavy lifting; X25519 comes along as a cheap hedge.
We measured it. The classical half is not the cheap half.
The numbers
These come from pqc-kem 0.3, our pure-Rust crate built on RustCrypto's ml-kem (FIPS 203). We ran
them on a dedicated host (Intel Xeon Platinum 8488C) with criterion: three passes with the
first discarded as warm-up, a fixed-seed RNG so operating-system entropy doesn't leak into
the timing, and a pinned release profile. The run was judged Stable: no operation moved
more than 4% between passes.
| Operation | ML-KEM-768 alone | Hybrid v1 (X25519 + ML-KEM-768, HKDF) | Hybrid v2 (X-Wing) |
|---|---|---|---|
| Key generation | 51.7 µs | 97.2 µs (1.88×) | 98.1 µs (1.90×) |
| Encapsulate | 54.6 µs | 155.8 µs (2.85×) | 151.7 µs (2.78×) |
| Decapsulate | 64.0 µs | 114.4 µs (1.79×) | 109.4 µs (1.71×) |
Adding X25519 nearly doubles key generation and almost triples encapsulation. Encapsulation takes the biggest hit because the sender does a full X25519 key generation and a Diffie-Hellman on top of the ML-KEM work.
The two hybrid constructions cost about the same. X-Wing (draft-connolly-cfrg-xwing-kem) is within 5% of our original HKDF combiner on every operation. X-Wing's combiner also binds the X25519 ciphertext and public key into the shared secret, which ours does not, so it is the one we recommend for new deployments.
The full tables, confidence intervals and methodology are in BENCHMARKS.md.
We pay it anyway, on purpose
pqc-kem ships the hybrid on by default. Everything else we build aims to be
post-quantum only, so this is a deliberate exception, and it applies to key exchange alone.
The reason is the threat model. An adversary can record an encrypted session today and decrypt it years from now, once a cryptographically relevant quantum computer exists, or once someone finds a flaw in a new algorithm. ML-KEM is young. If a structural weakness in it turns up in 2031, every session recorded in 2026 with ML-KEM alone is exposed, and nothing we do in 2031 can re-encrypt traffic an attacker already holds.
A hybrid stays secure as long as either half holds. X25519 falls to a quantum computer, and ML-KEM is designed to resist one. For a recorded session to be exposed, both have to fail.
Signatures are different. A broken signature scheme can be rotated: you revoke keys, issue
new ones and re-sign. There is no signed equivalent of "recorded today, decrypted later."
That is why our signature crate, pqc-sig, keeps its Ed25519 hybrid off by default,
while pqc-kem keeps its X25519 hybrid on.
The rule we follow: hedge where a break is permanent, not where it can be repaired.
About 100 microseconds per handshake is the price of that hedge. For a session that lasts longer than a single request, it is cheap insurance.
Try it
[dependencies]
pqc-kem = "0.3"
HybridKemKeypair is the default hybrid, and XWingKeypair is X-Wing. Both build for
wasm32-unknown-unknown and no_std. The
examples repository has a runnable key exchange.
pqc-kem has not been independently audited and is not FIPS 140-3 validated. "FIPS 203"
means the algorithm follows the standard, not that the code is certified. Known issues are
in its SECURITY.md.
These are the primitives 0x307 builds its own products on. The gateway behind
8gentz.io uses this X25519 + ML-KEM-768 hybrid for its session key
exchange, and is moving onto pqc-kem itself.