Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- Explicitly add webcrypto_modern_algorithms to compatibility_flags. No default enablement date is specified, so changing compatibility_date alone does not establish that it is enabled.
- Supported variants are ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65 and ML-DSA-87. ML-KEM-512 is currently unsupported.
- New capabilities include encapsulate/decapsulate APIs, getPublicKey(), SubtleCrypto.supports() and corresponding JWK support. Primitives remain accessible through crypto.subtle.
- Detect capabilities, run the official minimal examples and test real library integration. ML-KEM produces shared key material; on its own, it does not encrypt application messages.
- Not every algorithm in the proposal is implemented, and APIs may change with the draft. This article did not deploy an account Worker, measure performance or test the security of a complete protocol.
What capabilities were added
The Cloudflare announcement on October 1 lists two ML-KEM and three ML-DSA variants, plus encapsulateBits(), decapsulateBits(), encapsulateKey(), decapsulateKey(), getPublicKey(), SubtleCrypto.supports() and corresponding JWK import/export. This article was prepared on October 2. Use verifiable official metadata for the exact initial release time and time zone rather than assuming midnight from a date.
ML-KEM performs key encapsulation so communicating parties can obtain shared key material. ML-DSA performs signing and signature verification. These primitives let the runtime handle those operations and can reduce the need for some libraries to bundle their own implementations, but they are not a complete protocol that can replace every application encryption workflow.
Five variants are supported, not the whole proposal
The current Web Crypto documentation and announcement list ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65 and ML-DSA-87. ML-KEM-512 is currently unsupported; the announcement attributes this to the variant not yet being exposed by the BoringSSL used in Workers. Check the exact algorithm and operation needed rather than assuming an entire family is available.
The announcement initially illustrates ML-KEM-768 and ML-DSA-44, then lists the other three variants later; support is not limited to the two smallest examples. Proposal items including SHA-3, cSHAKE, TurboSHAKE and ChaCha20-Poly1305 are outside this initial implementation. An HPKE integration example also does not establish that WebCrypto implements every HPKE capability in the proposal.
Merge the explicit flag without replacing existing settings
The compatibility documentation requires explicit webcrypto_modern_algorithms activation. Merge <code>"webcrypto_modern_algorithms"</code> into the existing wrangler.jsonc compatibility_flags array. The minimal fragment is <code>{"compatibility_flags":["webcrypto_modern_algorithms"]}</code>. Preserve other flags already present; do not replace the complete project configuration with this fragment.
compatibility_date determines which behaviors are enabled by default as of that date, while explicit flags control particular behaviors separately. No default enablement date is currently specified for this feature, so changing compatibility_date to October 1 alone does not prove the algorithms are enabled. Flags can also be set through the Dashboard or Workers Script/Versions API metadata. Use the project's existing configuration path and verify the final deployed configuration.
First validation step: capability detection and minimal examples
In an isolated Worker, follow the official capability-detection example to check <code>SubtleCrypto.supports("sign", "ML-DSA-44")</code>. Cross-runtime libraries must also check whether this extension API exists. Workers support does not establish Node.js, Deno or browser support, and the presence of crypto.subtle does not imply support for all new algorithms.
Next, follow the official minimal ML-DSA example to generate test keys, sign fixed test bytes and verify the signature. Altering the test message should cause verification to fail. The ML-KEM example generates keys, encapsulates with the public key, decapsulates with the private key and compares the resulting shared key material. Use only new test keys and nonsensitive data, recording the algorithm, configuration, runtime and library versions. This site did not perform these account-level tests.
Second validation step: complete protocols and real libraries
ML-KEM alone does not encrypt messages. HPKE also needs components such as a key schedule and AEAD, while OHTTP depends on HPKE. The official announcement demonstrates integration directions for panva/hpke and panva/jose, but libraries may still need runtime adaptation. For JWT, verify that consumers support the same signature algorithm, key format and verification path. Successful local signing does not establish downstream acceptance.
Check actual request-body, key, signature and ciphertext sizes against storage, header, gateway and recipient limits. The announcement warns that data such as keys or signatures is larger with the new algorithms. Native implementations do not remove transmission or storage overhead. Do not turn vendor implementation descriptions into unmeasured performance gains or a claim that an entire system is post-quantum secure.
Diagnose configuration, algorithm and integration errors separately
If the API is absent, confirm that the expected Worker version and configuration are actually running and check the explicit flag. If only one algorithm fails, check the current algorithm table and operation type; in particular, do not repeatedly retry ML-KEM-512. If a minimal example succeeds but a library or complete protocol fails, retain the error, library version and runtime details, then inspect capability detection, algorithm mapping, key usages and format support.
Do not delete old keys or switch production protocols because a new primitive fails. Preserve the original deployment, configuration and test records, and narrow the difference in isolation. Advance through the existing change process only after review and validation of both the full protocol and its consumers. Reverting configuration should not delete stored data or alter someone else's verification endpoint.
Who can evaluate it now, and what to follow next
These capabilities suit developers maintaining cross-runtime cryptography libraries or evaluating signature and key-encapsulation integrations. They follow the Modern Algorithms in the Web Cryptography API draft. Cloudflare explicitly states that only part of the proposal is implemented and APIs may change. Pin versions and test conditions, and track algorithm tables, flags and library compatibility.
Without a clear protocol need, recipient verification capability or fallback plan, do not migrate production simply because of a release announcement. Assess network connectivity, runtime capability and protocol correctness separately. For general endpoint configuration, see the API key, base URL and model configuration guide, but those network settings cannot replace cryptographic integration validation.
Sources
Frequently Asked Questions
Is changing compatibility_date enough?
The documented activation method currently requires the explicit webcrypto_modern_algorithms flag, with no default enablement date specified. Preserve other project settings and verify the deployed flags.
Is ML-KEM-512 available?
The documentation explicitly says ML-KEM-512 is currently unsupported. The listed variants are ML-KEM-768 and ML-KEM-1024.
Which ML-DSA variants are supported?
ML-DSA-44, ML-DSA-65 and ML-DSA-87 are currently supported. Separately check required operations, key usages, formats and consumer support.
Can ML-KEM directly encrypt business messages?
ML-KEM provides shared key material, not a complete message-encryption scheme on its own. Protocols such as HPKE also combine a key schedule, AEAD and other required steps.
Does activation complete migration of all JWT and OHTTP workflows?
No. Library adaptation, protocol composition, recipient capability, key formats and real request paths each need validation. Primitive support does not prove a complete application migration.
Is this a stable, complete implementation of a new WebCrypto standard?
It currently follows an evolving draft, and Workers implements only part of it. APIs may change; other proposed algorithms cannot be assumed supported.