Cloudflare 为 Cloudflare Workers 环境中的 Web Crypto 接口新增了对抗量子计算的加密算法 ML-KEM 和 ML-DSA 的可选支持。这一变化使开发者能够在运行环境中使用原生接口测试密钥交换和数字签名的现代替代方案，而不必包含使用 JavaScript 或 WebAssembly 编写的独立实现。
目前，该支持通过兼容性标志 webcrypto_modern_algorithms 提供，因为现代算法接口仍基于可能发生变化的草案。首个版本支持用于密钥封装的 ML-KEM-768 和用于签名的 ML-DSA-44，同时也提供 ML-KEM-1024、ML-DSA-65 和 ML-DSA-87。ML-KEM-512 则不受支持，因为 Workers 使用的 BoringSSL 版本不提供该算法。
新接口提供了什么？
此次新增内容包括 encapsulateBits()、decapsulateBits()、encapsulateKey() 和 decapsulateKey() 操作，以及 getPublicKey()、SubtleCrypto.supports() 和这些算法的 JWK 密钥导入与导出功能。支持检查接口允许库避免假定所有 JavaScript 环境都提供这些算法，尤其是在 Workers、Node.js、Deno 和浏览器中运行代码时。
ML-KEM 本身不会单独执行完整加密；它会生成共享密钥材料，供 Hybrid Public Key Encryption（或 HPKE）等协议与密钥派生以及 AES-GCM 等对称加密算法结合使用。而 ML-DSA 提供了更接近 Ed25519 和 ECDSA 的模型：生成密钥对、签名数据并验证签名。
这则消息为何重要？
向抗量子计算加密迁移并不是一次简单的替换，而是需要更新协议、库、服务和部署环境。Cloudflare 表示，在 Web Crypto 中提供原生 primitives 可以减少每个库都必须附带专用加密实现的需求，并为开发者提供一个实际的测试入口，例如使用 ML-DSA 对 JWT 签名，或在 HPKE 中使用 ML-KEM；这与 OHTTP 等协议有关。
在实际应用中，这一变化不会自动将 Workers 应用转变为抗量子计算应用，也不会为任何协议提供完整的升级路径。它只提供基础构件，而库开发者仍需选择合适的协议、密码套件和兼容机制。
限制与后续步骤
Workers 在基于 V8 的 workerd 环境中的 Web Crypto 层实现这些功能，并依赖 BoringSSL 提供的 primitives。此次新增内容包括 Web Platform Tests、针对兼容性标志的专用测试以及新的 TypeScript 定义。
当前阶段未包括现代 Web Crypto 提案中的其他算法，例如 SHA-3、cSHAKE、TurboSHAKE 和 ChaCha20-Poly1305；HPKE 也尚未成为 Workers 接口的一部分。Cloudflare 指出，ML-DSA 的密钥和签名比 RSA 或 Ed25519 的对应对象大得多；因此，降低实现包含成本和提升性能，并不能消除网络或存储中密钥、签名和加密文本尺寸增加所带来的影响。
在草案趋于稳定并获得库开发者反馈之前，是否将该支持设为默认仍未确定。因此，应将这项新增功能视为用于实验和验证集成的工具，而不应将其理解为所有应用都已准备好立即迁移的信号。