Cloudflare sent AI hunting for old cryptography before the quantum deadline

THE SIGNAL IN ONE SENTENCE

Cloudflare is trying to answer one of the least glamorous questions in post-quantum security: where, exactly, is all the old cryptography hiding? The answer is not a tidy inventory. It is scattered through source files, configuration, manifests, lockfiles, scripts, tests, shared libraries, protocol defaults, hardware integrations and dependencies owned by other teams. A search for RSA or X25519 will find plenty of irrelevant references and miss plenty of real behavior. It also will not explain whether an algorithm protects a JSON Web Token, signs a certificate, negotiates a TLS connection or lives inside a custom protocol. Those uses may share a name and have completely different migration paths. On September 29, Cloudflare described CryptoLabe, an evolving internal system that uses AI to discover and explain cryptography across its codebase. The name comes from the mariner's astrolabe. The metaphor fits. CryptoLabe is meant to show engineers where they are and help chart a route. It does not steer the ship by itself. Cloudflare has set a 2029 target for full post-quantum readiness. The company says many products already support post-quantum encryption through TLS 1.3, while post-quantum authentication remains earlier in deployment. Its three stated goals are to help teams understand and upgrade cryptography, measure migration progress by repository and product, and reveal prerequisites that no single team can solve alone. That last category is where inventories become useful. A product team may discover that it uses a classical signature but cannot replace it until a library, identity provider, browser, certificate authority, protocol or standard is ready. The blocker is not one line of code. It is an ecosystem relationship. CryptoLabe scans in two stages. The discovery stage maps a repository and searches source, configuration, dependency files, scripts, tests and documentation. It looks for key agreement, signatures, asymmetric encryption, public-key infrastructure, tokens, credentials, hardware security modules and related behavior. The output is a set of raw observations, not final findings. The analysis stage returns to the source, checks each observation, investigates runtime use, identifies the role of the repository and follows dependencies into other repositories when necessary. It then reviews its own conclusions for missing or conflicting evidence such as configuration overrides, test-only code and assumptions about runtime behavior. That loop is more capable than keyword search because it can connect evidence across files and systems. It is also still an inference system. A convincing explanation can be wrong, a dependency can be dormant, a default can be overridden at deployment, and a cryptographic operation can be selected by a client or partner outside the scanned repository. Cloudflare is admirably direct about this. The company says it does not yet have a ground-truth dataset for reproducibly comparing prompt versions. It is not convinced that CryptoLabe has complete coverage of cryptographic use. Different scanning approaches find different things, and every finding still needs review by engineers who understand the system. That is the most important sentence in the project. AI is the mapmaker. The system owner remains the surveyor who checks whether the bridge actually exists. The architecture reflects that division of labor. An inventory Worker serves the dashboard and API and stores results in D1. A scanner Worker runs scans. Service Bindings connect them. Each repository gets a persistent coordinator built with a Durable Object. A bounded queue limits concurrency, while Workflows persist progress through discovery, analysis, merging and publication. The scan downloads a repository at an exact commit and stores that snapshot in R2. Each analysis runs in a fresh, short-lived Sandbox using read-only tools against the immutable snapshot. That design produces a useful receipt. A finding can be tied to the code state that the model actually saw, even if the main branch changes later. Read-only access also reduces the chance that a discovery system modifies the thing it is supposed to inspect. It does not remove confidentiality risk. Source code, tickets and internal documentation can contain secrets, vulnerabilities, customer assumptions and operational detail. Access, retention, model routing and logs still need tight boundaries. Cloudflare says model requests pass through AI Gateway to cost-effective open-weight models hosted on Workers AI. The company does not identify one permanent model because the gateway makes models replaceable as price and quality change. That flexibility is useful, but it makes versioning essential. A finding without the model, prompt, tool set, repository commit and time of scan is difficult to reproduce. Model replacement should trigger a controlled comparison, not an invisible change in the inventory. Scale created another ordinary but important problem. Concurrent scans generated bursts of requests and HTTP 429 rate limits. Independent retries made the bursts worse. Cloudflare added one global Durable Object to pace requests and coordinate backoff across scans. This detail has nothing to do with quantum physics and everything to do with shipping a real system. Agent workflows fail at queues, retries, budgets and partial state long before they fail at philosophy. A migration tool needs to know which repositories finished, which stages retried, which findings merged and which report belongs to which source snapshot. CryptoLabe groups findings into categories such as classical key agreement, classical signatures, classical tokens, hybrid post-quantum key exchange and other post-quantum-ready uses. It produces reports for two audiences. Product managers need the scope, dependencies and blockers. Engineers need enough source detail to plan and execute the change. That is a better unit than a giant undifferentiated list of algorithm names. A useful record should identify the owning product, repository and commit; the protocol and cryptographic role; the relevant code and configuration; the parties on both ends; the likely migration option; shared prerequisites; confidence; reviewer; and decision. It should also keep dismissed findings. Otherwise the same false positive returns in every scan and consumes another afternoon. Cloudflare describes a separate scan for hard cases. Instead of looking for ordinary TLS, it hunts custom protocols, cryptography in size-constrained fields, hardware-bound operations, unusual constructions and dependencies on external parties without post-quantum support. Running that targeted prompt across all repositories with ticketing and documentation context worked better in the company's qualitative review than the repository-by-repository approach for these cases. One example was a certificate carried inside an HTTP header. Post-quantum certificates and signatures can be larger than classical ones. If a header, intermediary or application assumes a smaller size, replacing the signature algorithm may break the path. The next task is not to ask the model for a more confident paragraph. It is to determine whether the code still matters, measure the actual limit and test the complete route. This is why no single scan finds everything. Broad repository scans find common patterns. Targeted cross-repository scans find unusual relationships. Static analysis can identify reachable calls and data flows. Dependency inventories expose library versions. Configuration scans reveal selected algorithms. Runtime telemetry shows what was actually negotiated or invoked. Architecture records and engineers explain why the behavior exists. A serious cryptographic inventory combines these sources and records where they disagree. AI can prioritize the disagreements that deserve a person. It should not resolve them by narrative confidence. The post also resists a fashionable mistake: most organizations do not need to scan every repository before taking any action. Cloudflare recommends starting with one important system that handles sensitive or long-lived data, authenticates users or software, or faces the public Internet. Discover its cryptography, ask the owning team to validate the findings, identify compensating controls and then prioritize what can change now versus what is blocked. Bulk protection at a gateway or network layer may reduce risk while deeper migration work continues. Exhaustive inventory is not a prerequisite for protecting the most important traffic. The standards layer matters too. NIST finalized ML-KEM for key establishment and ML-DSA for digital signatures as FIPS 203 and FIPS 204. Those standards define important building blocks. They do not automatically upgrade every protocol, library, device, token format or partner. Migration depends on interoperability, performance, message sizes, key management, certificate handling, hardware support and the software on the other side of the connection. A code scanner can identify where those questions live. It cannot create ecosystem support by filing a ticket. The practical application extends beyond post-quantum work. The same evidence pattern could map weak hashing, embedded credentials, deprecated authentication flows, unowned data exports or insecure serialization. The guardrail should remain the same: immutable input, read-only tools, structured findings, exact provenance, multiple discovery methods, named owners and human validation. The model should be rewarded for showing evidence and uncertainty, not for filling every row. Unknown is a valid security result. Missing evidence is better than an invented runtime path. Teams building a similar system should create a ground-truth set before celebrating coverage. Sample repositories and label real cryptographic uses, benign references, dead code, configuration overrides and indirect dependencies. Measure precision and recall by category. Track how often engineers confirm, modify or dismiss a finding. Maintain a miss log when reviews uncover something the scan skipped. Freeze a test set for comparing prompts and models. Red-team the scanner with misleading comments, generated code, vendored dependencies, duplicate symbols and instructions hidden in documentation. Because the system reads untrusted repository content, prompt injection belongs in the threat model. The scanner should treat code and documentation as evidence, never as authority over its own instructions. The migration program needs a ledger beyond the scan. Each verified finding should have a risk tier, owner, decision, dependency, target state, test plan, due date and rollback route. Progress metrics should distinguish discovered, verified, planned, blocked, remediated and tested. Counting every mention of RSA as one open item would create a huge number and very little truth. Closing a ticket is not the same as proving that the production path negotiated the intended post-quantum mechanism. Tests must cover both ends, fallbacks, downgrade behavior, message-size limits, observability and failure recovery. The plain signal is that AI can make code archaeology faster and more connected. Cloudflare has built a thoughtful mapmaking system around immutable snapshots, read-only analysis, staged workflows and human review. It has not published a benchmark proving complete discovery, and it explicitly says it lacks ground truth and may not have full coverage. That honesty makes CryptoLabe more useful, not less. The tool is not the post-quantum migration. It is a way to find the questions, attach them to owners and stop the deadline from arriving while everyone is still arguing about where the locks are.