demo · v147 · security · post-quantum

Key Exchange Benchmark

Side-by-side performance comparison of X25519 (classical) versus X25519Kyber768 (post-quantum hybrid), using the Web Crypto API for real key generation and simulated Kyber operations.

X25519
Classical elliptic curve Diffie-Hellman
Ops/second—
Key gen time—
Derive time—
Public key size32 bytes
Security bits~128 (classical)
Quantum safe?✗ No
throughput (relative)
—
X25519Kyber768
Post-quantum hybrid (X25519 + ML-KEM-768)
Ops/second—
Key gen time—
Encaps time—
Public key size1,184 bytes (Kyber part)
Security bits~192 (classical+PQ)
Quantum safe?✓ Yes (hybrid)
throughput (relative)
—
Harvest-now-decrypt-later attack window
Harvest year 2024
Quantum arrives 2035

TLS ClientHello handshake overhead
X25519 key share
32
bytes
Kyber768 key share
1,184
bytes
Hybrid key share total
1,216
bytes (38× larger)
Ciphertext (server→client)
1,088
bytes (Kyber part)
Extra TCP round trips
0
same 1-RTT TLS 1.3
Typical overhead
<1
ms extra per handshake

Byte visualisation — each block = 32 bytes of ClientHello key_share extension:

X25519 (1 block, 32 bytes)    Kyber768 additional bytes (37 blocks, 1,184 bytes)

why size matters

The 1,216-byte hybrid key share is ~38× larger than the 32-byte X25519 share. During Chrome's initial Kyber rollout in 2023, some corporate network middleboxes rejected TLS ClientHellos with unexpectedly large key_share extensions — causing connection failures. Chrome later limited Kyber to certain server configurations to avoid this. The tradeoff is temporary: as server ecosystems update, the hybrid can be deployed universally.

see also

implementation reference

Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗