Post-Quantum Cryptography

Quantum-resistant algorithms, hybrid migration strategies, crypto agility, and NIST PQC standardization timeline for practical adoption.

Post-quantum cryptography (PQC) addresses the threat that large-scale quantum computers pose to current public-key cryptography including RSA and elliptic curve cryptography (ECC). Security engineers build cryptographic agility and plan migrations to NIST-selected PQC algorithms with minimal business disruption.

Effective PQC migration requires:

• Cryptographic inventory of all algorithm usage across systems
• Hybrid approaches combining classical and quantum-resistant algorithms during transition
• Coordination across dependencies, partners, and certificate authorities

Quantum computers capable of breaking RSA and ECC do not yet exist at scale, but the harvest-now-decrypt-later threat requires action today for long-lived confidential data.

Quantum Threat to Cryptography

Vulnerable vs. Resistant Algorithm Classes

Understanding which cryptographic primitives are vulnerable to quantum attacks guides migration prioritization:

Algorithm Type	Quantum Vulnerability	Attack Vector	Mitigation
RSA	Critical	Shor’s algorithm breaks integer factorization	Replace with ML-KEM or ML-DSA
Diffie-Hellman	Critical	Shor’s algorithm solves discrete logarithm	Replace with ML-KEM
ECDSA/ECDH	Critical	Shor’s algorithm solves elliptic curve discrete logarithm	Replace with ML-DSA/ML-KEM
AES-128	Moderate	Grover’s algorithm provides quadratic speedup	Upgrade to AES-256
AES-256	Low	Grover’s reduces effective security to 128-bit	Generally acceptable
SHA-256/SHA-3	Low	Grover’s provides quadratic speedup	Consider SHA-384 or SHA-512

Harvest-Now-Decrypt-Later (HNDL) Threat

Adversaries can capture encrypted data today and decrypt it when cryptographically-relevant quantum computers (CRQCs) become available. This threat model affects:

• Government classified data with multi-decade confidentiality requirements
• Healthcare records protected under long-term privacy regulations
• Financial data including long-term contracts and trade secrets
• Intellectual property with extended competitive value

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

The NIST Post-Quantum Cryptography Standardization Project finalized its first standards in August 2024, providing the foundation for quantum-resistant cryptography adoption.

Key Encapsulation Mechanisms (KEMs)

KEMs replace Diffie-Hellman and RSA key exchange, enabling quantum-resistant key establishment for TLS, SSH, and other protocols.

Algorithm	NIST Standard	Use Case	Key Size	Ciphertext Size
ML-KEM (Kyber)	FIPS 203	General-purpose key exchange	800-1568 bytes	768-1568 bytes
Classic McEliece	Under consideration	Conservative alternative	~1 MB	128-240 bytes

ML-KEM (formerly CRYSTALS-Kyber) is the primary standard for general use, offering strong security with practical performance characteristics suitable for high-volume TLS deployments.

Digital Signatures

Signature algorithms replace RSA and ECDSA, enabling quantum-resistant authentication, code signing, and document integrity verification.

Algorithm	NIST Standard	Use Case	Public Key	Signature Size
ML-DSA (Dilithium)	FIPS 204	General-purpose signatures	1312-2592 bytes	2420-4627 bytes
FN-DSA (Falcon)	Draft standard	Bandwidth-constrained applications	897-1793 bytes	666-1280 bytes
SLH-DSA (SPHINCS+)	FIPS 205	Conservative hash-based alternative	32-64 bytes	7856-49856 bytes

ML-DSA is recommended for most applications. SLH-DSA provides a conservative fallback based on well-understood hash function security.

Standardization Timeline

1. August 2024: NIST published final FIPS 203, 204, and 205 standards
2. 2024-2025: Additional algorithms under evaluation (including HQC for KEMs)
3. Ongoing: IETF PQC Working Group developing protocol integrations

Migration Strategy

Step 1: Cryptographic Inventory

Before migrating, conduct a comprehensive inventory of all cryptographic usage:

• Protocols: TLS versions, SSH configurations, IPsec/VPN tunnels, QUIC implementations
• Libraries: OpenSSL, BoringSSL, libsodium, platform-specific crypto providers
• Key material: RSA/ECC keys, certificates, tokens, API keys
• Data stores: Encrypted databases, key management systems, HSMs

Prioritize inventory items by:

1. Confidentiality duration — data requiring 10+ years protection
2. Algorithm type — RSA/ECC before symmetric/hash
3. Exposure — internet-facing services before internal systems

Step 2: Establish Cryptographic Agility

Cryptographic agility enables algorithm changes without code modifications—essential for any PQC migration:

• Version algorithms and key types in configuration rather than code
• Use pluggable cryptographic providers (e.g., OpenSSL 3.x provider architecture)
• Eliminate hardcoded algorithms that prevent migration
• Abstract cryptographic operations behind interfaces that support algorithm negotiation

Step 3: Implement Hybrid Approaches

Hybrid cryptography combines classical and PQC algorithms, providing security if either algorithm remains secure:

Hybrid Type	Example Combination	Use Case
Hybrid KEM	X25519 + ML-KEM-768	TLS 1.3 key exchange
Hybrid Signature	Ed25519 + ML-DSA-65	Code signing, certificates
Composite Certificate	ECDSA + ML-DSA	X.509 certificate chains

Hybrid approaches are recommended during transition because:

• They hedge against undiscovered weaknesses in new PQC algorithms
• They maintain classical security if PQC implementations have bugs
• IETF draft standards are maturing for protocol integration

Step 4: Performance Testing

PQC algorithms have different performance characteristics than classical algorithms. Test for:

• Key and signature sizes — ML-DSA signatures are ~40x larger than ECDSA
• MTU fragmentation — larger TLS handshakes may exceed 1500-byte MTU limits
• Latency impacts — some PQC operations are slower than classical equivalents
• Memory pressure — larger keys affect embedded and IoT devices

Testing guidance: Conduct performance testing in production-representative environments. Lab testing often underestimates real-world impacts from network conditions and concurrent load.

Dependencies and Supply Chain

Library Support Status

Cryptographic library support is a prerequisite for PQC migration. Track these implementations:

Library	PQC Status	Notes
OpenSSL 3.x	Provider-based support	Via OQS provider
BoringSSL	ML-KEM integrated	Used by Chrome, Android
AWS-LC	ML-KEM, ML-DSA	FIPS-validated builds available
liboqs	Reference implementations	Open Quantum Safe Project
wolfSSL	ML-KEM, ML-DSA	FIPS 140-3 path available

FIPS 140-3 validation for PQC algorithms is in progress through NIST’s Cryptographic Module Validation Program (CMVP). Environments requiring FIPS validation should track validation timelines closely.

Partner and Vendor Coordination

Protocol interoperability requires both parties to support PQC—unilateral migration is insufficient:

• Request vendor PQC roadmaps for all cryptographic dependencies
• Participate in industry working groups through IETF, CA/Browser Forum, and sector-specific bodies
• Test interoperability early using reference implementations
• Plan for asymmetric migration where some partners migrate faster than others

Certificate Authority Support

Certificate Authorities must issue PQC certificates for quantum-resistant TLS:

• Track CA timelines for PQC certificate issuance support
• Consider hybrid certificates combining classical and PQC signatures as interim solution
• Plan for certificate chain impacts — PQC certificates are significantly larger
• Monitor CA/Browser Forum developments for baseline requirements updates

Migration Timeline and Prioritization

Risk-Based Prioritization Matrix

Prioritize migration based on data sensitivity and exposure:

Priority	Data Characteristics	Timeline
Critical	National security, 25+ year confidentiality, state-level adversaries	Immediate
High	Financial, healthcare, 10-25 year confidentiality	2025-2026
Medium	Business sensitive, 5-10 year confidentiality	2026-2028
Lower	Short-lived session data, public data with integrity requirements	2028-2030

High-value targets including government, defense, finance, and healthcare face greater threat actor interest and should accelerate timelines accordingly.

Phased Migration Approach

Avoid big-bang migrations. Phase implementation to manage risk:

1. Phase 1 — Foundation (Current)

   • Establish cryptographic agility architecture
   • Deploy hybrid key exchange in non-critical systems
   • Complete cryptographic inventory
   • Train security and development teams

2. Phase 2 — Priority Systems (2025-2027)

   • Migrate systems protecting long-lived confidential data
   • Implement hybrid TLS for internet-facing services
   • Update certificate infrastructure for hybrid certificates

3. Phase 3 — Complete Migration (2027-2030+)

   • Migrate remaining systems to PQC-only where appropriate
   • Deprecate classical-only cryptographic paths
   • Achieve full quantum resistance across infrastructure

Standards and Compliance Tracking

Track these authoritative sources for PQC requirements:

• NIST PQC Project — algorithm standards and updates
• NSA CNSA 2.0 — requires PQC for National Security Systems by 2030-2035
• IETF PQUIP Working Group — protocol integration standards
• CISA PQC Initiative — guidance for critical infrastructure

Warning: Avoid non-standardized PQC algorithms in production. Algorithms without NIST standardization lack sufficient peer review and may contain undiscovered vulnerabilities.

Implementation Considerations

Key and Certificate Management

PQC keys and certificates are significantly larger than classical equivalents:

Component	Classical Size	PQC Size	Impact
ECDSA public key	64 bytes	ML-DSA-65: 1952 bytes	30x increase
RSA-2048 signature	256 bytes	ML-DSA-65: 3309 bytes	13x increase
X.509 certificate	~1-2 KB	~5-10 KB with PQC	Storage, bandwidth

Key management considerations:

• Update KMS systems to support PQC key types and larger key sizes
• Review HSM capabilities for PQC algorithm support
• Adjust certificate lifecycle processes for larger certificate chains
• Plan for increased bandwidth in certificate distribution

Protocol-Specific Changes

Protocol	PQC Impact	Considerations
TLS 1.3	Larger handshakes (3-5 KB additional)	MTU fragmentation, connection latency
SSH	Larger key exchange messages	May require protocol version updates
IPsec/IKEv2	Larger IKE_SA_INIT exchanges	VPN gateway updates required
S/MIME, PGP	Larger encrypted messages	Email system compatibility

Backward Compatibility

During the transition period, systems must maintain interoperability:

• Implement algorithm negotiation supporting both classical and PQC options
• Use hybrid modes where protocol support exists
• Plan time-limited classical fallback for legacy system compatibility
• Monitor and log algorithm negotiation to track migration progress

Conclusion

Post-quantum cryptography addresses the existential threat that quantum computers pose to current public-key cryptography. Security engineers must build cryptographic agility now and execute phased migrations to NIST-selected PQC algorithms, prioritizing long-lived confidential data and leveraging hybrid approaches during transition.

Key success factors:

• Comprehensive cryptographic inventory across all systems
• Library and dependency updates aligned with vendor roadmaps
• Partner coordination for protocol interoperability
• Risk-based prioritization focusing on harvest-now-decrypt-later threats

Organizations investing in PQC migration today protect sensitive data against future quantum threats while building the cryptographic flexibility needed for long-term security resilience.

References

• NIST Post-Quantum Cryptography Project
• NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
• IETF PQUIP Working Group — TLS, SSH, X.509 PQC integration
• NSA CNSA 2.0 Announcement — National Security Systems requirements
• CISA Post-Quantum Cryptography Initiative
• Open Quantum Safe Project — reference implementations and testing tools
• Cloud Security Alliance PQC Guidelines