Chrome Default Hybrid Post-Quantum Key Exchange (X25519Kyber768 → ML-KEM)

A dated reading of what is claimed, reported, and independently verified in the current evidence.

Current reading

Readiness band and full integer triple

AI-assisted assembly · derived results

Readiness band

Ready

Primary summary from verified readiness

Evidence strength Critical

Decision

Agent-assisted assessment · independently reviewed · 2026-10-05

Suitable for routine Chrome HTTPS use when the server negotiates X25519MLKEM768 and the network path is compatible.

Why: Default deployment and substantial observed traffic support production use. Compatibility failures have occurred with inspection equipment; key exchange alone does not complete post-quantum website authentication.
Next: Keep Chrome and TLS infrastructure updated, confirm the negotiated group in DevTools or server logs, and test inspection paths and constrained networks before broad rollout.

Constraints

Post-quantum protection requires server support for TLS 1.3 and X25519MLKEM768; offering the group does not ensure selection.
For post-quantum negotiation, Kyber-only servers need standardized ML-KEM support because Chrome 131 removed the prestandard Kyber group.
Older TLS inspection engines can cause connection failures and require updates.
Larger handshakes add bandwidth; latency impact depends on the network and implementation.

Evidence summary

AI-assisted assembly

Counts and dates only. Raw signals, private excerpts, trust records, and internal corpus material are not published here.

Publication record

Revision 4