Quantum-Vulnerable Algorithm Reference
Which cryptographic algorithms are broken, weakened, or safe against quantum computers — mapped to every context where cryptography is used.
Asymmetric (Public Key) Algorithms — All Broken by Quantum
Shor's algorithm efficiently solves the mathematical problems underpinning all current public-key cryptography. All asymmetric algorithms based on integer factorisation (RSA), discrete logarithm (DH, DSA), or elliptic curve discrete logarithm (ECDSA, ECDH, Ed25519) are completely broken by a CRQC. Increasing key sizes does not help — Shor's algorithm scales efficiently.
| Algorithm | Type | Classical Security | Quantum Status | Quantum Attack | Replacement |
|---|---|---|---|---|---|
| RSA-2048 | Key exchange, digital signatures | 112 bits | BROKEN | Shor's algorithm factors N in polynomial time. All key sizes broken. | ML-KEM (key exchange), ML-DSA (signatures) |
| RSA-4096 | Key exchange, digital signatures | 140 bits | BROKEN | Shor's algorithm — larger key sizes do NOT help against quantum. | ML-KEM, ML-DSA |
| DH (Diffie-Hellman) 2048 | Key exchange | ~112 bits | BROKEN | Shor's algorithm solves discrete log problem efficiently. | ML-KEM (FIPS 203) |
| ECDH / ECDHE | Key exchange (TLS, SSH, VPN) | 128 bits (P-256) | BROKEN | Shor's algorithm applied to elliptic curve discrete log. | ML-KEM (FIPS 203) |
| ECDSA (P-256, P-384) | Digital signatures | 128–192 bits | BROKEN | Shor's algorithm recovers private key from public key. | ML-DSA (FIPS 204), SLH-DSA (FIPS 205) |
| Ed25519 / EdDSA | Digital signatures (SSH, TLS) | 128 bits | BROKEN | Based on elliptic curve — broken by Shor's algorithm. | ML-DSA (FIPS 204) |
| DSA | Digital signatures | 80–112 bits | BROKEN | Discrete log problem — Shor's algorithm applies. | ML-DSA (FIPS 204) |
| ElGamal | Encryption, key exchange | 112–128 bits | BROKEN | Discrete log problem. | ML-KEM (FIPS 203) |
| X25519 (Curve25519) | Key exchange (TLS 1.3, Signal) | 128 bits | BROKEN | Elliptic curve — quantum vulnerable. | X25519Kyber768 hybrid (interim), ML-KEM (full migration) |
Symmetric Algorithms & Hash Functions
Grover's algorithm provides a quadratic speedup against symmetric cryptography — effectively halving the bit security. AES-256 (256-bit → 128-bit effective quantum security) remains acceptable. AES-128 (128-bit → 64-bit effective) is marginal. Hash functions are similarly affected but SHA-256 and above remain safe at adequate security levels.
| Algorithm | Classical Security | Quantum Security | Quantum Status | Grover Impact | Action |
|---|---|---|---|---|---|
| AES-256 | 256 bits | 128 bits effective | SAFE | Grover halves to 128-bit — still acceptable for long-term use. | No migration needed. Preferred algorithm. |
| AES-192 | 192 bits | 96 bits effective | SAFE | Grover halves to 96-bit — acceptable but AES-256 preferred. | Acceptable. Prefer AES-256 for new implementations. |
| AES-128 | 128 bits | 64 bits effective | WEAKENED | Grover reduces to 64-bit — borderline security. Not recommended for long-term secrets. | Upgrade to AES-256 for data requiring 10+ year protection. |
| ChaCha20 | 256 bits | 128 bits effective | SAFE | Equivalent to AES-256 quantum security. | No migration needed. |
| 3DES | 112 bits | 56 bits effective | DEPRECATED | Already broken classically (Sweet32 attack). Quantum makes it worse. | Migrate immediately — this is a classical vulnerability. |
| DES | 56 bits | 28 bits effective | DEPRECATED | Broken since the 1990s classically. Not quantum-specifically broken. | Migrate immediately — should not exist in any system. |
| SHA-256 | 256 bits | 128 bits effective | SAFE | Grover reduces collision resistance — 128-bit preimage resistance remains. | Safe for all current uses. No migration needed. |
| SHA-384 | 384 bits | 192 bits effective | SAFE | Strong quantum security margin. | Preferred for long-term data integrity. |
| SHA-512 | 512 bits | 256 bits effective | SAFE | Highest quantum security margin of SHA-2 family. | Preferred for highest security requirements. |
| SHA-3 (256/384/512) | 256–512 bits | 128–256 bits effective | SAFE | Grover applies — SHA-3-256 has 128-bit quantum security. | Safe. SHA-3-256 equivalent to SHA-256 quantum resistance. |
| SHA-1 | 160 bits | 80 bits effective | DEPRECATED | Already broken classically (SHAttered attack, 2017). Quantum irrelevant. | Migrate immediately — classical collision attack exists. |
| MD5 | 128 bits | 64 bits effective | DEPRECATED | Broken classically. Should not be used anywhere. | Migrate immediately. |
| BLAKE2/BLAKE3 | 256–512 bits | 128–256 bits effective | SAFE | No known quantum speedup beyond Grover. | Safe and fast. Good alternative to SHA-2/3. |
| Argon2 / bcrypt (password hashing) | Variable (cost-based) | Cost function remains strong | SAFE | Memory-hard functions limit parallelism even on quantum hardware. | No migration needed. Use for password storage. |
| HMAC-SHA256 | 256 bits | 128 bits effective | SAFE | Security depends on hash — SHA-256 is quantum safe. | No migration needed. |
Quantum Vulnerability by Use Case
| Where Cryptography Is Used | Current Algorithm | Quantum Status | Priority | Migration Path |
|---|---|---|---|---|
| TLS 1.3 HTTPS (key exchange) | X25519 / ECDHE | BROKEN | High | Enable X25519Kyber768 hybrid (supported in Chrome, Firefox, Cloudflare, AWS) now. Full ML-KEM migration 2025–2027. |
| TLS 1.3 HTTPS (certificate) | ECDSA (P-256) or RSA-2048 | BROKEN | Medium-High | Hybrid certificates (classical + ML-DSA) are in draft. CAs beginning to offer PQC. Migrate certificate infrastructure 2025–2028. |
| SSH (key exchange) | ECDH / DH | BROKEN | High | OpenSSH 9.0+ supports hybrid PQC (sntrup761x25519). Enable now for forward secrecy. |
| SSH (host/user authentication) | ECDSA, RSA, Ed25519 | BROKEN | Medium | NIST PQC SSH support coming in OpenSSH. Rotate to ML-DSA keys when available. |
| VPN / IPSec IKEv2 | ECDH, DH | BROKEN | High | StrongSwan and OpenIKED support post-quantum key exchange. Enable hybrid PQC now for high-sensitivity VPNs. |
| VPN (WireGuard) | Curve25519 | BROKEN | Medium | WireGuard post-quantum fork (PQ WireGuard) exists. Not yet mainline. Monitor for upstream support. |
| JWT / API authentication | RSA (RS256), ECDSA (ES256) | BROKEN | Medium | Switch to symmetric HMAC-based JWT (HS256) now as interim — HMAC-SHA256 is quantum safe. Long-term: ML-DSA signed JWT. |
| Code signing | RSA, ECDSA | BROKEN | Medium-High | Microsoft, Apple, and Linux distributions will need PQC code signing. ML-DSA for new signing infrastructure. |
| S/MIME email signing | RSA, ECDSA | BROKEN | Low-Medium | Low urgency — email content rarely needs 10+ year secrecy. Monitor RFC progress. |
| PGP / GPG email encryption | RSA, ECDH | BROKEN | Medium | OpenPGP RFC 9580 adds ML-KEM support. Migrate PGP keys for sensitive long-term communications. |
| DNSSEC | RSA, ECDSA | BROKEN | Medium | IETF working on PQC DNSSEC. ML-DSA signatures for DNS records. Timeline: 2025–2028. |
| PKI / X.509 Certificates | RSA-2048/4096, ECDSA | BROKEN | High | Entire CA hierarchy needs migration. Hybrid certs as interim. Full PQC CAs by 2028. |
| Blockchain / crypto wallets | ECDSA, EdDSA | BROKEN | High (long-term) | Bitcoin, Ethereum vulnerable — no migration path yet. Active research. Major ecosystem challenge. |
| Database Transparent Encryption (TDE) | AES-256 (data), RSA (key wrap) | Partial | Medium | AES-256 is safe. RSA key wrapping is vulnerable — migrate key management to ML-KEM. |
| Full disk encryption | AES-256/128 + RSA or ECDH key | Partial | Low | AES-256 body encryption is safe. Pre-boot authentication keys may use RSA — check and migrate. |
| TOTP / authenticator apps | HMAC-SHA1 (HOTP), HMAC-SHA256 | SAFE | None | HMAC is quantum-safe. TOTP is not quantum-vulnerable. |
NIST PQC Replacement Algorithms (Finalised August 2024)
| NIST Standard | Algorithm | Replaces | Use For | Key/Sig Size | Performance |
|---|---|---|---|---|---|
| FIPS 203 | ML-KEM (Kyber) | ECDH, ECDHE, DH, RSA key exchange | Key encapsulation — establish shared secrets for TLS, VPN, SSH key exchange | Public key: 1,184B (768). Ciphertext: 1,088B | Fast — comparable to ECDH. Recommended for most applications. |
| FIPS 204 | ML-DSA (Dilithium) | ECDSA, RSA-PSS, EdDSA, DSA | Digital signatures — code signing, certificate signing, JWT, TLS certificates | Public key: 1,952B. Signature: 3,293B (level 3) | Fast signing and verification. Primary recommendation for signatures. |
| FIPS 205 | SLH-DSA (SPHINCS+) | ECDSA, RSA — where stateless hash-based is needed | Signatures when minimal trust in implementation security is required. Backup algorithm. | Public key: 32B. Signature: 49,856B (fast variant) | Slow — very large signatures. Use ML-DSA unless specific reasons for SPHINCS+. |
Interim hybrid approach (deploy now)
| Hybrid Combination | Where Supported | Security Property |
|---|---|---|
| X25519Kyber768 | Chrome 116+, Firefox 119+, Cloudflare, AWS, nginx (with patch) | Secure if EITHER classical OR PQC is unbroken. Best of both worlds. |
| P-256 + ML-KEM-512 | Draft IETF RFC — emerging TLS support | Hybrid for standards-compliant deployment where P-256 is mandated. |
| RSA-2048 + ML-DSA | Hybrid X.509 certificates (LAMPS WG draft) | Transition certificate usable by both classical and PQC-capable clients. |
| ECDSA + ML-DSA (composite) | Draft — not yet widely supported | Composite signature for PKI migration compatibility. |