Quantum Threat to Cryptography
Vulnerable Algorithms RSA, Diffie-Hellman, and elliptic curve cryptography (ECC) are vulnerable to quantum attacks using Shor’s algorithm. Quantum computers can solve discrete logarithm and integer factorization problems efficiently. Symmetric cryptography including AES is less vulnerable. Grover’s algorithm provides quadratic speedup, requiring doubling of key sizes (AES-256 instead of AES-128). Hash functions are similarly less vulnerable. Doubling output size provides quantum resistance. Harvest-Now-Decrypt-Later Adversaries can capture encrypted data today and decrypt it when quantum computers become available. Long-lived confidential data is at risk today. Data with confidentiality requirements beyond 10-15 years should be protected with PQC now. Waiting until quantum computers exist is too late.NIST Post-Quantum Cryptography Standards
Key Encapsulation Mechanisms (KEMs) CRYSTALS-Kyber is NIST’s selected KEM for general use. Kyber provides quantum-resistant key exchange. Classic McEliece is selected as alternate KEM. McEliece provides conservative alternative with larger keys. KEMs replace Diffie-Hellman and RSA key exchange. KEMs enable quantum-resistant TLS and other protocols. Digital Signatures CRYSTALS-Dilithium is NIST’s selected signature algorithm for general use. Dilithium provides quantum-resistant signatures. Falcon is selected for applications requiring smaller signatures. Falcon has smaller signature sizes than Dilithium. SPHINCS+ is selected as stateless hash-based signature. SPHINCS+ provides conservative alternative. Signature algorithms replace RSA and ECDSA signatures. Signatures enable quantum-resistant authentication and integrity. Standardization Timeline NIST published final PQC standards in 2024. Standards enable implementation and deployment. Additional algorithms are under consideration for future standardization. Diversification provides resilience.Migration Strategy
Cryptographic Inventory Inventory all cryptographic usage including protocols (TLS, SSH, IPsec), libraries, keys, certificates, and tokens. Inventory identifies migration scope. Inventory should identify algorithm types, key sizes, and usage contexts. Detail enables migration planning. Long-lived keys and certificates should be prioritized. Long-lived cryptography has higher risk. Cryptographic Agility Cryptographic agility enables algorithm changes without code changes. Agility is essential for PQC migration. Algorithms and key types should be versioned and configurable. Configuration enables migration. Cryptographic providers should be pluggable. Pluggable providers enable algorithm updates. Hardcoded algorithms should be eliminated. Hardcoding prevents migration. Hybrid Approaches Hybrid key exchange combines classical and PQC algorithms (e.g., X25519 + Kyber). Hybrid provides security if either algorithm is secure. Hybrid signatures similarly combine classical and PQC signatures. Hybrid hedges against PQC algorithm breaks. Hybrid approaches are recommended during transition. Hybrid provides defense-in-depth. Standards including hybrid TLS are under development. Standards enable interoperability. Performance Testing PQC algorithms have different performance characteristics than classical algorithms. Performance testing is essential. Kyber and Dilithium have larger key and signature sizes. Size increases may affect protocols. MTU (Maximum Transmission Unit) impacts should be assessed. Larger handshakes may fragment. Latency impacts should be measured. Some PQC algorithms are slower than classical algorithms. Performance testing should occur in realistic environments. Lab testing may not reflect production.Dependencies and Supply Chain
Library Updates Cryptographic libraries must be updated to support PQC algorithms. Library support is prerequisite for migration. OpenSSL, BoringSSL, and other libraries are adding PQC support. Library updates enable application migration. FIPS 140-3 validation for PQC algorithms is in progress. FIPS validation is required for some environments. Library update timelines should be tracked. Dependencies may delay migration. Partner and Vendor Coordination Partners and vendors must support PQC for interoperability. Coordination is essential. Protocol interoperability including TLS, SSH, and QUIC requires both parties to support PQC. Unilateral migration is insufficient. Vendor roadmaps for PQC support should be obtained. Vendor delays may block migration. Industry coordination through standards bodies accelerates migration. Standards enable ecosystem migration. Certificate Authority Support Certificate Authorities must issue PQC certificates. CA support is required for PQC TLS. CA timelines for PQC support should be tracked. CA delays may block migration. Hybrid certificates combining classical and PQC signatures may be interim solution. Hybrid certificates enable gradual migration.Migration Timeline and Prioritization
Risk-Based Prioritization Long-lived confidentiality data should be prioritized. Harvest-now-decrypt-later risk is highest for long-lived data. Data with 10+ year confidentiality requirements should migrate first. Shorter-lived data has lower urgency. High-value targets including government, finance, and healthcare should prioritize migration. High-value targets face greater threat. Phased Migration Migration should be phased to manage risk and complexity. Big-bang migration is high-risk. Phase 1 should establish cryptographic agility and hybrid approaches. Agility enables future phases. Phase 2 should migrate high-priority systems and data. Priority systems provide most risk reduction. Phase 3 should complete migration across all systems. Complete migration provides full protection. Standards Tracking NIST PQC standards should be tracked for updates. Standards may evolve. IETF protocol standards including TLS and SSH PQC should be tracked. Protocol standards enable interoperability. CNSA 2.0 (Commercial National Security Algorithm Suite) provides government timeline. CNSA 2.0 requires PQC by 2030-2035. Non-standard algorithms should be avoided in production. Non-standard algorithms lack peer review and may be insecure.Implementation Considerations
Key and Certificate Management PQC keys and certificates are larger than classical equivalents. Storage and transmission impacts should be assessed. Key management systems must support PQC key types. KMS updates may be required. Certificate lifecycle management should accommodate PQC certificates. Lifecycle processes may need updates. Protocol Changes TLS handshakes with PQC are larger. Handshake size may affect performance and compatibility. SSH with PQC similarly has larger handshakes. Protocol implementations must handle larger messages. VPN protocols including IPsec require PQC support. VPN updates enable quantum-resistant remote access. Backward Compatibility Backward compatibility with classical cryptography is required during transition. Not all systems will migrate simultaneously. Protocol negotiation should support both classical and PQC algorithms. Negotiation enables gradual migration. Fallback to classical algorithms may be necessary for legacy systems. Fallback should be time-limited.Conclusion
Post-quantum cryptography addresses the threat that quantum computers pose to current public-key cryptography. Security engineers build cryptographic agility and plan phased migrations to NIST-selected PQC algorithms, prioritizing long-lived confidential data and using hybrid approaches during transition. Success requires comprehensive cryptographic inventory, library and dependency updates, partner coordination, and risk-based prioritization. Organizations that invest in PQC migration now protect against harvest-now-decrypt-later threats and prepare for quantum-resistant future.References
- NIST Post-Quantum Cryptography Project
- NIST FIPS 203 (ML-KEM/Kyber), FIPS 204 (ML-DSA/Dilithium), FIPS 205 (SLH-DSA/SPHINCS+)
- IETF PQC Working Group (TLS, SSH, X.509)
- NSA CNSA 2.0 (Commercial National Security Algorithm Suite)
- Cloud Security Alliance PQC Guidelines