Defending against future threats: Cloudflare goes post-quantum

Why hybrid key agreement matters now

Every encrypted connection established today carries a hidden deadline. A sufficiently powerful quantum computer — expected within the next 15 to 40 years — will be able to break the asymmetric cryptography underpinning the modern Internet. The risk is not just to future communications: data recorded today can be stored and decrypted retroactively once such a machine exists.

Post-quantum (PQ) cryptography is designed to resist that threat. In July 2022, after a six-year international competition, NIST announced the algorithms it will standardize, with final standards expected in 2024. Cloudflare is not waiting for those standards to land. As of today, all websites and APIs served through Cloudflare support post-quantum hybrid key agreement as a beta service — enabled by default, at no cost. If the client supports it, the connection to Cloudflare's network is protected against future quantum decryption.

The decision to deploy now is deliberate. Post-quantum algorithms are new, and even years of scrutiny cannot rule out a catastrophic break. That is why the deployment uses hybrid key agreement: a proven classic algorithm paired with a new post-quantum one. Security is only one concern; practical deployment is another. While the Internet's protocols were designed to accommodate cryptographic transitions, real-world code is messy. Middleboxes may choke on larger post-quantum keys; other failures have not even been observed yet because these algorithms are so new. Early deployment, in cooperation with browser vendors and other clients, is the way to surface and resolve those issues before quantum computers arrive.

Secure browsing over HTTP or QUIC relies on the Transport Layer Security (TLS) protocol. Two versions dominate traffic today: TLS 1.3 at roughly 90%, and the older TLS 1.2 at about 10% and declining. Post-quantum support is currently available for TLS 1.3 only, which is significantly easier to extend than its predecessor. The protocol's purpose is twofold:

• Confidentiality and integrity — no third party can read or tamper with data undetected.
• Authenticity — the client is certain it is talking to the intended server, not an imposter.

The cryptographic building blocks

TLS relies on three distinct types of cryptography to reach these goals.

Symmetric encryption — specifically Authenticated Encryption With Associated Data (AEAD) — handles confidentiality and integrity. A single shared key encrypts and decrypts the data; tampering produces a decryption error. TLS 1.3 commonly uses ChaCha20-Poly1305 and AES128-GCM. A naive reading of quantum threats suggests moving to 256-bit keys to blunt Grover's algorithm, but in practice Grover's does not parallelize well, so the existing AEADs remain adequate.

That leaves the question of how two parties agree on that shared key without an eavesdropper learning it. This is the domain of asymmetric key agreement. Today the de facto standard in TLS 1.3 is X25519, an Elliptic Curve Diffie–Hellman (ECDH) protocol whose security rests on the elliptic curve discrete logarithm problem — exactly the kind of problem a quantum computer using Shor's algorithm solves with ease. Post-quantum key agreement, such as Kyber, is the intended replacement.

Key agreement alone only defends against passive eavesdropping. An active man-in-the-middle can negotiate separate shared keys with each party and re-encrypt traffic in both directions. The third piece — digital signatures — closes that gap. Algorithms like RSA and ECDSA use a private key to sign messages and a public key to verify them. These signatures authenticate websites through TLS certificates. Both RSA and ECDSA are quantum-vulnerable, but they have not yet been replaced with post-quantum signatures. The urgency is lower: authentication needs upgrading only before a large quantum computer is built, whereas data protected by vulnerable key agreement today can be harvested now and cracked later. Replacing post-quantum authentication will nevertheless be a substantial challenge in its own right.

The TLS 1.3 handshake under the hood

A TLS connection begins with a handshake, through which the server is authenticated and a shared key is derived. The client opens with a ClientHello listing the AEADs, signature algorithms, and key agreement methods it supports. To save a roundtrip, the client may guess the server’s preferences and include one or more client keyshares right away — either that guess is correct, or the server responds with a HelloRetryRequest to prompt a corrected attempt.

Key agreement and authentication

A keyshare is used differently depending on the underlying scheme. Kyber is a Key Encapsulation Mechanism (KEM), whereas X25519 is a Diffie–Hellman (DH) style agreement. The mechanics differ, but in TLS the shape is identical: the client sends a keyshare, the server derives the shared key from it and replies with its own keyshare, and the client computes the same shared key from that.

Once the server receives the ClientHello, it selects an AEAD, a signature algorithm, and a compatible keyshare. It answers with a ServerHello carrying the chosen AEAD and its own keyshare, after which it can begin encrypting traffic. The server also attaches a handshake signature covering the transcript so far, along with its certificate chain. The client verifies both the certificate authority’s trust and the signature against the exact messages it sent — this authenticates the server and guards against downgrade attacks.

Why downgrade resistance matters

The migration to post-quantum cryptography cannot happen overnight. During the transition, clients and servers will continue offering classical key agreements as a fallback. TLS 1.3 negotiates this gracefully, but the keyshares and supported-algorithm lists are transmitted in plaintext. An attacker could try to strip the post-quantum options and force a classical-only connection — a downgrade attack.

The handshake signature is what foils this: it is computed over the entire message exchange, including the list of supported key agreements the client sent. If an attacker alters that list, the server may not notice, but the client will — its verification of the server’s signature will fail against the list it actually sent. The corresponding protections in TLS 1.2 are considerably more intricate, which is a key reason Cloudflare is reluctant to retrofit post-quantum security there.

Finishing the handshake

The server’s final message is a server finished — a message authentication code (MAC) over the transcript. The handshake signature does most of the heavy lifting, but the MAC is important in modes that lack it, such as session resumption.

The client, now holding the server keyshare, computes the shared key. That key is never used directly; it is mixed with the transcript to derive separate keys for the handshake and for the main connection. The client sends its own MAC, and encrypted application data can then flow. A HelloRetryRequest appears when the client’s keyshare guess is off: if both parties support a common key agreement but the client sent no share for it, the server can request one, and the client retries with a new ClientHello. A server may also ask for a preferred algorithm even if a workable share was offered — for instance, requesting a post-quantum keyshare the client supports but didn’t send.

HelloRetryRequests are uncommon in practice because essentially all servers support X25519 and about 98% of clients send an X25519 keyshare. Earlier, P-256 was standard and many browsers sent both P-256 and X25519 shares to avoid a retry. As the next sections will show, sending multiple post-quantum keyshares may not be a luxury Cloudflare can afford.

What Cloudflare deployed

Cloudflare has enabled the X25519Kyber512Draft00 and X25519Kyber768Draft00 key agreements, using TLS identifiers 0xfe30 and 0xfe31 respectively — the same combinations it trialed on a limited set of zones earlier in July. These are hybrid schemes pairing the classical X25519 with the post-quantum Kyber512 or Kyber768. The ordering matters: even if Kyber were broken, the connection would retain X25519-level security.

Kyber is currently the only key agreement NIST has selected for standardization. It is notably light on CPU — faster than X25519 itself — but its keyshares are substantially larger.

Kyber is expected to change in minor but backwards-incompatible ways before NIST finalizes its standard in 2024. The TLS working group has likewise not yet settled the integration details, including the exact hybrid construction. Cloudflare will adopt the final versions promptly but does not intend to support these interim key agreements long-term; they are offered as a beta service. Updates will be posted at pq.cloudflareresearch.com and announced on the IETF PQC mailing list.

With the theory and the deployed algorithms in place, the remaining question is where real-world deployment breaks down.

Deployment risks: ossification, fragmentation, and QUIC edge cases

Rolling out new cryptographic primitives is rarely just a matter of swapping algorithms. History shows that protocol flexibility tends to erode when it isn’t exercised, a phenomenon known as protocol ossification. The TLS 1.3 deployment was painful precisely because of this: the version field in the ClientHello was supposed to signal the highest supported version, but in practice many servers crashed instead of falling back when they saw an unfamiliar value.

The workaround was to have TLS 1.3 masquerade as TLS 1.2, including legacy fields in the ClientHello, while moving the real version negotiation into a new extension. TLS 1.2 servers ignore the extension and proceed as usual; TLS 1.3 servers pick it up and continue accordingly.

To prevent future ossification, browsers now deliberately advertise dummy versions and other bogus values in various parts of the handshake. This practice, standardized in RFC 8701 and called GREASE (Generate Random Extensions And Sustain Extensibility), keeps implementations honest by forcing them to handle unexpected inputs. The approach extends to key agreement identifiers: today, roughly 40% of browsers send two client keyshares — one real X25519 and one bogus 1-byte keyshare — to preserve flexibility in key agreement negotiation.

Grease helps, but it has limits. The real concern with post-quantum keyshares is their size, not just their presence.

Large ClientHellos and packet fragmentation

The hybrid post-quantum keyshares are substantially larger than classical ones. Kyber-based hybrids come in at 832 bytes for the Kyber512 variant and 1,216 bytes for Kyber768, compared to X25519’s 32 bytes. Some implementations may simply fail when confronted with such large keyshares.

The 832-byte Kyber512 keyshare barely fits into a single network packet; the 1,216-byte Kyber768 keyshare typically forces the ClientHello to fragment across two packets. While operating system TCP stacks usually handle reassembly transparently, optimized middleboxes and load balancers that inspect packets individually may not track partial messages across connections — and if they don’t, the connection fails.

QUIC adds a twist

HTTP/3, built on QUIC, introduces a different complication. In QUIC, the server chooses the connection ID, unlike TCP where the client simply picks a port. The client sends a random connection ID in its initial packets because it doesn’t yet know the server’s preferred one. If a large ClientHello requires multiple initial packets, the client uses the same random connection ID for all of them. Although QUIC allows multiple initial packets, a QUIC load balancer that encodes the backend machine in the connection ID may not expect this pattern and may be unable to associate the packets with an underlying connection.

Performance concerns beyond hard failures

Hard failures aren’t the only risk. Soft failures — performance degradation — can be just as damaging: if a site loads too slowly, it might as well be broken. A 2019 joint experiment with Google deployed two post-quantum key agreements: CECPQ2 based on NTRU-HRSS and CECPQ2b based on SIKE. NTRU-HRSS is similar to Kyber, though slightly larger and slower. Results were encouraging.

The focus remains on tail performance: the goal is a smooth transition for everyone, from the fastest to the slowest clients on the Internet.

Getting involved in testing

The Internet is a heterogeneous environment, and surfacing all the issues requires a broad base of diverse testers. Cloudflare is working with browser vendors to add support for these key agreements, but browsers may not exist in every network environment.

For those who want to help, the suggestion is to route a small portion of traffic to Cloudflare domains using these new key agreement methods. Open-source forks are available for BoringSSL, Go, and quic-go, with sample code for BoringSSL and Go linked from the experiment announcement. Issues can be reported to [email protected], and discussions happen at the IETF TLS working group.

What’s next

The move to a post-quantum secure Internet is urgent, but it won’t be effortless. Cloudflare has already deployed a preliminary post-quantum key agreement across all its servers, covering a meaningful portion of the Internet, so testing of the large migration can begin now. The hope is that by 2024, when NIST finalizes Kyber, the groundwork will be in place for a smooth transition.1

1These post-quantum key agreements are supported only in TLS 1.3-based protocols, including HTTP/3, with one exception: hybrid key exchanges are disabled for websites in FIPS mode.