Workers Web Crypto adds ML-KEM and ML-DSA behind a compatibility flag

Cloudflare’s 1 October 2026 post says Workers now exposes post-quantum algorithms from the W3C community group’s modern Web Crypto draft. The algorithms are opt-in. Nothing in the default Web Crypto surface changes until a Worker sets the compatibility flag webcrypto_modern_algorithms. Cloudflare is clear that these are building blocks for tests and library work, not a finished migration of TLS or of your application protocol.

Which algorithms

The first examples are ML-KEM-768 with encapsulateBits and decapsulateBits, and ML-DSA-44 with sign and verify. Cloudflare says the implementation also includes ML-KEM-1024, ML-DSA-65, and ML-DSA-87. ML-KEM-512 is not included, because the BoringSSL build Workers uses does not expose it, and Cloudflare did not want a second implementation for that one size. SubtleCrypto.supports is there so a library can detect the algorithm before it calls generateKey. getPublicKey can derive a public key from a private key, with usage verify for signatures and encapsulateBits for ML-KEM.

The post says the change landed in workerd, the open-source Workers runtime, on top of BoringSSL, with Web Platform Tests, Workers tests for the flag, and TypeScript types. It thanks Filip Skokan for the original workerd contribution and says an implementation was run against the test suites of the panva/hpke and panva/jose libraries. That is Cloudflare’s account of its own tests.

Algorithms not in this change

Cloudflare says it split a larger proposal. This slice is ML-KEM, ML-DSA, helper APIs, and JWK. It does not add SHA-3, cSHAKE, TurboSHAKE, ChaCha20-Poly1305, or HPKE itself. Those remain in the community-group discussions the post cites. The flag stays because the API is still a draft. Public keys and signatures for ML-DSA are larger than RSA or Ed25519; native support does not shrink them on the wire.

The post also says ML-KEM alone is not encryption. It produces shared key material. A protocol such as HPKE still has to run a key schedule and an AEAD. The post says OHTTP uses HPKE, so this flag does not by itself turn OHTTP post-quantum.

Practical takeaway

Add webcrypto_modern_algorithms on a Worker where you want to try ML-KEM-768 or ML-DSA-44, and feature-detect with SubtleCrypto.supports. Do not promise ML-KEM-512, SHA-3, or HPKE on Workers from this announcement. Plan for larger keys and signatures, and keep the flag off until the library you ship has been tried against the draft API.