X25519Kyber768 key encapsulation for TLS

concepts

1. TLS Inspector

   Calls a handful of well-known endpoints and reports which key-exchange algorithm Chrome negotiated. A simple way to tell whether a given site is "harvest-now-decrypt-later" resistant.

2. Handshake bytes

   The X25519 share is 32 bytes; the hybrid X25519MLKEM768 share is 1,216 bytes. Visualises the byte budget per negotiated group and explains why oversized ClientHellos broke real-world middleboxes during Chrome's rollout.

3. Post-Quantum Timeline

   Timeline of classical and post-quantum algorithm security lifetimes. Adjust "harvest year" and "quantum arrives" sliders to see the "harvest now, decrypt later" attack window — and why X25519Kyber768 closes it while RSA-2048 and plain X25519 do not.

4. Key Exchange Benchmark

   Side-by-side performance comparison of X25519 (classical, via Web Crypto) versus X25519Kyber768 (post-quantum hybrid, simulated). Shows ops/second, key generation time, and key/ciphertext sizes. Includes a harvest-now-decrypt-later timeline slider and a byte-level visualisation of the TLS ClientHello size difference.

5. Compatibility Lab

   Probes adjacent WebCrypto algorithm support and Resource Timing protocol tokens. Runs a live X25519 key generation and derivation test, explains why nextHopProtocol cannot identify the TLS KEM, and models server, middlebox, policy, and legacy fallback paths.

why it shipped

"Harvest now, decrypt later" is the canonical post-quantum threat model: an adversary records encrypted traffic today and decrypts it when a sufficiently powerful quantum computer becomes available. Hybrid post-quantum key exchange shuts that strategy down. X25519Kyber768 layers a NIST-standardised lattice-based key-encapsulation mechanism on top of the well-understood X25519 elliptic-curve construction, so if either component holds, the session key stays secret. Chrome ships it client-side so any server that opts in immediately benefits.

references

• ChromeStatus entry
• Chrome 124 launch post