NIST FIPS 203 / 204 / 205
Post-Quantum Cryptography Scanner
Written and maintained by Hendrik Schneider · Last reviewed · How we check this
Korthex scans source code, dependencies, binaries, TLS certificates and git history for quantum-vulnerable cryptography - RSA, ECC, Diffie-Hellman and DSA - buckets every finding by post-quantum readiness, and generates a concrete migration plan to ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). 100% on-premise: source never leaves your infrastructure.
What is a post-quantum cryptography scanner?
A post-quantum cryptography scanner is a static-analysis tool that finds every use of asymmetric cryptography that a cryptographically relevant quantum computer could break. Shor's algorithm solves integer factorization and discrete logarithms, so the affected primitives are RSA, ECC (ECDSA, ECDH, EdDSA), finite-field Diffie-Hellman, and DSA. Symmetric ciphers and hashes are affected differently: Grover's algorithm halves their effective strength, which is why AES-128 is commonly upgraded to AES-256 during a PQC migration.
Korthex scans 18 languages plus dependencies, binaries, TLS / PKI certificates, databases and git history. Every quantum-vulnerable finding lands in one inventory with file and line, severity, a taint-based verdict, and a post-quantum readiness bucket - a quantum-vulnerable code finder whose output you can hand directly to the team that has to fix it.
Why scan now? Harvest now, decrypt later
Encrypted data recorded today can be stored and decrypted once a sufficiently large quantum computer exists. For anything with a long confidentiality lifetime - health records, financial data, state secrets, firmware signing keys - the migration deadline is set by the attacker's recorder, not by the arrival of the quantum computer. The regulatory timelines reflect that. We track these rather than restate them: each row above maps to rules in the NIST, BSI and CISA channels, and a change in one of them changes what a scan reports.
| Authority | What it requires | When |
|---|---|---|
| NIST | FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) finalised | 13 August 2024 |
| NIST IR 8547 | RSA, ECDSA, EdDSA, DH and ECDH deprecated, then disallowed | after 2030, disallowed 2035 |
| EU coordinated PQC roadmap | Member states begin migration; high-risk systems migrated | from 2025, high-risk by end of 2030 |
| BSI TR-02102 | Quantum-safe hybrid key exchange recommended for new systems | now |
| CNSA 2.0 | ML-KEM / ML-DSA required for US national security systems | schedule began 2025 |
What does Korthex find, and what replaces it?
- RSA and ECDH key exchange: replaced by ML-KEM (FIPS 203), typically run in hybrid mode with a classical algorithm during transition
- RSA, ECDSA and EdDSA signatures: replaced by ML-DSA (FIPS 204)
- Long-lived signing such as firmware and code signing: SLH-DSA (FIPS 205) as the conservative, hash-based option
- TLS endpoints and certificates negotiating quantum-vulnerable key exchange or signed with weak algorithms
- 128-bit symmetric configurations: flagged for upgrade to 256-bit keys in line with BSI and CNSA 2.0 guidance
- Every finding carries file:line evidence, severity, a taint verdict, and its post-quantum readiness bucket in the CBOM
From scan to migration plan
A scan produces a Cryptographic Bill of Materials (CBOM) with a per-finding post-quantum bucket. Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. From the CBOM, Korthex generates a topologically-ordered migration plan: per item the file and line, the replacement algorithm, a deadline, an effort estimate in hours, and the dependency order - with an impact simulation that shows what a change touches before you make it.
Weak cryptography is proven, not pattern-matched: extracted cryptography is graded by emulation against NIST Known-Answer Tests, with a side-channel timing verdict.
A quantum-vulnerable code finder in CI
Korthex ships a GitHub Actions step, a GitLab CI template and a generic CLI exit code for any pipeline. Scans fail above a configurable risk threshold, and SARIF integration puts findings inline in pull requests - so new quantum-vulnerable code fails the build before it merges, and the PQC inventory stays current on every commit.
Frequently asked questions
What makes code quantum-vulnerable?
Any use of RSA, ECC (ECDSA, ECDH, EdDSA), finite-field Diffie-Hellman or DSA for key exchange, encryption or signatures. These primitives rely on integer factorization or discrete logarithms, both of which Shor's algorithm breaks on a cryptographically relevant quantum computer.
Is Korthex a NIST FIPS 203 scanner?
Yes. Korthex maps every quantum-vulnerable finding to its NIST successor standard: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for signatures, SLH-DSA (FIPS 205) for hash-based signatures - and reports FIPS 140-3 compliance status alongside.
Can Korthex plan an ML-KEM migration?
Yes. The migration plan lists every RSA / ECDH key-exchange site with file and line, the ML-KEM replacement, dependency order and an effort estimate, and recommends hybrid (classical plus ML-KEM) modes where appropriate during transition.
Is Korthex only a post-quantum scanner?
No. Korthex is a full cryptography scanner: weak and broken primitives (MD5, SHA-1, DES, 3DES, RC4, Blowfish, AES-ECB / CBC misuse), hardcoded keys and leaked secrets, insecure TLS configurations, and quantum exposure - all in one CBOM.
Does source code leave my infrastructure?
No. Korthex runs 100% on-premise as a CLI or inside CI/CD, including air-gapped operation. Only anonymized metadata is transmitted for the dashboard report.
How long does a post-quantum scan take?
Source analysis of 50,000 to 500,000 lines takes seconds to about half a minute on a current workstation. How long the whole run takes is decided by the depth of the git history and the machine, so korthex.io/scan-duration publishes the cost model and the measurements behind it instead of a flat promise. All 18 supported languages are covered in the same pass.