How to scan your codebase for post-quantum cryptographic risk

Jahanzeb Raja — Tue, 05 May 2026 22:12:50 +0000

If you've been following NIST's post-quantum cryptography standardization process, you already know the threat is real. In August 2024, NIST finalized the first three PQC standards: ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium), and SLH-DSA (SPHINCS+).

But here's the problem most engineering teams face: they don't know what cryptography is actually running in their codebase.

Why this matters now

The "harvest now, decrypt later" attack is already happening. Nation-state actors are collecting encrypted traffic today, betting they'll be able to decrypt it once quantum computers are powerful enough. For data that needs to stay confidential for 5+ years, this is not a future problem.

CNSA 2.0 (NSA's Commercial National Security Algorithm Suite) has set deadlines:

Software and firmware: migrate by 2025
Networking equipment: migrate by 2026
General purpose systems: migrate by 2030

What algorithms are actually at risk

These are the algorithms that quantum computers will break using Shor's algorithm:

Algorithm	Used for	Status
RSA-2048	Encryption, signatures	Vulnerable
ECDSA P-256	TLS, JWT, SSH	Vulnerable
ECDH	Key exchange	Vulnerable
Diffie-Hellman	Key agreement	Vulnerable

These are weakened but not broken by Grover's algorithm:

Algorithm	Used for	Status
AES-128	Symmetric encryption	Downgrade to 64-bit security
SHA-1	Hashing	Already deprecated
MD5	Hashing	Already deprecated
3DES	Legacy encryption	Vulnerable

AES-256 and SHA-256 remain safe against known quantum attacks.

How to find cryptographic risk in your code

The naive approach is grepping for algorithm names. This misses a lot.

# This will miss most real-world usage
grep -r "RSA" ./src

Real cryptographic usage hides in:

Library imports (from cryptography.hazmat.primitives.asymmetric import rsa)
Configuration files (ssl_protocols TLSv1 TLSv1.1)
Certificate handling code
JWT libraries using RS256 or ES256 signing
SSH key generation
TLS configuration in web servers

A proper scan needs to understand context, not just pattern match.

What a real scan looks like

I built CipherAhead to solve this. Here's what scanning the Apache HTTPD repository surfaces:

57 findings across the codebase
6 critical issues including Diffie-Hellman key exchange and TLS 1.0 support
Specific file and line references for each finding
Remediation mapped to NIST PQC standards

For example, in modules/ssl/ssl_engine_init.c:

// Line 122 - CRITICAL
DH_generate_key(dh); DH_compute_key(shared_secret, peer_pub_key, dh);
// Fix: migrate to X25519 or ML-KEM post-quantum key exchange

And in the same file:

// Line 910 - HIGH
SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION);
// Fix: require TLS 1.3 as minimum

A scan across popular open source projects

After scanning 97 real-world projects, here's what the data shows:

9,869 total findings
39 critical risk findings
42 high risk findings
Only Angular scored 0 (fully PQC-safe in its own code)
Apache Tomcat: 152 findings, 15 critical
Bitcoin Core: 190 findings, 4 critical
Classical cryptography still dominates across the ecosystem

Where to start in your own codebase

Inventory first: list every library that handles cryptography
Focus on data in transit: TLS configurations, API authentication
Focus on data at rest: encryption keys, certificate management
Check JWT signing algorithms: RS256 and ES256 are vulnerable, switch to EdDSA as an intermediate step
Audit SSH keys: RSA keys should be replaced with Ed25519

The migration path

For each vulnerable algorithm, NIST recommends:

Key exchange: migrate to ML-KEM (CRYSTALS-Kyber)
Digital signatures: migrate to ML-DSA (CRYSTALS-Dilithium) or SLH-DSA
Symmetric encryption: upgrade AES-128 to AES-256
Hashing: move from MD5/SHA-1 to SHA-256 or SHA-3

Most major libraries already support these. OpenSSL 3.x, BouncyCastle, and libsodium have PQC implementations available.

Try it on your own repo

You can scan any public GitHub repository or web URL at cipherahead.com for free. No install required.

The goal isn't to panic — most production systems have years before quantum computers become a real threat. But cryptographic migrations take time, and understanding your current exposure is the first step.

If you found this useful or have questions about PQC migration, drop a comment below.

DEV Community: Jahanzeb Raja