Cloudflare Workers adds post-quantum ML-KEM and ML-DSA to Web Crypto behind compatibility flag

Cloudflare ships post-quantum primitives in Workers

Cloudflare has added post-quantum cryptographic algorithms to the Web Crypto API in its Workers runtime. According to the Cloudflare blog, the release introduces ML-KEM-768 and ML-KEM-1024 for key encapsulation and ML-DSA-44, ML-DSA-65 and ML-DSA-87 for signatures, as defined in the Modern Algorithms in the Web Cryptography API community group draft report.

The support ships behind the webcrypto_modern_algorithms compatibility flag, which developers enable in their wrangler configuration. Cloudflare is explicit that these opt-in APIs are building blocks for testing and validating integrations, not a finished migration story.

What is in the release

Alongside the algorithms, Workers implements new Web Crypto operations: encapsulateBits() and decapsulateBits(), plus encapsulateKey() and decapsulateKey() for KEM usage, a getPublicKey() helper that derives a public key from a private key, and a SubtleCrypto.supports() method for feature detection. JWK import and export also covers the new algorithms.

Cloudflare says the initial implementation centres on ML-KEM-768 as the KEM and ML-DSA-44 as the signature algorithm, with the larger parameter sets supported as well. ML-KEM-512 is not offered because of the BoringSSL version that Workers builds on.

How the two primitives differ

ML-KEM does not encrypt anything on its own. One party encapsulates a shared secret against a public key, and the holder of the matching private key decapsulates the ciphertext to recover the same secret. Turning that material into actual message protection still requires a protocol such as HPKE, which runs the shared secret through a key schedule and an AEAD cipher like AES-GCM.

ML-DSA will feel familiar to anyone who has used Ed25519 or ECDSA: generate a key pair, sign bytes, verify bytes. Cloudflare describes its published code samples as deliberately small hooks for primitives rather than complete protocols.

Libraries can delegate to the runtime

Before this change, a Workers developer experimenting with post-quantum algorithms had to bundle a separate implementation in JavaScript or WebAssembly, because Web Crypto lacked the required primitives. According to Cloudflare, that approach bloats applications and pushes the job of selecting and maintaining cryptographic code onto every downstream library.

The blog demonstrates what changes. The panva/jose package can sign JWTs with ML-DSA-44 by mapping the algorithm onto Web Crypto, and the panva/hpke library can use ML-KEM-768 as the KEM inside a cipher suite. Since OHTTP is built on HPKE, native primitives also point toward post-quantum ciphersuites there once peers are ready to negotiate them.

The new getPublicKey() call removes a recurring annoyance for public-key protocols, which previously had to keep both halves of a key pair around or do format-specific work to publish a public key. The usage list differs per algorithm: ML-DSA public keys take "verify", while ML-KEM public keys take "encapsulateBits".

SubtleCrypto.supports() exists because the modern-algorithms proposal is not implemented everywhere yet. Cloudflare recommends that libraries running across Workers, Node.js, Deno and browsers check for capabilities instead of assuming they exist, which also helps when only part of the proposal has landed in a given runtime.

Broader ecosystem context

Cloudflare situates the work within wider post-quantum efforts: OpenSSH added the mlkem768x25519 key exchange in 2024, the IETF has an ongoing draft for post-quantum and hybrid KEMs in HPKE, RFC 9964 defines ML-DSA for JOSE, and an adopted draft extends JWE with post-quantum and hybrid HPKE. HTTP Message Signatures can already accommodate different algorithms as long as signer and verifier agree on them.

Why it matters

Cloudflare argues that the shift to post-quantum cryptography is not a single switch but a wide-reaching effort in which many protocols, libraries, services and deployment environments each have to learn to work with different primitives. Putting ML-KEM and ML-DSA into a widely used edge runtime means JavaScript developers can begin validating integrations without shipping their own cryptographic code, and library authors can treat the runtime as the implementation of record wherever support exists. The compatibility flag is a signal that the API shape may still change while the specification matures, but it lowers the cost of preparing applications for the quantum-safe era now rather than waiting for the standards process to complete.