服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 显式加入 compatibility_flags 中的 webcrypto_modern_algorithms；官方没有给出本项默认启用日期，不应仅调整 compatibility_date 后假设已经开启。
- 支持 ML-KEM-768、ML-KEM-1024，以及 ML-DSA-44、ML-DSA-65、ML-DSA-87；ML-KEM-512 当前不支持。
- 新增 encapsulate/decapsulate APIs、getPublicKey()、SubtleCrypto.supports() 及相应 JWK 支持，仍从 crypto.subtle 使用原语。
- 先检测能力、运行官方最小例子并检查真实库集成；ML-KEM 得到共享密钥材料，单独并不加密应用消息。
- 提案其他算法并未全部实现，API 可能随草案变化；本文未部署账户 Worker，未实测性能或整个协议安全性。
这次新增的是哪些能力
<a href="https://blog.cloudflare.com/workers-ml-kem-ml-dsa-support/">Cloudflare 10 月 1 日公告</a>列出两种 ML-KEM 变体与三种 ML-DSA 变体，以及 encapsulateBits()、decapsulateBits()、encapsulateKey()、decapsulateKey()、getPublicKey()、SubtleCrypto.supports() 和相应 JWK import/export。本文于 10 月 2 日整理；具体首发时刻与时区以官方可核验元数据为准，不把日期自动补成午夜。
ML-KEM 用于密钥封装，让通信双方得到共享密钥材料；ML-DSA 用于签名与验签。新增原语让运行时可承担这些运算，减少某些库自行携带实现的需要，但它们不是可直接替换所有应用加密流程的一整套协议。
支持五个变体，提案范围并未全部覆盖
按<a href="https://developers.cloudflare.com/workers/runtime-apis/web-crypto/">当前 Web Crypto 文档</a>及公告，支持 ML-KEM-768、ML-KEM-1024，ML-DSA-44、ML-DSA-65、ML-DSA-87。ML-KEM-512 当前不支持；公告解释为 Workers 使用的 BoringSSL 尚未暴露这一变体。应按实际需要检查算法名与操作类型，不把整个算法家族当作都可用。
公告短版先展示 ML-KEM-768 与 ML-DSA-44，后文补全另外三个变体，并不是文档只支持最小的两个。SHA-3、cSHAKE、TurboSHAKE、ChaCha20-Poly1305 等提案内容不在这次初始实现范围；HPKE 集成示例也不代表 WebCrypto 已实现提案里的所有 HPKE 能力。
配置：合并显式 flag，不覆盖原有设置
<a href="https://developers.cloudflare.com/workers/configuration/compatibility-flags/">兼容性文档</a>要求显式启用 webcrypto_modern_algorithms。在现有 wrangler.jsonc 的 compatibility_flags 数组中合并 <code>"webcrypto_modern_algorithms"</code>；对应最小配置片段是 <code>{"compatibility_flags":["webcrypto_modern_algorithms"]}</code>。如果已有其他 flags，应保留它们，不用这个片段覆盖完整项目配置。
compatibility_date 决定截至该日期默认启用的行为，显式 flags 则单独控制对应行为。当前官方没有给出本项成为默认行为的日期，所以只把 compatibility_date 改成 10 月 1 日并不足以证明新算法启用。Dashboard 或 Workers Script/Versions API metadata 也可设置兼容 flags，任选项目现有的配置入口并核对最终部署配置。
验证第一步：能力检测与最小例子
在隔离 Worker 中按<a href="https://blog.cloudflare.com/workers-ml-kem-ml-dsa-support/">官方能力检测示例</a>先判断 <code>SubtleCrypto.supports("sign", "ML-DSA-44")</code>。跨运行时库还需要判断该扩展 API 是否存在；不能把 Workers 的支持推断为 Node.js、Deno 或浏览器支持，也不能将存在 crypto.subtle 等同于拥有所有新算法。
随后按官方最小 ML-DSA 例子生成测试密钥、签名固定测试字节，再验签；修改测试消息后应观察验签失败。ML-KEM 例子则生成密钥、用公钥 encapsulate、用私钥 decapsulate，并比较得到的共享密钥材料。只用新建测试密钥和非敏感数据，记录算法、配置、运行时与库版本；本站没有执行这些账户试验。
验证第二步：完整协议和真实库边界
ML-KEM 本身不加密消息。HPKE 还需要 key schedule 与 AEAD 等组合；OHTTP 又依赖 HPKE。官方演示 panva/hpke 与 panva/jose 的集成方向，但库仍可能需要运行时适配。对 JWT，要验证消费端也支持同一签名算法、密钥格式与验证路径；本地签名成功不证明下游已经接受。
检查真实请求体、密钥、签名和 ciphertext 尺寸，确认存储、header、网关与接收端限制。公告提醒新算法的密钥或签名等数据更大，原生实现不消除传输和存储开销；不要将厂商实现说明转为未经实测的性能提升数字或整个系统已具备后量子安全的结论。
报错时先定位配置、算法与集成
若目标 API 不存在，先确认实际执行的是预期 Worker 版本和配置，并核对显式 flag；若只某个算法失败，查当前算法表与操作类型，尤其不要对 ML-KEM-512 反复尝试。若最小例子正常而库或完整协议失败，保留错误、库版本和运行时信息，检查库的能力检测、算法映射、key usages 与格式支持。
不要因为新原语报错就删除旧密钥或切换生产协议。保留原部署、配置和测试记录，先在隔离环境缩小差异；只有完整协议与消费端均经过评审和验证，才按现有变更流程推进。回到旧配置也不应删除已存数据或改变他人的验证端。
现在适合谁，后续要关注什么
这次能力适合维护跨运行时加密库、评估签名或密钥封装集成的开发者。它基于 Modern Algorithms in the Web Cryptography API 草案，<a href="https://developers.cloudflare.com/workers/configuration/compatibility-flags/">官方明确只实现部分提案且 API 可能变化</a>。先固定版本和试验条件，跟踪算法表、flag 和库兼容变化。
没有明确协议需求、接收端验证能力或回退方案时，不应仅因为发布消息就迁移生产。网络连通性、运行时能力和协议正确性应分别判断；一般接口配置可参考<a href="/resources/ai-api-key-base-url-model-guide">API key、base URL 与模型配置说明</a>，但这些网络配置不能替代密码学集成验证。
资料来源
常见问题
改 compatibility_date 就能开启吗？
当前官方列出的启用方式是显式 webcrypto_modern_algorithms flag，未给出默认启用日期。保留项目其他配置并核对实际部署的 flags。
ML-KEM-512 可用吗？
当前官方明确不支持 ML-KEM-512。列出的可用变体是 ML-KEM-768、ML-KEM-1024。
ML-DSA 有哪些变体？
当前支持 ML-DSA-44、ML-DSA-65、ML-DSA-87。应另外检查所需操作、key usages、格式及消费端支持。
ML-KEM 能直接加密业务消息吗？
ML-KEM 提供共享密钥材料，单独不是完整消息加密方案。HPKE 等协议还组合 key schedule、AEAD 和其他必要步骤。
启用后所有 JWT 和 OHTTP 就完成迁移了吗？
没有。库适配、协议组合、接收端能力、密钥格式和真实路径都需独立验证；原语支持不能证明完整应用迁移成功。
这是不是稳定的完整 WebCrypto 新标准实现？
当前依据仍在演进的草案，Workers 只实现部分内容。API 可能变化，其他提案算法不能自动视为已支持。