In Part 1 of our quantum cryptography series, we established the urgency: adversaries are harvesting your encrypted data right now, waiting for quantum computers that will decrypt it in hours. Most organizations have already run out of time to wait.

Now comes the critical question: “What do we actually migrate To?”

The Algorithm That Almost Wasn’t

August 13, 2024, redefined cryptographic security for the next 50 years. NIST finalized three post-quantum standards after eight years of rigorous analysis involving the global cryptography community.

Here’s what most coverage missed: the selection process nearly eliminated the winning algorithms multiple times. CRYSTALS-Kyber, now ML-KEM, faced serious scrutiny in 2019 over side-channel vulnerabilities. CRYSTALS-Dilithium, now ML-DSA, underwent significant modifications after Round 2. SPHINCS+, now SLH-DSA, was almost rejected as “too slow” until researchers proved hash-based signatures provided crucial algorithmic diversity.

The algorithms that emerged weren’t perfect. They were battle-tested.

💡 Key Insight

Through my architectural work evaluating cryptographic implementations for enterprise systems, I’ve watched these standards evolve from academic curiosities to production necessities. What was “experimental” in 2020 became “mandatory” in 2025 for government systems.

If you’re waiting for “better” algorithms, you’re misunderstanding the process. These algorithms won BECAUSE they survived eight years of the most intensive cryptanalysis in history. This is as good as cryptographic confidence gets.

The Eight-Year Journey to Quantum-Resistant Standards

Understanding NIST’s selection process helps explain why these algorithms deserve your confidence.

In 2016, NIST issued a call for post-quantum algorithms, modeled after the successful AES competition. The requirements were clear: demonstrate security against quantum computers, provide detailed specifications for independent implementation, and achieve acceptable performance. Sixty-nine submissions arrived from cryptographers worldwide, spanning lattice-based, code-based, multivariate, hash-based, and isogeny-based cryptography.

By 2020, after three years of intense cryptanalysis, seven finalists remained. CRYSTALS-Kyber, CRYSTALS-Dilithium, FALCON, and SPHINCS+ advanced for standardization. The community had systematically eliminated algorithms with security concerns or performance issues.

In July 2022, NIST announced initial selections. Kyber for key encapsulation, Dilithium for signatures, SPHINCS+ as hash-based backup, and FALCON for compact signatures. Each algorithm filled a specific role based on security, performance, and use case requirements.

On August 13, 2024, NIST published three finalized standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). The name changes reflected standardization—these were now official U.S. government standards.

On March 11, 2025, NIST selected HQC (Hamming Quasi-Cyclic) as the fifth algorithm, providing a code-based backup for ML-KEM. Where ML-KEM uses lattices, HQC uses error-correcting codes, offering crucial diversity if lattice vulnerabilities emerge. Draft standard expected 2026, finalization 2027.

Figure 1: NIST Post-Quantum Cryptography Timeline – The 8-year journey from 69 global submissions to finalized standards. No cryptographic standard has ever received this level of validation before deployment.

Eight years from competition to finalized standards represents unprecedented scrutiny. AES took four years. RSA was never formally standardized through public competition. No cryptographic standard has ever received this level of validation before deployment.

The Core Algorithms: What Actually Protects Your Data

ML-KEM (FIPS 203): Your Primary Key Exchange

When your browser connects to your bank, the first step is key agreement—establishing a shared secret without transmitting it. ML-KEM replaces RSA and ECDH for this critical function in every HTTPS connection, VPN tunnel, SSH session, and API call.

Similar to how we architect robust authentication systems with multiple layers of protection, ML-KEM provides quantum-resistant key establishment as the foundation for secure communications.

Technical Foundation

ML-KEM builds on Module Learning with Errors (MLWE), a lattice-based problem. The algorithm operates in three steps: the receiver generates a public-private keypair, the sender encapsulates a shared secret using the public key producing a ciphertext, and the receiver decapsulates using their private key, recovering the same shared secret. Both parties share a secret without ever transmitting it.

The mathematics resist both classical and quantum attacks. Shor’s algorithm, which breaks RSA and ECDSA, doesn’t apply to lattice problems. The best known quantum attacks against lattices provide only modest speedups, far less than the exponential advantage Shor’s algorithm provides against factoring.

Three Security Levels

ML-KEM comes in three variants corresponding to different security levels:

• ML-KEM-512: AES-128 equivalent security, suitable for baseline quantum resistance
• ML-KEM-768: AES-192 equivalent security—NIST’s recommended level for commercial applications
• ML-KEM-1024: AES-256 equivalent security, required by NSA CNSA 2.0 for National Security Systems

The security level affects key sizes. ML-KEM-512 uses 800-byte public keys and 768-byte ciphertexts. ML-KEM-768 requires 1,184-byte public keys and 1,088-byte ciphertexts. ML-KEM-1024 needs 1,568-byte public keys and 1,568-byte ciphertexts.

💡 Key Insight

Compare this to classical cryptography: X25519, the most common elliptic curve key exchange, uses 32-byte keys. ML-KEM-768 public keys are 37 times larger, driving much of the implementation complexity in post-quantum migration.

Performance Characteristics

The good news: ML-KEM is fast. On modern processors:

• Key generation: 10-20 microseconds
• Encapsulation: 15-30 microseconds
• Decapsulation: 20-40 microseconds
• Total TLS handshake overhead: 80-150 microseconds

For typical 50-100 millisecond internet handshakes dominated by network latency, adding 150 microseconds represents a 0.15% to 0.3% increase. With TLS connection reuse, where a single handshake protects thousands of requests, the amortized overhead becomes negligible.

💰 Cost Analysis

AWS benchmarks from April 2025 showed ML-KEM deployment to AWS KMS resulted in 0.05% throughput reduction with proper connection pooling. Google Cloud reported similar results.

Why ML-KEM-768 Won

NIST selected ML-KEM-768 as the recommended level because:

• Security margin comfortably exceeds AES-128 while remaining more efficient than ML-KEM-1024
• Key and ciphertext sizes, while large, remain manageable for modern networks
• Performance operates efficiently from servers to mobile devices
• Five-plus years of public cryptanalysis found no fundamental weaknesses

Use cases: TLS 1.3 key exchange for HTTPS and APIs, VPN tunnel establishment (IPsec, OpenVPN), SSH connections, secure messaging protocols, and any scenario requiring quantum-resistant key establishment.

ML-DSA (FIPS 204): Your Primary Digital Signature

Key exchange solves half the problem. Authentication is the other half. Digital signatures prove authenticity and prevent tampering. ML-DSA replaces RSA and ECDSA for signing software, certificates, documents, and APIs.

Technical Foundation

ML-DSA builds on Module Short Integer Solution (MSIS), another lattice problem providing algorithmic diversity from ML-KEM. To sign, you hash a message and combine it with your private key through ML-DSA, producing a signature. Anyone can verify using your public key, confirming you signed this exact message and it hasn’t been altered.

The mathematics resist quantum attacks through the same lattice hardness assumptions that protect ML-KEM. Quantum algorithms provide only limited advantage against lattice problems, preserving security in the quantum era.

Three Security Levels

ML-DSA offers three security levels matching ML-KEM:

• ML-DSA-44: AES-128 equivalent (1,312-byte public keys, 2,420-byte signatures)
• ML-DSA-65: AES-192 equivalent, NIST’s recommendation (1,952-byte public keys, 3,309-byte signatures)
• ML-DSA-87: AES-256 equivalent, CNSA 2.0 requirement (2,592-byte public keys, 4,595-byte signatures)

Signature size matters for some use cases. ECDSA P-256 uses 64-byte signatures. ML-DSA-65 requires 3,309 bytes—50 times larger. For code signing large firmware, this doesn’t matter. For constrained IoT protocols, it might.

Performance Profile

ML-DSA performs excellently in practice:

• Key generation: 50-100 microseconds
• Signing: 100-200 microseconds
• Verification: 50-100 microseconds

💡 Key Insight

Compared to RSA-2048’s several-millisecond signature generation, ML-DSA is actually 10x faster. ML-DSA isn’t just quantum-resistant—it’s often a performance upgrade from classical signatures.

Use cases: Software distribution (code signing for applications, firmware, containers), document signing (PDFs, contracts), API authentication (JWT, OAuth, webhooks), future TLS certificates, and email signatures.

SLH-DSA (FIPS 205): Your Conservative Backup

Every security architecture needs a backup plan. What if a flaw emerges in lattice cryptography? SLH-DSA provides insurance through completely different mathematics: hash functions.

The Hash-Based Approach

SLH-DSA builds security entirely on cryptographic hash functions like SHA-256. Hash functions have decades of history with no quantum algorithms providing more than modest speedup via Grover’s algorithm. If you trust SHA-256 today, trust SLH-DSA in the quantum era.

The stateless property distinguishes SLH-DSA from older hash-based signatures like LMS and XMSS, which require careful state tracking. SLH-DSA eliminates this risk through stateless operation.

Security Levels and Trade-offs

SLH-DSA comes in variants balancing speed and size:

• SLH-DSA-128f: Fast signing, 16 KB signatures
• SLH-DSA-128s: Smaller 8 KB signatures, slower performance
• SLH-DSA-256f: Maximum security, 49 KB signatures

⚠️ Production Reality

The trade-off is significant. A 49 KB signature creates real protocol challenges. Signing takes 5-50 milliseconds—100x slower than ML-DSA. Verification takes 1-5 milliseconds.

When to Use SLH-DSA

The size and performance penalties mean SLH-DSA isn’t for everyday use. It shines in specific scenarios:

• Long-term archival signatures needing decades of validity
• Extremely high-security requirements justifying overhead
• Backup systems protecting against lattice breakthroughs
• Any stateless signature requirement

Most organizations will use ML-DSA for 95% of signatures and SLH-DSA for the 5% where absolute confidence matters most.

FN-DSA (FIPS 206 Draft): Compact Signatures for Constrained Devices

ML-DSA produces 2-4 KB signatures—fine for servers, problematic for IoT devices on low-power networks. FN-DSA addresses this through compact signatures.

The NTRU Foundation

FN-DSA builds on NTRU lattices, different from ML-DSA’s module lattices, providing algorithmic diversity. The key innovation: much smaller signatures.

• FN-DSA-512: 666-byte signatures (one-fifth the size of ML-DSA-44)
• FN-DSA-1024: 1,280-byte signatures (one-third the size of ML-DSA-87)

The Implementation Challenge

⚠️ Production Reality

FN-DSA’s smaller signatures come with a cost: implementation complexity. The algorithm requires floating-point arithmetic—unusual for cryptography and error-prone. Constant-time implementations resisting side-channel attacks prove difficult. Small errors create serious vulnerabilities.

Use cases: Embedded systems and IoT devices benefiting from smaller signatures, smart cards with limited memory, and battery-powered devices transmitting wirelessly. The draft standard status matters—FIPS 206 isn’t finalized yet, expected 2025-2026.

For most applications, ML-DSA is better. For genuine size-constrained scenarios, FN-DSA will provide an important alternative once standardized.

HQC: Algorithmic Diversity Insurance

NIST’s March 2025 HQC selection reinforces a critical principle: never bet everything on one mathematical problem.

HQC abandons lattices entirely, building on error-correcting codes. Security derives from decoding random linear codes, extensively studied since the 1970s. Code-based cryptography has longer research history than lattices, providing additional confidence.

💡 Key Insight

The strategic concern: ML-KEM, ML-DSA, and FN-DSA all use lattices. If a fundamental lattice breakthrough occurs, three standards fail simultaneously. HQC provides completely different mathematics as backup.

HQC performance roughly matches ML-KEM-768. Key sizes run 10-20% larger—the price of algorithmic diversity.

Strategy: Deploy ML-KEM now. Monitor HQC standardization. Plan hybrid deployments combining ML-KEM and HQC once HQC finalizes in 2027. Two different mathematical foundations provide defense in depth.

Figure 2: Post-Quantum Algorithm Comparison Matrix – Key sizes are 37x larger than classical algorithms, but performance remains fast on modern x86 processors. RSA and ECDSA are quantum-vulnerable, while ML-KEM and ML-DSA provide AES-192 equivalent quantum resistance.

Choosing the Right Algorithm for Your Use Case

Five algorithms, multiple security levels, different trade-offs. How do you decide?

The Decision Framework

Start with your use case: key exchange or digital signatures?

For key exchange:

• ML-KEM-768 handles 95% of scenarios with strong security, acceptable performance, and manageable key sizes
• Use ML-KEM-1024 only for CNSA 2.0 mandates requiring maximum security
• Plan for future HQC to add algorithmic diversity

For digital signatures:

• ML-DSA-65 covers most use cases—code, documents, APIs, certificates
• Use ML-DSA-87 for firmware with long-term validity or CNSA 2.0 compliance
• Choose FN-DSA-512 only for genuinely constrained devices where signature size matters, and only after FIPS 206 finalizes
• Reserve SLH-DSA-256 for archival signatures needing decades of validity Figure 3: Post-Quantum Algorithm Selection Flowchart – A visual decision tree to map your requirements to the right algorithm in 60 seconds. ML-KEM-768 and ML-DSA-65 are NIST-recommended for 95% of use cases. Always use HYBRID mode during transition (Classical + PQC for safety).

Performance-Driven Selection

If performance is primary:

• ML-DSA provides fastest signatures, outperforming RSA
• ML-KEM delivers fast key exchange with minimal overhead
• FN-DSA trades some performance for smaller signatures
• SLH-DSA sacrifices significant performance for hash-based security

For latency-sensitive applications like high-frequency trading or real-time communications, ML-DSA and ML-KEM are your only practical choices.

Size-Constrained Environments

If bandwidth or storage drives constraints:

• Key exchange: All ML-KEM variants require ~1-1.5 KB per handshake with no smaller option until HQC finalizes
• Signatures: FN-DSA provides the most compact at 666-1,280 bytes but increases implementation complexity
• ML-DSA: Requires 2-4 KB, acceptable for most networks but problematic for extremely constrained devices
• SLH-DSA: 8-49 KB signatures work only when size doesn’t matter

The Hybrid Strategy: Why It’s Essential

During transition, hybrid cryptography combining classical and post-quantum algorithms provides maximum security. According to IETF’s hybrid key exchange specifications, a hybrid approach combines X25519 and ML-KEM-768. An attacker must break both algorithms to compromise the connection.

Major implementations support hybrid modes:

• TLS 1.3 hybrid drafts define how to combine ECDH with ML-KEM
• SSH supports hybrid key exchange methods
• IPsec has hybrid extensions for quantum-resistant VPNs

💡 Key Insight

The strategy: Use hybrid everywhere during transition. Classical algorithms provide backward compatibility and battle-tested security. Post-quantum algorithms provide quantum resistance. Together, they defend against both classical and quantum attacks.

Once the ecosystem fully transitions and confidence solidifies, pure post-quantum modes become acceptable. But that’s years away. For now, hybrid is responsible.

Common Selection Scenarios

Scenario 1: Public-Facing Web Application

Situation: You’re running an e-commerce site with HTTPS. Customers connect via browsers.

Solution:

• Deploy ML-KEM-768 for TLS key exchange in hybrid mode with X25519 at your load balancer or CDN
• Continue using RSA-2048 or ECDSA P-256 certificates until browsers support post-quantum certificate validation
• Monitor for ML-DSA-65 certificate support in major browsers

This hybrid approach provides quantum resistance for data in transit while maintaining compatibility with all existing browsers.

Scenario 2: Internal API Authentication

Situation: Your microservices use JWT tokens signed with RSA-2048. Thousands of tokens signed per second. You control both clients and servers.

Solution:

• Migrate to ML-DSA-65 for JWT signing—performance will actually improve over RSA-2048
• Update all services to validate ML-DSA signatures
• Deploy incrementally starting with non-critical services
• Rotate signing keys frequently to limit exposure

This internal migration can proceed quickly since you control the entire ecosystem without external dependencies.

Scenario 3: Long-Term Document Archive

Situation: You’re digitally signing legal documents requiring 30+ year validity. Document size isn’t a concern.

Solution:

• Use SLH-DSA-256 for maximum security and long-term confidence
• The 49 KB signature doesn’t matter for document archival where files are already kilobytes or megabytes
• Hash-based security provides maximum confidence over decades
• Stateless property eliminates key management complexity

This represents exactly the use case where SLH-DSA’s trade-offs make sense.

The Pitfall: “We Don’t Need Hybrid”

The most dangerous misconception is skipping hybrid cryptography.

Some argue hybrid deployments are unnecessary complexity. ML-KEM is quantum-resistant—why combine it with X25519? Just use ML-KEM alone.

This sounds logical. It’s risky.

Why Hybrid Matters

Post-quantum algorithms are relatively new. ML-KEM was finalized August 2024. While it underwent eight years of analysis, that’s still short compared to RSA’s 40+ years in production. Unexpected implementation vulnerabilities might emerge. Side-channel attacks might be discovered. Mathematical breakthroughs might reduce security margins.

Hybrid deployments provide insurance:

• If ML-KEM fails, X25519 still protects the connection
• If X25519 fails to quantum computers, ML-KEM provides protection
• An attacker must break both simultaneously

💰 Cost Analysis

The computational overhead is minimal—microseconds. Bandwidth overhead is modest—about 1.2 KB more data. For production systems, these costs are negligible compared to security benefits.

Industry Consensus

Major organizations uniformly recommend hybrid modes during transition:

• NIST guidance encourages hybrid deployments
• NSA CNSA 2.0 allows hybrid during transition period
• IETF is standardizing hybrid TLS specifications
• Cloud providers (AWS, Google, Azure) implement hybrid by default

When Can You Go Pure Post-Quantum?

Not yet. We need:

• Several more years of deployment finding implementation issues
• Continued cryptanalysis finding no major weaknesses
• Full ecosystem support in clients, servers, libraries, and hardware
• Organizational confidence that pure post-quantum is “battle-tested”

⚠️ Production Reality

Realistically, pure post-quantum becomes acceptable around 2028-2030. Until then, hybrid is responsible. As we discussed when analyzing Mosca’s Theorem in Part 1, the timeline pressure means we can’t afford to wait for perfection.

Frequently Asked Questions

What’s the difference between ML-KEM-768 and ML-KEM-1024?

ML-KEM-768 provides AES-192 equivalent security and is NIST’s recommendation for commercial applications. ML-KEM-1024 provides AES-256 equivalent security and is required by NSA CNSA 2.0 for National Security Systems. Unless you’re under government mandate, ML-KEM-768 offers the best balance of security and performance.

Can I use only ML-DSA without ML-KEM?

No, they solve different problems. ML-KEM handles key exchange (establishing shared secrets), while ML-DSA handles digital signatures (authentication and integrity). Most systems need both—ML-KEM for TLS connections and ML-DSA for code/document signing.

How long will hybrid mode be necessary?

Expect hybrid deployments through 2028-2030. This gives post-quantum algorithms time to prove themselves in production while maintaining backward compatibility. The exact timeline depends on ecosystem adoption rates and continued confidence in algorithm security.

Bottom Line: Standards Are Ready, Your Move Comes Next

NIST has delivered production-ready, extensively vetted post-quantum standards. ML-KEM-768 and ML-DSA-65 handle 95% of use cases effectively. SLH-DSA and FN-DSA provide specialized alternatives. HQC adds algorithmic diversity.

The algorithms survived eight years of global cryptanalysis—more scrutiny than any prior standard. Performance is acceptable with ML-KEM adding sub-millisecond overhead and ML-DSA often faster than RSA. Key and signature sizes increased but remain manageable.

Your decision framework is straightforward: Match algorithms to use cases based on security, performance, and size requirements. Deploy hybrid modes during transition. Plan for algorithmic diversity.

The standards are ready. The implementations exist. The mandates are active. The remaining question is execution.

What’s Next: From Standards to Production

Understanding which algorithms to use solves the theoretical problem. Actually deploying them reveals practical challenges.

In Part 3, we’ll move from theory to implementation with hands-on AWS deployment guidance. You’ll see exactly how to enable ML-KEM in AWS KMS with working code examples. We’ll benchmark real performance impact. We’ll explore operational considerations for monitoring, troubleshooting, and incident response.

The standards are clear. Now let’s make them real.

Ready to start your migration? Before diving into Part 3’s implementation, review these essential resources to build your foundation:

Essential Documentation to Review

NIST Official Standards (Read these first):

• FIPS 203: ML-KEM Specification – Complete technical specification for key encapsulation
• FIPS 204: ML-DSA Specification – Digital signature algorithm details
• NIST IR 8547: Migration Guide – Practical migration strategies and timelines

Implementation Guidance:

• NSA CNSA 2.0 FAQ – Answers to compliance questions (v2.1, Dec 2024)
• AWS Post-Quantum Cryptography Strategy – Cloud implementation approach

---

Download Resources

Free Algorithm Selection Flowchart: Get our visual decision tree that maps your requirements to the right post-quantum algorithm in 60 seconds.

PQC Migration Checklist: A comprehensive checklist covering discovery, planning, pilot, and production rollout phases.