A Historic Moment in Cryptography
On August 13, 2024, the National Institute of Standards and Technology (NIST) published the first three finalized post-quantum cryptographic standards. After eight years of analysis, testing, and public review, we now have standardized algorithms designed to resist attacks from both classical and quantum computers.
This is the most significant change to cryptographic standards since the adoption of AES in 2001. Every organization using public-key cryptography will eventually need to migrate to these new algorithms.
The Three Standards
FIPS 203: ML-KEM (Key Encapsulation)
ML-KEM (Module-Lattice-based Key Encapsulation Mechanism) replaces key exchange protocols like ECDH and RSA-KEM.
Use cases:
- TLS/HTTPS key exchange
- VPN tunnel establishment
- Secure messaging (Signal, WhatsApp, etc.)
- API authentication
Security levels:
| Parameter Set | Classical Security | Quantum Security |
|---|---|---|
| ML-KEM-512 | 128-bit | Category 1 |
| ML-KEM-768 | 192-bit | Category 3 |
| ML-KEM-1024 | 256-bit | Category 5 |
Key sizes:
| Parameter Set | Public Key | Ciphertext | Shared Secret |
|---|---|---|---|
| ML-KEM-512 | 800 bytes | 768 bytes | 32 bytes |
| ML-KEM-768 | 1,184 bytes | 1,088 bytes | 32 bytes |
| ML-KEM-1024 | 1,568 bytes | 1,568 bytes | 32 bytes |
FIPS 204: ML-DSA (Digital Signatures)
ML-DSA (Module-Lattice-based Digital Signature Algorithm) replaces RSA and ECDSA for digital signatures.
Use cases:
- Code signing
- Document signing
- Certificate authorities
- Blockchain and cryptocurrencies
Security levels:
| Parameter Set | Classical Security | Quantum Security |
|---|---|---|
| ML-DSA-44 | 128-bit | Category 2 |
| ML-DSA-65 | 192-bit | Category 3 |
| ML-DSA-87 | 256-bit | Category 5 |
Signature sizes:
| Parameter Set | Public Key | Signature |
|---|---|---|
| ML-DSA-44 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 1,952 bytes | 3,293 bytes |
| ML-DSA-87 | 2,592 bytes | 4,595 bytes |
FIPS 205: SLH-DSA (Hash-Based Signatures)
SLH-DSA (Stateless Hash-based Digital Signature Algorithm) provides an alternative signature scheme based on hash functions rather than lattices.
Advantages:
- Based on well-understood hash function security
- Conservative choice if lattice problems are broken
- No complex mathematical structures
Trade-offs:
- Larger signatures (7-50 KB depending on parameters)
- Slower signing and verification
- Best for applications where signature size isn't critical
The "Harvest Now, Decrypt Later" Threat
Why the urgency? Adversaries are already collecting encrypted data today, planning to decrypt it once quantum computers become available. This is called the "harvest now, decrypt later" attack.
Data with long-term sensitivity is at risk:
- Government secrets (decades of relevance)
- Medical records (lifetime of patient)
- Financial data (years of regulatory retention)
- Intellectual property (duration of competitive advantage)
If your encrypted data needs to stay secret for 10+ years, you should already be planning migration.
Migration Timeline Recommendations
Immediate (Now - 2025)
Assessment phase:
- Inventory all cryptographic usage in your systems
- Identify data with long-term confidentiality requirements
- Catalog certificates, key management systems, and protocols
- Evaluate vendor roadmaps for post-quantum support
Early adoption:
- Begin testing ML-KEM in non-production environments
- Update cryptographic libraries to versions with PQ support
- Train development teams on post-quantum concepts
Short-term (2025 - 2027)
Hybrid deployment:
- Deploy hybrid key exchange (classical + ML-KEM)
- Update TLS configurations to support hybrid cipher suites
- Begin certificate authority preparation for PQ certificates
Standards compliance:
- Follow NIST guidelines for transition (SP 800-131A updates)
- Monitor industry-specific guidance (HIPAA, PCI-DSS, etc.)
- Engage with compliance auditors on migration plans
Medium-term (2027 - 2030)
Full transition:
- Migrate to post-quantum-only for new deployments
- Phase out classical algorithms where possible
- Update all certificates to post-quantum
Verification:
- Audit systems for remaining classical cryptography
- Verify interoperability with partners and vendors
- Document compliance for regulatory requirements
Practical Implementation Steps
Step 1: Cryptographic Inventory
Create a comprehensive inventory:
# Example inventory format
systems:
- name: "Customer Portal"
protocols:
- TLS 1.3 (ECDHE key exchange)
certificates:
- issuer: "DigiCert"
expiry: "2025-06-15"
algorithm: "RSA-2048"
data_sensitivity: "HIGH"
pq_migration_priority: 1
- name: "Internal API Gateway"
protocols:
- mTLS (RSA certificates)
certificates:
- issuer: "Internal CA"
expiry: "2024-12-01"
algorithm: "ECDSA P-256"
data_sensitivity: "MEDIUM"
pq_migration_priority: 2
Step 2: Library Updates
Update to post-quantum-ready libraries:
// HPCrypt provides drop-in post-quantum support
use hpcrypt::kem::{MlKem768, Kem};
use hpcrypt::signature::{MlDsa65, Signer, Verifier};
// Key encapsulation
let (public_key, secret_key) = MlKem768::generate_keypair(&mut rng);
let (ciphertext, shared_secret) = public_key.encapsulate(&mut rng);
let decrypted_secret = secret_key.decapsulate(&ciphertext)?;
// Digital signatures
let signing_key = MlDsa65::generate_signing_key(&mut rng);
let signature = signing_key.sign(message);
signing_key.verifying_key().verify(message, &signature)?;
Step 3: Protocol Configuration
Enable hybrid mode in TLS:
# Nginx with hybrid post-quantum support
ssl_protocols TLSv1.3;
ssl_conf_command Groups X25519MLKEM768:X25519:P-256;
ssl_prefer_server_ciphers off;
Common Questions
"Is my RSA/ECDSA data already compromised?"
Not yet. Current quantum computers cannot break these algorithms. However, encrypted data captured today could be decrypted in the future. The risk depends on how long your data needs to remain confidential.
"Should I wait for more mature implementations?"
For production systems handling sensitive data, hybrid mode provides immediate protection without fully committing to post-quantum-only. This is the recommended approach for most organizations starting their migration.
"What about performance impact?"
Post-quantum algorithms are generally slower than classical equivalents, but the difference is often acceptable:
| Operation | Classical | Post-Quantum | Overhead |
|---|---|---|---|
| Key exchange | ~0.1ms | ~0.2ms | 2x |
| Signature verify | ~0.05ms | ~0.1ms | 2x |
| TLS handshake | ~2ms | ~3ms | 1.5x |
For most applications, this overhead is negligible compared to network latency.
"What if the post-quantum algorithms are broken?"
This is why hybrid mode is recommended during the transition. By combining classical and post-quantum algorithms, you maintain security even if one is compromised. Additionally, SLH-DSA (hash-based signatures) provides a conservative alternative based on different mathematical assumptions.
Resources
- NIST Post-Quantum Cryptography
- FIPS 203 (ML-KEM)
- FIPS 204 (ML-DSA)
- FIPS 205 (SLH-DSA)
- HPCrypt Documentation
Conclusion
The post-quantum era has officially begun. While the full transition will take years, organizations should start planning now. The combination of standardized algorithms, maturing implementations, and clear migration paths makes this an excellent time to begin your post-quantum journey.
At Seceq, we're committed to making this transition as smooth as possible. HPCrypt provides production-ready implementations of all three NIST standards, with the performance and safety guarantees modern applications require.