Cloudflare Develops AI Tool CryptoLabe to Chart Post-Quantum Cryptography Migration

Cloudflare Develops AI Tool CryptoLabe to Chart Post-Quantum Cryptography Migration Targeting full post-quantum readiness by 2029, Cloudflare developed an internal AI-driven tool called CryptoLabe to identify, analyze, and prioritize classical cryptography across its codebases, replacing simple pattern-matching searches with structured multi-stage analysis. Cloudflare is aiming for full post-quantum readiness by 2029 across both encryption and authentication. Traditional pattern matching (grepping) falls short by missing indirect dependencies, overcounting unused code, and failing to understand runtime context. CryptoLabe uses a two-stage discovery and analysis scan powered by Cloudflare Workers, Durable Objects, Workflows, and sandboxed immutable snapshots. A separate scan identifies 'hard cases' such as custom protocols, hardware crypto, or size constraints like certificates embedded in HTTP headers. Goals and Limitations of Traditional Discovery Aiming for platform-wide post-quantum (PQ) readiness by 2029, Cloudflare needed to map cryptography usage, track migration metrics, and detect ecosystem blockers early. Simple code grepping proved insufficient because it overcounts dead code, misses implicit defaults or indirect dependencies, and cannot discern runtime context, such as whether an ECDSA signature belongs to a JWT, TLS, or SSH. CryptoLabe Scanning and Architecture CryptoLabe operates in two stages: an initial discovery stage that scans code, manifests, and documentation for raw observations, followed by an analysis stage that evaluates runtime roles, cross-repository dependencies, and overrides to classify findings (e.g., classical encryption, classical token, or PQ-ready). Architecturally, it runs on Cloudflare Workers, using Durable Objects for coordination and rate pacing, Workflows for step retries, and Cloudflare Sandboxes to evaluate code snapshots stored in R2. Prerequisites, Hard Cases, and Migration Advice CryptoLabe clusters findings by shared prerequisites—such as waiting on post-quantum SAML or JWT standards and library support—before product teams can act. A separate prompt scans for 'hard cases' like custom constructions or size-sensitive fields, having already flagged an HTTP header carrying a certificate that could fail under larger PQ payload sizes. Cloudflare notes that other organizations should prioritize protecting critical traffic and high-value systems first rather than attempting an exhaustive cryptographic scan upfront.

Cloudflare 研发 AI 工具 CryptoLabe 推进 2029 年全面后量子密码迁移 为实现 2029 年全面后量子就绪的目标，Cloudflare 研发了名为 CryptoLabe 的内部 AI 工具，通过双阶段扫描与开发者平台架构，解决大规模代码库中密码学发现、运行时上下文分析及生态依赖阻塞等迁移难题。 Cloudflare 设定了 2029 年实现全面后量子（PQ）就绪的目标，并推行全面后量子化战略。 传统的文本搜索（grep）无法满足加密发现需求，存在误报、漏报且缺乏运行时上下文分析能力。 CryptoLabe 采用“发现”与“深度分析”两阶段扫描，结合只读沙箱与 AI 模型生成结构化分类与报告。 基于 Cloudflare 开发者平台构建，利用全局 Durable Object 实施统一速率限制以应对 AI API 配额瓶颈。 通过归类“前置依赖条件”与专项提示词筛查“复杂情况”（如体积受限字段），提前排查外部生态阻碍。 迁移目标与代码扫描挑战 Cloudflare 计划在 2029 年前实现全平台的后量子就绪。迁移的核心目标包括帮助工程团队理解并升级加密实践、建立仓库级迁移进度指标，以及尽早识别缺乏后量子标准或库支持的外部依赖。由于代码分布在大量仓库中且加密逻辑常隐藏在多层抽象后，简单的算法名称 grep 搜索不仅容易因未调用代码而过度计数，还会遗漏默认配置与间接依赖，更无法辨别具体协议上下文（如 ECDSA 用于 JWT、IPsec、TLS 还是 SSH）。 CryptoLabe 两阶段扫描机制 CryptoLabe 采用两阶段扫描工作流。第一阶段为发现阶段，全面扫描代码、配置、清单、锁文件和文档中的密钥协商、签名及 PKI 等操作，生成原始观察记录。第二阶段为分析阶段，重新核对源码并分析运行时行为、仓库角色及软硬件依赖，甚至跨仓库检查上下文并自我纠错。分析结果被归类为经典加密、经典签名、经典令牌（如 RS256/ES256 JWT）、混合密钥交换（X25519MLKEM768）或就绪的 PQ 算法，证据不足时标记为需要更多证据或未知，最终输出面向产品经理与工程师的双重报告。 基于开发者平台的系统架构 CryptoLabe 构建于 Cloudflare 自身开发者平台之上。扫描服务由两个 Worker 组成，分别负责执行扫描与处理仪表盘 API 及 D1 数据存储。系统通过 Agents SDK 为每个代码仓库分配持久化的 Durable Object 作为协调器，并交由 Workflows 执行容错与重试。为确保安全性，仓库快照存储在 R2 中并加载至一次性 Sandbox 容器内，模型仅能通过只读工具访问。针对多仓库并发扫描引发的 HTTP 429 限流问题，系统部署了全局 Durable Object 对所有模型请求统一排队与退避冷却。 前置依赖与复杂场景排查 后量子迁移高度依赖软件库（如 BoringSSL）和外部生态。CryptoLabe 将无法由单个团队直接修复的问题归类为“前置依赖”，例如等待 RFC 9964 的 PQ-JWT 库支持或 SAML 协议的后量子化改造。此外，团队使用精简的专项提示词进行全量扫描以挖掘“复杂情况”，排查硬件加密、盲签名以及在 HTTP 标头等尺寸敏感字段中使用大体积后量子证书导致的系统兼容问题，从而提前制定改造策略。 实施建议与开源资源 Cloudflare 已将部分加密发现提示词开源供行业参考，但强调提示词效果取决于模型、工具上下文与人工审查配合。作者指出，大多数普通机构无需效仿 Cloudflare 对所有仓库进行地毯式扫描，以免浪费资源；更实用的路径是先利用边缘或 SASE 等网络基础设施自带的后量子加密作为补偿控制手段，随后聚焦于高价值业务系统，按优先级逐步推行迁移。

As laboratories around the world race to build out a [cryptographically relevant quantum computer](https://blog.cloudflare.com/the-quantum-menace/), we at Cloudflare are racing towards a [2029 target deadline for full post-quantum readiness](https://blog.cloudflare.com/post-quantum-roadmap/). While we’ve already transitioned many of our [products](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/) to post-quantum encryption, we still have work to do to support [post-quantum authentication](https://blog.cloudflare.com/ml-dsa-will-have-to-do/) 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](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/) over [TLS](https://www.cloudflare.com/learning/ssl/transport-layer-security-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](https://blog.cloudflare.com/post-quantum-authentication-to-origins/) [days](http://blog.cloudflare.com/pq-ca-with-mtcs/) 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 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 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](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) signature could be part of a [JWT](https://www.rfc-editor.org/info/rfc7519/), [IPsec](https://www.cloudflare.com/learning/network-layer/what-is-ipsec/#how-does-ipsec-work), [TLS](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/), or [SSH](https://www.cloudflare.com/learning/access-management/what-is-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. 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. Among other things, the scan looks for the use of cryptography like key agreement, signatures, asymmetric encryption, [PKI](https://en.wikipedia.org/wiki/Public_key_infrastructure), tokens, credentials, hardware security module integrations, and more. This discovery stage produces a set of "raw observations." Each raw observation feeds a run of the second stage. This “analysis” stage first re-checks the observation against the source code. It then investigates how the cryptographic operation is used at runtime, what role the repository plays, and which internal or external parties it depends on. When necessary, it can inspect related code in other repositories to complete the analysis. Finally, it takes a pass over its own conclusions, searching for missing or conflicting evidence such as configuration overrides, test-only code, or incorrect assumptions about runtime behavior. Next, the model assigns a classification to the finding. If there is not enough evidence to assign a classification, the model assigns *More evidence needed*, *External dependency*, or *Unknown* rather than guessing. This is the current list of classifications used by CryptoLabe, containing catch-all classifiers which will likely be refined as we proceed through our migration. (As an example, we could refine our classifiers by splitting the “encryption” classifier into [key agreement](https://www.rfc-editor.org/info/rfc10024/) and [HPKE](https://blog.cloudflare.com/hybrid-public-key-encryption/); you get the idea.) | **Classification** | **Examples** | | Classical encryption | This is a catch-all category that finds cases of elliptic-curve [Diffie-Hellman key exchange (ECDHE)](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) (e.g., X25519, P-256, P-384), RSA key agreement or other uses of public-key encryption (e.g., [HPKE](https://www.rfc-editor.org/info/rfc9180/)). These are broken by a quantum computer running [Shor's algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), which puts them at risk of [harvest-now-decrypt-later attacks](https://blog.cloudflare.com/the-quantum-menace/). | | Classical signature | This is a catch-all category that finds use of an RSA signature or elliptic-curve (ECDSA) signature in anything, for example a certificate, a TLS handshake, another protocol handshake. These signatures are broken by Shor's algorithm. | | Classical token | We found a lot of [RS256 or ES256 JWT tokens](https://en.wikipedia.org/wiki/JSON_Web_Token), so we created a special classification for them. These are JWTs that use classical RSA and ECDSA signatures; [RFC 9964](https://www.rfc-editor.org/info/rfc9964) defines a post-quantum replacement using [ML-DSA](https://blog.cloudflare.com/ml-dsa-will-have-to-do/). | | PQ-ready hybrid key exchange | Finds hybrid post-quantum key exchange in TLS 1.3, i.e. [X25519MLKEM768](https://datatracker.ietf.org/doc/rfc10024/). This is the most prevalent use of PQ encryption in our codebase. | | PQ-ready | Finds other uses of post-quantum cryptography that are not [X25519MLKEM768](https://datatracker.ietf.org/doc/rfc10024/) in TLS 1.3, like [ML-DSA](https://csrc.nist.gov/pubs/fips/204/final). | Finally, it generates a report that serves two audiences: (1) product managers who need to understand what the migration means for their product, and (2) engineers that need enough detail to execute the migration. Here’s a (cropped) view of one of our reports: While we’ve been iteratively reviewing findings against the source code and with relevant engineers, we do not yet have a ground-truth dataset for reproducibly comparing different versions of the prompts we’ve tried for CryptoLabe. We built CryptoLabe on [Cloudflare's Developer Platform](https://developers.cloudflare.com/). Here’s the architecture: CryptoLabe runs across two Cloudflare [Workers](https://www.cloudflare.com/products/workers/). There’s a scanner Worker that runs the scans. And there’s an inventory Worker that serves the dashboard, exposes the API, and stores everything in a [D1](https://developers.cloudflare.com/d1/) database. The two communicate through [Service Bindings](https://developers.cloudflare.com/workers/runtime-apis/service-bindings/). A scan starts when someone requests it from the dashboard, and the inventory Worker passes the request to the scanner. We need a way to keep a scan alive and on track from start to finish, without building our own job orchestration system. We did this with [Agents SDK](https://developers.cloudflare.com/agents/). Each repository gets its own persistent coordinator built on a [Durable Object (DO)](https://developers.cloudflare.com/durable-objects/). A bounded queue in front of the coordinators limits how many scans run at once. When a scan's turn comes, the coordinator tracks its progress and handles cancellation, retries, and recovery. The coordinator doesn't do the analysis itself. It hands the work to [Cloudflare Workflows](https://developers.cloudflare.com/workflows/), so that they can persist progress and automatically retry failed steps. The coordinator moves each repository through four stages: The first two workflows need the model to have access to the repository's code. We want this access to be isolated, so we don’t risk damaging the codebase. That’s why CryptoLabe downloads the repository once, at an exact commit, at the start of each scan, and then stores that snapshot in [R2](https://developers.cloudflare.com/r2/). Each Workflow then restores the snapshot into a fresh, short-lived [Cloudflare Sandbox](https://developers.cloudflare.com/sandbox/), an isolated container. The model then works with the Sandbox through a small set of read-only tools on an immutable snapshot of the code, even if the codebase changes while the scan is still running. If we want to scan through all of our (many!) repositories, we have to worry about both cost and capacity. For cost, the model loop sends its requests through [AI Gateway](https://developers.cloudflare.com/ai-gateway/) to cost-effective open-weight models hosted on [Workers AI](https://developers.cloudflare.com/workers-ai/). Putting the model behind AI Gateway also makes it easy to switch models as better or cheaper ones become available. Capacity became a problem once we scanned many repositories at once. Bursts of model requests began triggering HTTP 429 (rate limit) responses from AI Gateway, and scans retrying independently only made the bursts worse. We solved this with a single, global Durable Object that paces every model request across all scans, including retries. When any scan hits a rate limit, the cooldown is shared and all scans back off together, so concurrent scans share the available capacity instead of competing for it. Let’s now get into our third goal: surfacing prerequisites and hard cases early. A lot of ink has been spilled about *ecosystem readiness* for the PQ migration, and we are now going to spill some more. As everyone knows, a PQ migration cannot happen in a vacuum. For migration to succeed, post-quantum cryptography must be supported in relevant software libraries (e.g. BoringSSL) and across parties that participate in the ecosystem (e.g. clients, browsers, origins, cloud proxies, certificate authorities, etc.). Standards are also an important indicator of ecosystem support, although a standard that is still in “draft” state does not necessarily mean deployment cannot proceed. As an example, we deployed X25519MLKEM768 in TLS 1.3 back in 2022 when it was still a “draft” at the Internet Engineering Task Force ([IETF](https://www.ietf.org/)) while it was only finalized as [RFC 10024](https://www.rfc-editor.org/info/rfc10024/) in 2026. Either way, our point is that in order to upgrade a system to PQ cryptography, we need to understand its dependencies and level of ecosystem support. That’s why CryptoLabe uses the concept of “prerequisites” to highlight findings that cannot be immediately remediated by an individual product team working alone. A prerequisite can be something as straightforward as “we are currently blocked on migrating to post-quantum JWTs.” We say this is straightforward because there is already a standard ([RFC 9964](https://www.rfc-editor.org/info/rfc9964/)) for post-quantum JWTs. Nevertheless, if our software libraries don’t yet support validating post-quantum JWTs, or if we’re using a token issuer that does not yet issue post-quantum JWTs, we can’t go company-wide and ask each of our product teams to start PQ-ing their JWTs. This migration is blocked until we solve its core prerequisites. CryptoLabe lets us group together findings that (likely) have the same prerequisite, which also helps us decide how to prioritize resolving these prerequisites. For example, the snapshot below shows the six findings from CryptoLabe that have post-quantum [SAML](https://www.cloudflare.com/learning/access-management/what-is-saml/) as a prerequisite. (SAML is a protocol for single sign-on ([SSO](https://www.cloudflare.com/learning/access-management/what-is-sso/)).) On the other hand, there may be uses of cryptography that lack even a basic level of ecosystem support. We’ve been calling these “hard cases.” To find them, we wrote a separate prompt that ignores “vanilla” uses of cryptography (e.g. ordinary TLS between internal systems) and instead looks for custom cryptographic protocols, keys, or signatures used in size-constrained fields, cryptography built into hardware, specialized cryptographic constructions (like [blind signatures](https://en.wikipedia.org/wiki/Blind_signature)), protocols without a PQ standard, and dependencies on external parties that do not yet support PQ cryptography. This prompt is shorter and simpler than those used for CryptoLabe, since its only job is to find hard cases. In our qualitative review, we found that it got better results when it ran in one fell swoop against all our repositories, while also taking in context from our internal ticketing and documentation system. Here’s an example of a “hard case” we found: a certificate carried in an HTTP header. Post-quantum certificates and signatures are larger than their classical counterparts, so if the header (or an intermediary, or the application processing the header) assumes a certificate has a certain size, changing the signature algorithm may break the system. Our next step is to determine whether this code will remain in use in the long term. If it will, we need to measure the relevant size limits and decide how to accommodate the larger certificate. An important lesson here is that no single scan finds everything. Our repository-by-repository scans were effective at discovering common uses of cryptography. Meanwhile, this targeted scan worked better for “hard cases” because it ignored well-understood cryptography and had more context about each product and its dependencies. The bottom line is that different approaches find different things, and every finding still needs to be checked by the engineers who understand how the system actually works. We’ve been messing around with the best way to write prompts for CryptoLabe for the last several months.  We don’t yet have a ground-truth dataset for comparing one prompt’s performance against another, and we are not convinced we have 100% coverage of all uses of cryptography in our codebase. Instead, we have iterated by running scans, reviewing findings with the engineers that maintain the repositories, investigating misses that came up during these reviews and revising the prompts.   Nevertheless, we decided to publish [selected prompts](https://github.com/cloudflare/crypto-discovery-prompts/), so other teams can learn from and adapt our approach. These prompts are starting points, not a standalone version of CryptoLabe, and the quality of their results will depend on the model, tools, context, and engineering review available. At Cloudflare, we’re taking a maximalist approach to our PQ migration because of our goal of acting as a provider of post-quantum cryptography for customers and the Internet at large. But most organizations [do not need](https://blog.cloudflare.com/post-quantum-eo-2026/) to start by finding every use of cryptography in every repository in every one of their products. In fact, most organizations should not be doing this, because at this time it's a waste of precious resources. Before scanning a single repository, you can protect traffic in bulk wherever possible. If your websites run through Cloudflare, we protect your data in transit with post-quantum encryption [already today](https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-cloudflare-products/); check this out with our [new PQ visibility features](https://blog.cloudflare.com/post-quantum-visibility). Our [SASE](https://www.cloudflare.com/learning/access-management/what-is-sase/) platform, [Cloudflare One](https://blog.cloudflare.com/post-quantum-sase/), provides post-quantum encryption for private network traffic. Post-quantum encryption is provided at [no additional cost](https://blog.cloudflare.com/post-quantum-crypto-should-be-free/) and without requiring you to upgrade every origin server or private application on your enterprise network. This gives you a compensating control while you work through discovering and understanding the use of cryptography inside your own systems. An exhaustive cryptographic inventory is not a prerequisite for action. Instead, organizations should first identify the systems whose compromise would matter most, discover their use of cryptography, and then PQ that cryptography in priority order. Here is one way to begin: That gives you the beginning of a PQ transition plan, without requiring a complete map of every cryptographic operation in your organization. CryptoLabe is still ever-evolving, but its scans and results have been illuminating to us as we plan our migration. We hope these shared learnings will be useful as you continue to work through your own PQ migration. *Acknowledgements: Many people across Cloudflare provided feedback on and contributed to CryptoLabe, including Davide Marquês, Peter Wu, Phil Schmieder, JP Aumasson, Andrew Galloni, Christopher Patton, Luke Valenta, Mari Galicer, Vânia Gonçalves, and the [Client](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/download/), [Tunnel](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/) and [Gateway](https://www.cloudflare.com/zero-trust/products/gateway/) teams who reviewed reports produced by the tool.*