The Internal Push for Post-Quantum Cryptography
Swapping cryptographic algorithms for their post-quantum counterparts is theoretically straightforward. In practice, applying that swap across the dozens of services and programming languages that back Cloudflare's internal network requires careful planning. The company's goal is to make every internal connection quantum-secure, and it has begun testing that transition with three specific systems: Logfwdr, gokeyless, and Cloudflare Tunnel.
The challenge is not just about swapping algorithms. The migration must not diminish the security properties of the protocols involved, nor hurt performance, and it has to respect existing compliance requirements, such as FedRAMP certification efforts. Those constraints drove decisions about how to introduce post-quantum cryptography, which protocols to target, and which services to migrate first.
A Hybrid Approach for TLS
The most logical starting point for the migration is TLS, the protocol securing most of Cloudflare's internal traffic and the bulk of the internet. Of TLS's three core security properties—integrity, authentication, and confidentiality—confidentiality is the most urgent. An attacker can record encrypted traffic today and decrypt it later once a sufficiently powerful quantum computer exists, exposing all past and current communications.
Cloudflare's plan focuses on the TLS 1.3 key exchange. In a standard handshake, the client and server exchange key shares and derive a shared "master secret" used to encrypt the session. Adding post-quantum algorithms to that key exchange ensures the resulting master secret is quantum-safe.
However, most post-quantum algorithms lack the years of scrutiny given to classical ones. To hedge against a future break, Cloudflare is adopting a "hybrid" mechanism that concatenates two shared secrets:
- A classical secret (Z) derived via a FIPS-approved mechanism like the P-256 elliptic curve.
- An auxiliary secret (T) derived from a post-quantum algorithm, in this case Kyber-512.
Combining both secrets yields a final master secret that is secure even if the post-quantum component is compromised, while also producing a FIPS-suitable output as defined in SP 800-56C Rev. 2.
The implementation targets specific TLS libraries: BoringCrypto and the compiled version of Go with BoringCrypto. Cloudflare's own Kyber-512 implementation was added to these libraries, along with the hybrid handshake logic. A key benefit of TLS is its negotiation mechanism: if one endpoint doesn't support post-quantum algorithms, the handshake simply falls back to a mutually supported classical algorithm rather than failing outright.
Authentication, the other quantum-threatened property of TLS, is being deferred. Certificate-based authentication depends on external systems and certification authorities across the broader internet ecosystem. Migrating that would require a coordinated broad industry effort. Cloudflare's internally hosted PKI makes that easier to do in the future, but it is not part of the current phase.
Post-Quantum Logfwdr
The first migration test involved Logfwdr, an internal Go service that handles structured logs, sending them over TLS to a subservice called Logreceiver, which writes them to Kafka. Logfwdr's simple architecture, long-lived connections, and high traffic volume made it an ideal pilot.
Cloudflare created a dedicated "pq-stream" copy of the HTTP stream and compiled both Logfwdr and Logreceiver with the modified TLS libraries containing the hybrid post-quantum key exchange. The results showed that the post-quantum TLS handshakes were actually faster than the classical ones, a finding attributed to the use of Kyber-512 (a lattice-based algorithm) and the fact that the test services ran TLS 1.3 while the classical deployments were still on TLS 1.2.
The average batch send duration also came in lower for the post-quantum stream than the non-post-quantum one. Part of that difference comes from the fact that the quantum-protected data wasn't yet routed to Kafka, whose connection remains classical. The testing ran for several weeks with no failures, giving confidence to move forward with migrating Logfwdr stream by stream until the whole service is post-quantum.
Post-Quantum gokeyless
gokeyless is Cloudflare's system for separating servers from long-term TLS private keys, which are held on key servers either at customer sites or within Cloudflare (gokeyless-internal). Requests flow through Keynotto, a Rust service that mints RSA and ECDSA signatures, with a small subset forwarded to gokeyless-internal.
Migrating the transport connections of this system initially targeted the TLS handshake between Keynotto and gokeyless-internal. Since Keynotto is written in Rust, this required a separate integration effort into the rustls codebase. The approach there was different: rather than forcing users to pick specific cipher suites and key shares, the library exposes a simple boolean or API call to enable the post-quantum hybrid mechanism.
That test proved successful, and the next steps include integrating the post-quantum handshake into the real Keynotto-to-gokeyless-internal connection and eventually planning a migration path for the customer-side gokeyless servers.
Post-Quantum Cloudflare Tunnel and Beyond
Cloudflare Tunnel connects customer infrastructure to Cloudflare's network via long-lived TCP or QUIC connections through the cloudflared daemon. The easier target there is the connection between Cloudflare's network and cloudflared, but deeper inspection revealed a more interesting find.
The traffic goes through Tunnelstore, a Kubernetes deployment fronted by an ingress made of Envoy and Contour. Envoy uses BoringSSL for TLS, and swapping libraries in Envoy appeared complex until it was found that a patched BoringSSL with the post-quantum algorithms could be referenced in Envoy's Bazel build file. Contour, which Cloudflare runs under its own patched version, will likewise need an update with the Go library containing the post-quantum support.
Migrating this Kubernetes ingress would not only make Tunnel completely quantum-safe but would also benefit every other internal service that routes through it. Initial tests with the modified Envoy and Contour libraries were successful, and plans are in place to test the full ingress ecosystem.
What Comes Next
The core work is done: Cloudflare now has modified TLS libraries in Go, Rust, and C, each supporting the hybrid post-quantum key exchange. Two services are ready for deployment, and the shared Kubernetes ingress could be upgraded. The longer-term ambition moves beyond the edge of Cloudflare's network to the connections where customers ultimately meet Cloudflare's infrastructure, a topic considered the next stage of this project.
