Support for modern cryptographic algorithms in Workers
- ID
- 30731
- Status
- summarized
- Published
- 01 Oct 2026, 9:00 PM
- Fetched
- 01 Oct 2026, 9:14 PM
- Provider
- Cloudflare Blog
- Category
- infrastructure
- Original URL
- https://blog.cloudflare.com/workers-ml-kem-ml-dsa-support/
- Source URL
- https://blog.cloudflare.com/rss/
Summary
- Score
- 6.0
- Created
- 01 Oct 2026, 9:15 PM
- Tags
- Audience
- developerssaas_startup_founders
What happened
Cloudflare Workers now exposes post-quantum algorithms through Web Crypto: ML-KEM-768/1024 for key encapsulation and ML-DSA-44/65/87 for signatures, plus encapsulateBits(), decapsulateBits(), encapsulateKey(), decapsulateKey(), getPublicKey(), SubtleCrypto.supports(), and JWK import/export. The feature is opt-in behind the webcrypto_modern_algorithms compatibility flag because the underlying 'Modern Algorithms in the Web Cryptography API' draft community group report is still moving. Cloudflare's post by Thibault Meunier states explicitly that this is not a full migration path, only building blocks for validating an integration, and that ML-KEM output still needs to be fed into a key schedule and AEAD such as AES-GCM via something like HPKE.
Why it matters
If you already bundle a JavaScript or WebAssembly post-quantum library into a Workers project, this is a chance to delete that dependency and test ML-KEM/ML-DSA against the runtime's own implementation instead. But the flag is named webcrypto_modern_algorithms and the spec is a draft, so treat it as an experiment branch, not a production key-exchange swap — Cloudflare itself says there is no complete migration path here. There is no Malaysian or Southeast Asian angle in this text; the relevance is purely for teams already running Workers.
Discussion angle
Is a draft-spec, flag-gated Web Crypto primitive enough to start prototyping PQ handshakes on Workers, or does the 'no full migration path' caveat mean you should wait for HPKE-level support before touching production traffic?