demo · v147

Handshake bytes

The classical X25519 key share is 32 bytes. The hybrid X25519MLKEM768 share is 1,216 bytes — a 38× jump. Visualise the byte budget for each negotiated group, and see how the ClientHello swells once you light up PQ.

Shipped: X25519Kyber768 (and the standardised X25519MLKEM768) are on by default in Chrome 147 desktop. This page reports your browser's TLS context where it can, and otherwise visualises the byte budget from spec values.
ClientHello key-share bytes—
ServerHello key-share bytes—
Round-trip extra over classical—

ClientHello key_share

ServerHello key_share / ciphertext

X25519 share (32B) ML-KEM-768 enc/cipher (1184B / 1088B) protocol overhead

Live: what did your browser negotiate?

querying secure context…

Why the size matters

  1. Middleboxes that hard-code "TLS ClientHello fits in one packet" reject oversized hellos. Chrome's rollout caused real-world breakage when the ClientHello exceeded ~1.5KB.
  2. Every connection pays the cost, even to servers that don't speak PQ — so Chrome usually advertises both X25519MLKEM768 and a backup X25519 share, paying an extra 32B for the backup.
  3. On mobile networks, the extra round-trip-trigger packet is measurable; on connection setup, it's typically <1ms.
// rough byte budgets (per draft-ietf-tls-ecdhe-mlkem and RFC 9180):
//
//   X25519           share: 32     bytes
//   ML-KEM-768       share: 1184   bytes (client encaps. key)
//   ML-KEM-768       ct:    1088   bytes (server ciphertext)
//
// Hybrid X25519MLKEM768 ClientHello key_share:
//   32  (X25519) + 1184 (MLKEM)         = 1216 bytes
// Hybrid X25519MLKEM768 ServerHello key_share:
//   32  (X25519) + 1088 (MLKEM ct)      = 1120 bytes

see also

implementation reference

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