pqc --check | praneeth.me

praneeth@website:~$ pqc --check [beta]

This page is a tool rather than a document, so it needs JavaScript to do anything — the parsing and classification all happen in your browser. That is also why nothing is sent anywhere: enabling JavaScript only lets the work happen locally, it does not introduce a server.

certificate, key, cipher suite or algorithm name

One per line. Accepts a PEM -----BEGIN CERTIFICATE----- block, an ssh-ed25519 AAAA… line, a suite like ECDHE-RSA-AES128-GCM-SHA256, a JWT, or a plain name (ECDSA P-256, AES-128, ML-KEM-768). Read in your browser; never sent anywhere.

Paste something real — a certificate, an SSH key, a TLS cipher suite, a JWT, or just an algorithm name. Each one is sorted into retire now, quantum-vulnerable — plan to replace, needs a bigger key, or quantum-safe already, with the NIST replacement (FIPS 203 / 204 / 205) and the ASD ISM target parameter. Then the risk check turns “should I care yet” into a number.

standards: FIPS 203 / 204 / 205 · NIST IR 8547 (draft)
framework: ASD LATICE
reads: X.509 · SSH · JWT · TLS suites
what's collected: nothing

Nothing you paste is sent anywhere. Parsing the certificate, classifying the algorithm and running the arithmetic all happen in your browser. There is no server, no analytics and no lookup of any kind — once this page has loaded it makes no network requests at all. It also does not pretend to be a full X.509 parser: it names the algorithms in a certificate, not its expiry or extensions. For a real inventory, the reference below points at the tools built for it.

risk check — Mosca's inequality

If the years your data must stay secret, plus the years it takes you to migrate, run past the years until a quantum computer can break it, then data captured today is already at risk. It does not need a precise date to be useful.

data shelf-life (X) — 10 yr

how long it must stay confidential

migration time (Y) — 4 yr

to move this system to PQC

years to a CRQC (Z) — 9 yr

2030 is ASD's deadline, and the US federal one for post-quantum key establishment. The odds are the ranges experts gave for a cryptographically relevant quantum computer within 10 and 15 years in the Quantum Threat Timeline Report 2025 (Global Risk Institute, March 2026).

data protected to year 14 CRQC ~year 9

reference — classical → post-quantum, and the deadlines

in use today	replacement	note
RSA, Diffie–Hellman, ECDH (key exchange / key transport)	ML-KEM — FIPS 203	Kyber lineage. ASD ISM: ML-KEM-1024 (ML-KEM-768 until 2030).
ECDSA, EdDSA, RSA signatures	ML-DSA — FIPS 204	Dilithium lineage. The general-purpose PQC signature. ASD ISM: ML-DSA-87 (ML-DSA-65 until 2030).
Long-lived signatures — firmware, roots of trust	SLH-DSA — FIPS 205	Hash-based. Conservative, large, slow. Not ASD-approved.
Compact signatures where size matters	FN-DSA / Falcon — FIPS 206	Not final yet.
KEM algorithm diversity (a hedge against a lattice break)	HQC — standard expected 2027	Code-based, not lattice-based.
AES-128	AES-256	Same algorithm; Grover just wants the bigger key. ASD ISM: AES-256 only, beyond 2030.
SHA-256	SHA-256 (keep) / SHA-384 for long-term	Not broken by quantum, and NIST keeps it. ASD ISM: SHA-384 or SHA-512 only, beyond 2030.

Deadlines. NIST IR 8547 — still an initial public draft — proposes deprecating 112-bit-strength RSA, DH and elliptic-curve keys after 2030 and disallowing every quantum-vulnerable public-key algorithm after 2035. US Executive Order 14412 (June 2026) moves federal high-value assets and high-impact systems to post-quantum key establishment by end of 2030 and post-quantum signatures by end of 2031; OMB M-26-15 is how agencies carry it out. ASD recommends ceasing RSA, DH, ECDH and ECDSA by end of 2030: its ISM approves none of them beyond 2030 — nor AES-128/192, SHA-224/256, ML-KEM-768 or ML-DSA-65 — and wants new equipment supporting ML-KEM-1024, ML-DSA-87, SHA-384/512 and AES-256 by then. ASD's plan also wants a refined transition plan by end of 2026 and work started on critical systems by end of 2028. Checked against the September 2026 ISM.

doing this at scale

Open Quantum Safe — liboqs & oqs-provider — C library of the PQC algorithms, plus an OpenSSL 3 provider for hybrid TLS and certificates.
PQClean — Clean, tested reference C implementations — archived read-only in August 2026 and no longer maintained, though many bindings still vendor from it. The PQ Code Package is the maintained successor for ML-KEM and ML-DSA.
@noble/post-quantum — Pure-JavaScript ML-KEM, ML-DSA and SLH-DSA. What you'd reach for to run PQC in a browser or Node.
IBM CBOMkit — Generates a Cryptographic Bill of Materials (CycloneDX) from source and containers — the LATICE 'Locate' phase, automated.
pqcscan — Scans SSH and TLS servers for their stated PQC support and writes a report.
ASD — Planning for post-quantum cryptography (LATICE) — The framework this tool's advice follows: Locate, Assess, Triage, Implement, Communicate & Educate.