Breaking Down the Quantum Challange: TLS Cipher Suite Vulnerabilities and FIPS Post-Quantum Standards Explained
Our Cipher Landscape and Quantum Considerations
Understanding quantum computing's impact on current classical cryptography provides us a foundation for effective post-quantum cryptography migration planning. Current TLS implementations rely on RSA and ECDSA algorithms that future quantum computers could potentially compromise, while symmetric ciphers will need increased key sizes (if you're haven't updated in a while). It's time to update to Post-Quantum Cryptogray (PQC). Don't worry, it's not as bad as it sounds.
Join F5 DevCentral Community Evangelist Chase Abbott as he give us a technical overview examining specific considerations, new FIPS standards that address them, and some fun around OpenSSL oqs libraries that will make all our lives a little bit better.
The evolution to post-quantum TLS represents a significant but manageable upgrade to secure communications infrastructure. Organizations that understand these technical details and begin planning now have excellent opportunities to implement these changes systematically and successfully.
The standards are ready. The tools are maturing. You have questions don't you? Well... ask away. Below is informational for referencing requirements against your unique compliance needs.
Happy PKI'ing!
RSA-Based Cipher Suites: Quantum Computing Considerations
Logical qubit estimation is dependent on several variables including the logical:hardware qubit ratios needed depending on hardware implementation and efficiency of system processing the algorithms. This is all subject to change as improvements in quantum systems make our lives more interesting.
Common RSA-based TLS 1.2/1.3 Cipher Suites:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384Shor's Algorithm Impact on RSA:
- RSA-2048: Breakable by a quantum computer with ~4,099 logical qubits
- RSA-3072: Requires ~6,147 logical qubits
- RSA-4096: Requires ~8,194 logical qubits
ECDSA/ECDH Cipher Suites: Quantum Computing Impact
Common Elliptic Curve TLS Implementations:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256Shor's Algorithm vs. Elliptic Curves:
- P-256 (secp256r1): Breakable with ~2,330 logical qubits
- P-384 (secp384r1): Requires ~3,484 logical qubits
- P-521 (secp521r1): Requires ~4,719 logical qubits
Symmetric Cryptography and Grover's Algorithm
Current Symmetric Algorithms in TLS:
AES-128: Effective security reduced to 64-bit (broken)
AES-256: Effective security reduced to 128-bit (acceptable)
ChaCha20: Effective security reduced to 128-bit (acceptable)
SHA-256: Effective security reduced to 128-bit (acceptable)
SHA-384: Effective security reduced to 192-bit (strong)Grover's Algorithm Impact:
- Quadratic speedup: √N time complexity vs. N for classical attacks
- AES-128: Reduced from 128-bit to 64-bit effective security (inadequate)
- AES-256: Reduced from 256-bit to 128-bit effective security (acceptable for most uses)
- Hash functions: SHA-256 becomes 128-bit secure, SHA-384 becomes 192-bit secure
New FIPS Standards: Post-Quantum Cryptographic Algorithms
FIPS 203: ML-KEM (Key Encapsulation Mechanism)
Lattice-based key establishment replacing ECDH:
| Algorithm | Security Level | Public Key Size | Ciphertext Size |
|---|---|---|---|
| ML-KEM-512 | AES-128 equivalent | 800 bytes | 768 bytes |
| ML-KEM-768 | AES-192 equivalent | 1,184 bytes | 1,088 bytes |
| ML-KEM-1024 | AES-256 equivalent | 1,568 bytes | 1,568 bytes |
Implementation Note: ML-KEM provides IND-CCA2 security and replaces ECDH/RSA key exchange in TLS 1.3.
FIPS 204: ML-DSA (Digital Signature Algorithm)
Lattice-based signatures replacing RSA/ECDSA:
| Algorithm | Security Level | Public Key Size | Signature Size |
|---|---|---|---|
| ML-DSA-44 | AES-128 equivalent | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | AES-192 equivalent | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | AES-256 equivalent | 2,592 bytes | 4,627 bytes |
Critical Differences from Classical Signatures:
- Stateless: Unlike hash-based signatures, ML-DSA doesn't require state management
- Variable signature size: Signatures vary slightly in length (±32 bytes)
- Memory requirements: Higher RAM usage during signing/verification
FIPS 205: SLH-DSA (Stateless Hash-Based Signatures)
Backup signature scheme with minimal security assumptions:
SLH-DSA-128s: Small signatures (~7KB), slow signing
SLH-DSA-128f: Fast signing, large signatures (~17KB)
SLH-DSA-192s/f: Medium security level variants
SLH-DSA-256s/f: High security level variantsUse Cases: Long-term signatures, firmware signing, root CA certificates where performance is less critical.
If you have updates to this and we're not paying attention, hit us up in the comments and we can make changes accordingly. Mahalo!
