Cloudflare has added optional support for the quantum-resistant cryptographic algorithms ML-KEM and ML-DSA to the Cloudflare Workers environment through the Web Crypto API. The change allows developers to test modern alternatives for key exchange and digital signatures using native interfaces in the runtime, rather than bundling separate JavaScript or WebAssembly implementations.
Support is currently available through the webcrypto_modern_algorithms compatibility flag because the modern algorithms interface is still based on a draft that may change. The first release supports ML-KEM-768 for key encapsulation and ML-DSA-44 for signatures, while also providing ML-KEM-1024, ML-DSA-65, and ML-DSA-87. ML-KEM-512 is not supported because the version of BoringSSL used in Workers does not provide it.
What does the new interface provide?
The addition includes the encapsulateBits(), decapsulateBits(), encapsulateKey(), and decapsulateKey() operations, along with getPublicKey(), SubtleCrypto.supports(), and JWK key import and export for these algorithms. The support-detection interface allows libraries to avoid assuming that the algorithms are available in every JavaScript environment, particularly when code runs across Workers, Node.js, Deno, and browsers.
ML-KEM does not perform complete encryption on its own; it produces shared-key material that protocols such as Hybrid Public Key Encryption, or HPKE, can use with key derivation and a symmetric encryption algorithm such as AES-GCM. ML-DSA, meanwhile, provides a model closer to Ed25519 and ECDSA: it generates a key pair, signs data, and verifies signatures.
Why does this news matter?
The transition to quantum-resistant cryptography does not happen through a single switch; it requires updating protocols, libraries, services, and deployment environments. Cloudflare says that providing native primitives within Web Crypto reduces the need to ship a custom cryptographic implementation with every library and gives developers a practical point for testing integrations such as signing JWTs with ML-DSA or using ML-KEM within HPKE, which is connected to protocols such as OHTTP.
In practice, this change does not automatically turn Workers applications into quantum-resistant applications, nor does it provide a complete upgrade path for any protocol. It provides only the basic building blocks, while library developers remain responsible for choosing the appropriate protocol, cryptographic suites, and compatibility mechanisms.
Limitations and next steps
Workers implements these functions in the Web Crypto layer within the workerd environment built on V8, relying on primitives from BoringSSL. The addition included Web Platform Tests, compatibility-flag-specific tests, and new TypeScript definitions.
The current phase does not include other algorithms mentioned in the modern Web Crypto proposal, such as SHA-3, cSHAKE, TurboSHAKE, and ChaCha20-Poly1305, nor has HPKE become part of the Workers interface itself. Cloudflare points out that ML-DSA keys and signatures are much larger than their RSA or Ed25519 counterparts; therefore, reducing the cost of bundling the implementation and improving performance does not eliminate the impact of increased key, signature, and ciphertext sizes on the network or storage.
The question of moving the support to the default mode remains open until the draft stabilizes and feedback is received from library developers. The addition should therefore be treated as a means of experimentation and integration validation, not as a signal that all applications are ready for an immediate transition.