One server. One certificate. Two listeners — one classical, one quantum-safe. This page tells you which one you are on right now, tests your own browser, and hands you the commands to verify every claim yourself.
Reading the listener that served this page.
Same URL, same certificate, same machine — only the listener changes. Flip between the two and watch the verdict above change with it.
Listener B accepts only post-quantum key exchange. Any client that cannot do ML-KEM is refused during the TLS handshake — there is no fallback to fail into. If the request below succeeds, your browser genuinely negotiated post-quantum cryptography.
Opening a TLS connection to the post-quantum-only listener.
Both listeners present the identical Let's Encrypt certificate for the identical hostname on the identical host. The only difference is the key-exchange group each will accept.
| Listener A | Listener B | Classical (control) | |
|---|---|---|---|
| Purpose | Serves this site, quantum-safe | Live browser capability test | Everything a normal server does today |
| Endpoint | pqc.app2u.click:9443 | pqc.app2u.click:9444 | pqc.app2u.click:443 |
| Key exchange | X25519MLKEM768 + classical fallback | X25519MLKEM768 only | X25519 / P-256 |
| Quantum-safe | YES | YES — enforced | NO |
| Harvest-now-decrypt-later | Protected | Protected | Exposed |
| TLS stack | Go 1.25 crypto/tls | Go 1.25 crypto/tls | OpenSSL 3.0 |
Why two stacks. ML-KEM landed in OpenSSL 3.5. The classical listener runs the distribution's OpenSSL 3.0, where the algorithm does not exist at all — it cannot be switched on, only replaced. The quantum-safe listeners run a Go 1.25 TLS stack alongside it, on their own ports, touching nothing the classical server owns. That is the migration pattern this demo exists to show: add capability beside production, prove it, then move traffic — never rip out a running cryptographic stack and hope.
Do not take our word for it. These commands run against the public internet from your
own machine. You need OpenSSL 3.5 or newer — check with openssl version.
# offer ONLY the post-quantum group, no fallback allowed openssl s_client -connect pqc.app2u.click:9444 \ -tls1_3 -groups X25519MLKEM768 </dev/null expected → Negotiated TLS1.3 group: X25519MLKEM768 handshake succeeds
# identical client, identical hostname, classical port openssl s_client -connect pqc.app2u.click:443 \ -tls1_3 -groups X25519MLKEM768 </dev/null expected → tls alert handshake failure (alert 40) no shared group
# the enforcement runs both ways openssl s_client -connect pqc.app2u.click:9444 \ -tls1_3 -groups X25519 </dev/null expected → tls alert handshake failure classical is not accepted here
Two opposite results, same server, same certificate, same minute. That is the difference between a claim and a proof.
Quantum computers do not need to exist yet to put your data at risk. That is the part most briefings get wrong.
An adversary records your encrypted traffic today and simply stores it. When a cryptographically relevant quantum computer arrives, they decrypt the archive retroactively. Nothing you do in 2032 protects what was captured in 2026.
Ask one question: how long must this stay confidential? Payroll, medical records, identity documents, contracts, national data — if the answer is longer than about eight years, today's key exchange is already the wrong tool.
X25519MLKEM768 runs the classical and post-quantum algorithms together. An attacker must break both. If ML-KEM is ever weakened, X25519 still holds — so adopting it early carries no downside risk.
Dates published by standards bodies and regulators, not vendor marketing.
| Source | Instrument | What it says |
|---|---|---|
| NACSA / Ministry of Digital Malaysia |
National PQC Readiness Roadmap 29 Oct 2025 |
A 2025–2030 framework across technical readiness, strategic alignment and workforce. Explicitly non-binding — each entity defines its own migration path and cryptographic-agility posture. |
| NIST United States |
IR 8547 — transition guidance | RSA-2048 and ECC P-256 deprecated after 2030, disallowed after 2035. |
| NSA United States |
CNSA 2.0 | ML-KEM-1024 and ML-DSA-87 mandatory across national security systems by 2035, with networking equipment moving far earlier. |
| Bank Negara Malaysia | RMiT | Does not mandate PQC. It does harden cryptographic key management and algorithm governance — the crypto-agility groundwork a migration depends on. |
An honest note on urgency. No cryptographically relevant quantum computer exists today. Expert surveys put roughly a one-in-four chance by 2030 and one-in-two by 2035. Anyone quoting you a precise date is selling fear. The reason to move now is not the date — it is that harvest-now-decrypt-later makes the exposure retroactive, and that migrating a real estate of systems takes years of planning, not a weekend.
The order matters more than the algorithm.