Cloudflare built an AI tool to hunt its own old crypto
Cloudflare's internal CryptoLabe tool scans its codebase for classical cryptography using AI, as the company works towards full post-quantum readiness by 2029 and admits the tool is still learning what it does not know.
Cloudflare has built an internal AI tool called CryptoLabe that combs its entire codebase for classical cryptography, part of a push towards full post-quantum readiness by 2029. The company described the tool in a blog post on 29 September, and was honest about the limits: it is built for Cloudflare's own repositories, ticketing systems and documentation, it is still evolving, and it is not being offered to customers.
The problem it solves is scale. Cloudflare has already moved many of its products to post-quantum encryption over TLS 1.3, but it still has a long tail of TLS connections to upgrade, plus all the other places public-key encryption is used, and it has barely started on post-quantum authentication. Cloudflare describes its stance as “maximalist”, or “PQ everything”, on the grounds that it is an infrastructure provider to the world. Anything protected by classical key agreement today is exposed to harvest-now-decrypt-later attacks, where traffic is recorded now and opened later by a quantum computer running Shor's algorithm.
Why grepping the codebase does not work
Most Cloudflare product code lives in one centralised source-control platform, which helps, but three things get in the way. The code is spread across a great many repositories. Cryptography rarely announces itself, hiding instead in shared libraries a repository imports but may never call, in protocol defaults, in configuration files sitting in a different repository, and in code paths that are dead, test-only or on the way out. Examples from the post include a TLS 1.3 listener silently negotiating the classical X25519 key exchange rather than the post-quantum hybrid X25519MLKEM768, and a responder whose algorithm choices are pinned in a YAML file somewhere else entirely.
A plain search makes that worse in both directions. Grepping for “RSA” or “X25519” overcounts, because it finds cryptography in code nobody runs. It undercounts, because it misses defaults and indirect uses buried in dependencies and configuration. And it cannot say how a piece of cryptography is used, which is the part that actually decides the work: a classical ECDSA signature could belong to a JWT, IPsec, TLS or SSH, and each of those has a completely different migration path. Some uses also depend on the other end of the connection, since a TLS server may support both post-quantum and classical key exchange and let the client choose.
Two passes, then a classification
CryptoLabe works in two stages. A discovery pass first maps the repository, then searches through source, configuration, manifests, lockfiles, scripts, tests and documentation for key agreement, signatures, asymmetric encryption, PKI, tokens, credentials and hardware security module integrations, producing a set of raw observations. Each observation then feeds an analysis pass, which re-checks it against the source code, investigates how the operation is used at runtime and what role the repository plays, and can pull in related code from other repositories to complete the picture.
If the evidence will not support a conclusion, CryptoLabe is designed to say so: it can label a finding “More evidence needed”, “External dependency” or “Unknown” instead of guessing. Otherwise it sorts findings into categories such as classical encryption, classical signature, classical token, post-quantum-ready hybrid key exchange and post-quantum-ready. The classical token category exists because the scans turned up a lot of RS256 and ES256 JSON Web Tokens, and the hybrid category covers X25519MLKEM768, which Cloudflare says is the most prevalent post-quantum use in its codebase. Each finding turns into a report aimed at two readers: a product manager who needs to know what the migration means for their product, and an engineer who needs enough detail to carry it out.
Running on Cloudflare's own developer platform
The tool is itself a Cloudflare customer. A scanner Worker runs the scans and an inventory Worker serves the dashboard, exposes an API and stores results in a D1 database, with the two talking over service bindings. Cloudflare says it is still reviewing findings against source code with engineers and does not yet have a ground-truth dataset for reproducibly comparing prompt versions. The stated goals are to help teams understand how cryptography is used, to produce per-repository and per-product progress metrics, and to surface prerequisites early, so that protocols, standards bodies and libraries without a post-quantum plan are identified while there is still time to chase them.
Our opinion
The interesting thing here is not that an AI tool reads code. It is that Cloudflare has admitted the part everyone building this kind of system eventually hits: the hard bit is not finding cryptography, it is deciding whether a finding matters, and a model that guesses badly is worse than a grep because its answers look considered. Publishing the refusal cases, the catch-all categories and the absence of a ground-truth benchmark is more useful than another confident automation announcement.
The 2029 deadline is the part worth watching. Cloudflare is candid that post-quantum authentication is barely started, and authentication is where most of the ecosystem pain lives, because it depends on certificates, hardware, browsers and other people's software rather than on one company's deployment schedule. An internal tool can find every classical signature in the codebase. It cannot make the rest of the internet migrate, and that is the actual deadline.