Post-quantum cryptography

Check a host

The pq type of q.cf.rt.ht asks Cloudflare Radar whether a host supports post-quantum TLS. It takes a comma list of hosts and answers with JSON:

https://q.cf.rt.ht/?pq=rtedge.net,rtcode.io,elefunc.com
https://qi.rt.ht/?pq=elefunc.com,rtedge.net,rtcode.io

The second URL opens the same query in the qi.rt.ht console, which is what the Verify button on elefunc.com links to. A host that supports it answers like this:

{ "PQ": { "rtcode.io": { "secure": true, "host": "rtcode.io:443", "kex": { "name": "X25519MLKEM768", "id": 4588 } } } }

secure

true when the host negotiates a post-quantum key agreement.

kex

The key agreement group that the check saw, with its name and TLS group id.

error

When every upstream check fails, the answer for that host is { "error": "PQ test failed for <host>" }.

The service sends Access-Control-Allow-Origin: * and Cache-Control: no-store. A live check takes about a second: on 2026-10-04 it took about 0.7 seconds for three hosts and 1.1 seconds for nine. Load it lazily, and do not call it on every page view.

A live post-quantum badge

The link opens the console for a prepared query. The script prints the key agreement that the check saw for rtcode.io when the host is secure, classical TLS when it is not, and check failed when the answer has no key agreement.

<a href="//qi.rt.ht/?pq=rtcode.io,rtedge.net" target=_pq>Verify</a> <output id=badge>…</output>
<script type=module>
  const { PQ } = await fetch('//q.cf.rt.ht/?pq=rtcode.io').then(r => r.json())
  const pq = PQ?.['rtcode.io']
  badge.value = pq?.secure ? `🔐 ${pq.kex.name}` : pq?.kex ? 'classical TLS' : 'check failed'
</script>

What is available

Around the algorithms, these parts of the draft work too: getPublicKey(), the static SubtleCrypto.supports(), JWK keys with kty: "AKP", the raw-seed, spki and pkcs8 formats, and the ML-DSA context parameter.

What is not available

These throw NotSupportedError at the edge:

• ML-KEM-512.
• The hybrid KEMs: X-Wing (MLKEM768-X25519), MLKEM768-P256 and MLKEM1024-P384.
• SLH-DSA, ChaCha20-Poly1305 and AES-OCB.
• SHA3-256, SHA3-384, SHA3-512, cSHAKE, TurboSHAKE, KT128 and KT256, KMAC and Argon2.

Which deployments have it

Each upload sets the webcrypto_modern_algorithms compatibility flag, together with the other flags that RTEdge.net always sets. You cannot change the flags. A worker uploaded before 2026-10-01 does not have the flag, so redeploy its route to get it. See Edge worker runtime.

Detect support

At the edge, globalThis.Cloudflare?.compatibilityFlags?.webcrypto_modern_algorithms === true tells you that the flag is set. It works only there. crypto.subtle.constructor.supports?.('encapsulateBits', 'ML-KEM-768') works in both places when supports exists. Trying generateKey() works everywhere, and the example below uses it. Prefer detection to reading version numbers.

<iframe src=:></iframe>
<script type=worker edge>
  const can = (alg, usages) => crypto.subtle.generateKey(alg, false, usages).then(() => true, () => false)
  export default {
    fetch: async r => Response.json({
      runtime: r.rt.edge ? 'edge' : 'browser',
      flag:    globalThis.Cloudflare?.compatibilityFlags?.webcrypto_modern_algorithms ?? null,
      mlkem768: await can('ML-KEM-768', ['encapsulateBits', 'decapsulateBits']),
      mldsa65:  await can('ML-DSA-65', ['sign', 'verify'])
    })
  }
</script>