v147 · Post-Quantum Timeline
Post-Quantum Timeline
Visualise when classical TLS key exchange becomes vulnerable to quantum "harvest now, decrypt later" attacks — and where Chrome's X25519Kyber768 hybrid sits on the quantum readiness timeline.
Algorithm security lifetimes
at-risk
transition
PQC
Chrome 147
Harvest now, decrypt later calculator
An adversary harvesting TLS traffic today can decrypt it when a quantum computer arrives. Adjust both sliders to see the risk window.
Hybrid construction details
Walk through the draft TLS 1.3 payloads. The values are not JavaScript APIs; they are the wire-format pieces that explain both the security property and the compatibility risk.
Deployment edge cases
The hybrid exchange is negotiated below the web platform. These scenarios show what a site can and cannot observe when deployment goes wrong.
Algorithm comparison
| Algorithm | Type | Key size | Quantum-safe | Chrome 147 status |
|---|---|---|---|---|
| RSA-2048 | Classical KEX | 256 bytes | No (Shor's algorithm) | Deprecated for TLS 1.3 |
| X25519 | ECDH (classical) | 32 bytes | No (quantum ECDLP) | Supported, being superseded |
| Kyber768Draft00 | Pre-standard PQ KEM | 1184 bytes public key | Yes (hybrid component) | Used inside the draft hybrid group |
| X25519Kyber768 | Hybrid KEX+KEM | 1216-byte client share | Yes (hybrid) | Default in Chrome; v147 removes temporary opt-out |
| ML-KEM successors | Standard PQ KEM | 1568 bytes (pub) | Yes (highest security) | Future roadmap |
References
- ChromeStatus feature 5257822742249472
- IETF X25519Kyber768Draft00 hybrid key agreement draft
- Feature conformance probe
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗