Cloudflare has announced native support for post-quantum-resistant cryptographic algorithms within the Web Crypto API for Cloudflare Workers. Based on the "Modern Algorithms in the Web Cryptography API" draft community group report from the W3C Web Incubator Community Group (WICG), the update introduces robust building blocks designed to help developers test and validate post-quantum integrations without needing to bundle separate, bulky cryptographic implementations into their applications.
For developers preparing for the impending post-quantum transition, these opt-in Web Crypto APIs make experimenting with algorithms like ML-KEM and ML-DSA significantly more straightforward. While the new primitives do not deliver a complete, out-of-the-box migration path for every existing network protocol, they furnish essential runtime-level building blocks that engineers can use to securely test, evaluate, and upgrade their infrastructure. To accommodate the evolving specification, the new capabilities are currently available behind the webcrypto_modern_algorithms compatibility flag.
Background and the Cost of Custom Crypto
The Web Crypto API is frequently categorized as foundational infrastructure—the kind of tool that engineers only truly notice when it lacks a specific primitive required for a modern workload. Experimenting with emerging post-quantum algorithms inside a standard JavaScript execution environment has historically presented steep friction. Developers either found themselves unable to construct advanced cryptographic protocols directly on top of native Web Crypto, or they were forced to bring their own custom implementations written in JavaScript or WebAssembly.
Neither of these conventional approaches is ideal. Packing custom cryptographic code into an application places the heavy burden of selection, auditing, and maintenance directly on developers, frequently causing application bundle sizes to inflate significantly. Furthermore, this redundant work must be reproduced across every downstream library and service. Because the global technology ecosystem faces the urgent necessity of transitioning to post-quantum-resistant cryptography much sooner than originally anticipated, the industry cannot afford to wait indefinitely for standardized implementations to trickle into every runtime. Engineers require immediate access to these underlying primitives so they can thoroughly test, evaluate, and refine their security postures before quantum computers are able to break standard public-key cryptography.
Primitives for a Post-Quantum Era
At its core, the initial Workers implementation provides developers with two major post-quantum cryptographic primitives: ML-KEM for key encapsulation and ML-DSA for digital signatures.
ML-KEM functions as a key encapsulation mechanism. In a typical workflow, one party holds a public key, while another side encapsulates a shared secret targeted to that specific public key. The holder of the private key then decapsulates the transmission to retrieve the identical shared secret. This mechanism delivers shared key material to both participating parties, which higher-level protocols like Hybrid Public Key Encryption (HPKE) then feed into a key schedule combined with an Authenticated Encryption with Associated Data (AEAD) algorithm such as AES-GCM.
Conversely, ML-DSA operates much more similarly to traditional signature schemes that developers already recognize from algorithms like Ed25519 or Elliptic Curve Digital Signature Algorithm (ECDSA). Developers can effortlessly generate a key pair, sign an arbitrary payload of bytes, and subsequently verify those signatures against a known public key. These native JavaScript hooks provide the exact foundational building blocks that complex, multi-layered security protocols require to function smoothly.
The Broader Ecosystem Transition
The transition to a post-quantum cryptographic landscape is far from a simple binary switch. It requires an intricate coordination of protocols, libraries, third-party services, and diverse deployment environments learning how to implement and trust entirely different mathematical primitives. Early indications of this massive industry-wide shift are already visible across foundational protocols like Transport Layer Security (TLS) and Secure Shell (SSH). For instance, OpenSSH introduced support for the mlkem768x25519 hybrid mechanism in 2024, and the Internet Engineering Task Force (IETF) has actively maintained drafts for post-quantum and hybrid Key Encapsulation Mechanisms within HPKE.
Additionally, the IETF has advanced standards such as RFC 9964 for utilizing ML-DSA within JSON Object Signing and Encryption (JOSE), alongside adopted drafts for JSON Web Encryption utilizing post-quantum HPKE. Modern HTTP Message Signatures similarly accommodate alternative signature algorithms, provided that both the signing authority and the verifying party agree on the underlying production and verification mechanisms.
To support this sprawling ecosystem on Cloudflare Workers, developers required reliable, high-performance support for the underlying cryptographic primitives directly inside the Web Crypto runtime. Without native integration, developers attempting post-quantum experimentation were forced to rely on bundled libraries. While such external dependencies are helpful for early prototyping and portability, they represent an inefficient long-term architecture for production-grade applications operating at web scale.
Integrating with Libraries like JOSE and HPKE
Popular open-source libraries are already adapting to utilize these native runtime capabilities. Signed JSON Web Tokens, which protect sensitive claims using JSON Web Signatures, serve as a familiar illustration of this integration. Using ecosystems like the panva/jose library, which maps ML-DSA algorithms directly to the underlying Web Crypto implementation, developers can sign and verify JWT tokens seamlessly without embedding heavy standalone cryptographic engines.
Similarly, libraries structured around HPKE and Web Crypto—such as panva/hpke—can now leverage native ML-KEM primitives wherever they are exposed by the execution environment. This operational paradigm applies equally to advanced privacy architectures like Oblivious HTTP (OHTTP), which relies heavily on HPKE. When HPKE can communicate with a native post-quantum KEM through standard Web Crypto interfaces, peer systems can initiate the gradual migration toward ciphersuites designed to withstand quantum threats.
To further streamline developer workflows, the update introduces helpful utility functions such as getPublicKey(), which removes the repetitive, format-specific code previously required to derive or publish a public key after loading an associated private key. Furthermore, because these advanced specifications are still evolving and lack universal adoption across all JavaScript runtimes, libraries can utilize feature-detection checks to safely verify algorithm support before attempting cryptographic operations.
Implementation and Scope
Cloudflare Workers operate on workerd, an open-source runtime built on the V8 JavaScript engine. The new post-quantum functionality extends workerd’s Web Crypto layer by backing it with robust BoringSSL primitives. This architectural change incorporates comprehensive Web Platform Tests for the modern algorithms API surface, Workers-specific validation tests for compatibility flag handling, and updated TypeScript definitions.
The initial release focuses deliberately on a streamlined subset of the wider WICG proposal, prioritizing ML-KEM-768 and ML-KEM-1024 as key encapsulation mechanisms, alongside ML-DSA-44, ML-DSA-65, and ML-DSA-87 for digital signatures. ML-KEM-512 has been intentionally excluded from the initial rollout because the specific BoringSSL version utilized by the Workers runtime does not currently expose it. Rather than introducing a custom, isolated implementation solely for that single variant, developers chose to stick strictly to the algorithms natively supported by the underlying cryptography library.
Other ambitious elements from the original WICG proposal—such as the SHA-3 hash function, cSHAKE, TurboSHAKE, and ChaCha20-Poly1305 AEAD—remain excluded from this first iterative release. Narrowing the initial scope significantly eases the code review process while providing library maintainers with a concrete, stable target to test against before the broader modern algorithms specification is fully ratified.
Industry experts emphasize that while native runtime integration drastically improves performance and reduces application bloat, it does not alter fundamental mathematical realities. Post-quantum public keys, signatures, and ciphertexts are substantially larger than their classical RSA or Ed25519 predecessors, meaning developers must still account for increased payload sizes across networks and storage layers.
For now, these advanced cryptographic features remain gated behind the webcrypto_modern_algorithms compatibility flag, allowing developers and library maintainers to provide critical feedback while the underlying specifications continue to mature. Library maintainers and Cloudflare Workers developers looking to future-proof their applications can begin experimenting with the new native primitives immediately by enabling the required compatibility flag in their configuration files and consulting the official developer documentation for the latest updates.
Leave a Reply