PQC Tester CIO Factory
NET TLS 1.3 ML-KEM

Post-Quantum Cryptography · TLS 1.3 key-exchange audit

Check if your domain supports Post-Quantum Cryptography

Eight live TLS handshakes, built byte by byte, test whether your server negotiates the hybrid X25519MLKEM768 key exchange, which keeps recorded traffic sealed against future quantum computers.

Primary group
0x11EC
Standard
FIPS 203 · RFC 10024
Probes
8 + cert
pqc-scan — tls1.3 / hybrid-kem ready
Try

Field notes

01

What does this tool do?

Enter a domain and the tester opens eight real TLS 1.3 handshakes with its server. It checks which post-quantum key-exchange groups the server accepts, and which one it actually picks when a modern browser connects. The result comes with the exact bytes exchanged. If your server falls short, you get configuration steps matched to the server software it detects.

02

What is Post-Quantum Cryptography?

Most encrypted connections today agree on session keys using elliptic-curve Diffie-Hellman, which a large quantum computer running Shor's algorithm could reverse. Post-quantum cryptography replaces that step with schemes built on hard lattice problems, such as ML-KEM (NIST FIPS 203). On the web it ships as a hybrid, X25519MLKEM768, so a connection stays secure as long as either half holds.

03

Why is this important?

Encrypted traffic can be copied off the network and stored indefinitely. Anyone who records it today can decrypt it once a capable quantum computer exists: the harvest now, decrypt later threat. Data with a long shelf life is most exposed, such as financial records, health data, credentials and trade secrets. Only post-quantum key exchange keeps it out of reach, and it has to be switched on before the traffic is sent.

MethodologyHow the probes work

No TLS library on our side. Each probe is a ClientHello assembled byte by byte in PHP and sent over a raw TCP socket. The scanner reads the server's first flight (ServerHello, HelloRetryRequest or Alert) and hangs up. No session is ever completed.

HelloRetryRequest probes (six of the eight) offer exactly one group and an empty key_share. RFC 8446 §4.1.4 then leaves the server two choices: answer with a HelloRetryRequest naming that group (supported), or abort with an alert (not supported). That gives a definitive yes/no with no cryptography on our side.

The browser-realistic probe sends what Chrome, Firefox and Safari send: an X25519MLKEM768 share and an x25519 share. The group the server picks is what real visitors get, so this probe decides the verdict. A server can support the hybrid and still choose x25519.

A valid-format ML-KEM key. FIPS 203 requires servers to reject encapsulation keys with any 12-bit coefficient ≥ q = 3329, so random bytes don't work. The tester reduces every coefficient mod q before encoding. The server accepts the key, encapsulates against it and returns its 1088-byte ciphertext, which is visible in the Codebook hexdump.

Scope. The result covers whatever terminates TLS for that name and port, usually a CDN or load balancer. Origins, APIs, mail and VPN endpoints negotiate separately. Certificates and signatures are still classical across the WebPKI, which is a separate migration and not a harvest-now-decrypt-later risk.

Key-exchange group reference

IANA TLS Supported Groups
CodeNameClassLayoutClient BServer BSpec