As laboratories around the world race to build out a cryptographically relevant quantum computer , we at Cloudflare are racing towards a 2029 target deadline for full post-quantum readiness . While we’ve already transitioned many of our products to post-quantum encryption, we still have work to do to support post-quantum authentication and achieve full post-quantum readiness across our platform.
We’re taking a maximalist stance (“PQ everything!”) , because as an infrastructure provider to the world, we want to give our customers the peace of mind that using Cloudflare ensures that their traffic is future-proofed against quantum adversaries. But how does one accomplish such a massive migration at an organization of our size and scale?
After all, cryptography is the base layer for almost all of the world’s digital systems, including the software services and the networking protocols that power our platform. To drive our PQ migration, we have three key goals. First, we want to help our product and engineering teams understand how cryptography is being used and how they should be upgrading it.
This should cover both the upgrades to post-quantum encryption and to post-quantum authentication. Many of our products have already been upgraded to post-quantum encryption over TLS 1. 3, but we still want to cover the long tail of TLS connections, as well as upgrade any other uses of public-key encryption.
Meanwhile, it’s still early days for our deployment of post-quantum authentication. Next, we want to provide progress metrics for the migration. These might include per-repository and per-product counts of the use of classical and post-quantum cryptography.
Finally, we want to surface prerequisites early. If our products or platform rely on protocols that don’t yet have a PQ migration plan (because PQ variants of the system have not yet been considered, because PQ standards do not exist or lack consensus, or because software libraries or other key ecosystem components do not yet have PQ support), then we need to know now.
That way we can work with the relevant stakeholders, standards bodies and ecosystems to help drive their PQ migration plans, so that we can meet our own 2029 PQ migration timeline. This post is the story of how we’re going about this. We explain how we turned to AI to help us solve some of our problems and how we’re developing an internal tool called CryptoLabe to help us.
CryptoLabe is named after the mariner’s astrolabe, a navigation instrument refined by Portuguese navigators. Just as an astrolabe helped sailors determine where they were and chart a course, CryptoLabe helps us discover cryptography in our code, understand how it is used, and chart a path to post-quantum migration. CryptoLabe is highly specialized to our internal systems (our repositories, our ticketing systems, and internal documentation processes) and still evolving as we continue its development, so we aren’t making it available to customers.
Nevertheless, we are sharing our learnings so that other organizations can build upon our efforts as they work through their own PQ migration journey. The scale of the problem The software that powers most Cloudflare products lives inside our single centralized source control management platform. This means we can find most uses of cryptography across our platform by just looking through our codebase.
While the centralization of our codebase is a marked advantage for us, we still need to contend with three challenges that come with the scale of this problem. First, our code is spread across many repositories. Second, cryptography rarely announces itself plainly in the code.
Instead, it hides in shared libraries that a repository imports but may or may not actually call upstream and protocol defaults, like a TLS 1. 3 listener that is configured to negotiate a classical key exchange such as X25519 rather than post-quantum X25519MLKEM768 configuration files that select algorithms far away from the code that uses them, like a TLS responder whose key exchange protocols are pinned in a YAML file stored in a different repository code paths that are dead, test-only, or on a path to being deprecated Third, cryptography discovery is about more than just pattern matching.
Grepping for certain algorithm names (e. g. “RSA” or “X25519”) overcounts, because it finds cryptography in unused code.
Grepping also undercounts, because it misses defaults and indirect uses in dependencies and configuration. Most importantly, it can't tell you how the cryptography is used. A classical ECDSA signature could be part of a JWT , IPsec , TLS , or SSH , and each has a completely different migration path.
Many uses also depend on the other side of the connection: a TLS server may support both post-quantum key exchange and classical key exchange; the one it chooses to use would depend on the client. Turning to AI It turns out that AI is pretty good at doing more than just grepping. A model can search a codebase, follow evidence across files, and return structured analysis.
It can also enrich findings by pulling information from other sources, like our internal documentation and ticketing systems. In fact, AI can even explain how cryptography is being used and how it should be updated. We’ve been putting that idea to the test as we develop CryptoLabe.
As we said before, our first two goals are to (1) discover and understand the use of cryptography in our codebase, and also (2) to get metrics on the state of our PQ migration. Towards these goals, our current implementation of CryptoLabe performs scans in two stages, as shown in the figure below. The first “discovery” stage starts by mapping the repository.
It then searches for cryptography through source, configuration, manifests, lockfiles, scripts, tests, and documentation.
Originally published at blog.cloudflare.com
