Post-Quantum Cryptography Migration: A Practical Guide

Why Post-Quantum Cryptography Matters Now

The cryptographic algorithms that protect virtually all internet traffic today — RSA, ECDSA, ECDH, and Diffie-Hellman — are built on mathematical problems that quantum computers can solve efficiently. When a Cryptographically Relevant Quantum Computer (CRQC) becomes available, these algorithms will provide zero security.

This isn’t a distant theoretical risk. It’s an active, exploitable threat today through a strategy called Harvest Now, Decrypt Later (HNDL).

The Quantum Timeline

The gap between “when adversaries collect data” (now) and “when they can decrypt it” (2030–2035) means that any data with a sensitivity lifetime beyond 2035 is already at risk.

NIST Post-Quantum Standards: FIPS 203, 204, 205

NIST finalized three post-quantum cryptographic standards in August 2024 after an 8-year competition. These are the algorithms you must migrate to:

FIPS 203: ML-KEM (CRYSTALS-Kyber)

Use case: Key encapsulation (replaces RSA key exchange, ECDH, DH)

ML-KEM (Module Lattice-based Key Encapsulation Mechanism) provides quantum-resistant key exchange. It’s based on the hardness of the Module Learning With Errors (MLWE) problem.

FIPS 204: ML-DSA (CRYSTALS-Dilithium)

Use case: Digital signatures (replaces RSA signatures, ECDSA)

ML-DSA (Module Lattice-based Digital Signature Algorithm) provides quantum-resistant digital signatures. It’s the primary replacement for RSA and ECDSA in most applications.

FIPS 205: SLH-DSA (SPHINCS+)

Use case: Hash-based digital signatures (alternative to ML-DSA)

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) provides a conservative alternative based solely on hash functions. It’s recommended as a backup to ML-DSA because its security assumptions are simpler and better-understood.

Building a Crypto-Agile Architecture

Crypto-agility is the ability to swap cryptographic algorithms without redesigning your entire system. This is essential because:

• New algorithms may be found vulnerable (it’s happened before — SIKE was broken in 2022)
• Standards will continue to evolve
• Different deployments may need different algorithms

Principles of Crypto-Agility

1. Abstract Cryptographic Operations

Never hard-code algorithm choices. Use abstraction layers:

# ❌ Bad: Hard-coded algorithm
from cryptography.hazmat.primitives.asymmetric import rsa
key = rsa.generate_private_key(65537, 2048)

# ✅ Good: Configurable algorithm
def generate_signing_key(algorithm: str = "ML-DSA-87"):
    return crypto_provider.create_key(algorithm)

2. Externalize Algorithm Configuration

Move algorithm selection to configuration files:

# crypto-config.yaml
signing:
  algorithm: ML-DSA-87
  fallback: SLH-DSA-SHA2-256s
key_exchange:
  algorithm: ML-KEM-1024
  hybrid: true  # Use classical + PQC during transition
symmetric:
  algorithm: AES-256-GCM
hashing:
  algorithm: SHA-384

3. Support Hybrid Mode

During the transition, use both classical and PQC algorithms simultaneously:

# Hybrid TLS: classical + PQC key exchange
# This ensures security against both classical and quantum attacks
# Even if the PQC algorithm is later found vulnerable, classical crypto still protects

4. Version Your Cryptographic Protocols

Include algorithm identifiers in your data formats so you know which algorithm was used for each piece of data:

{
  "encrypted_payload": "...",
  "crypto_metadata": {
    "kem": "ML-KEM-1024",
    "symmetric": "AES-256-GCM",
    "version": "2"
  }
}

Step-by-Step PQC Migration Guide

Step 1: Discover Your Cryptographic Surface Area

You can’t migrate what you can’t see. Start with a comprehensive scan:

# Install KeyLens
brew install keylens/tap/cbom

# Scan everything
cbom scan . --format cbom --output baseline-cbom.json

# View quantum-vulnerable algorithms specifically
cbom scan . --filter 'algo.quantum_safe==false' --format table

Expected output for a typical codebase:

┌──────────────────────────────────────────────────────────┐
│ Algorithm      │ Quantum Safe │ Count │ Locations         │
├──────────────────────────────────────────────────────────┤
│ RSA-2048       │ ❌ No        │ 12    │ auth/, tls/      │
│ ECDSA-P256     │ ❌ No        │ 8     │ signing/, api/   │
│ ECDH-P384      │ ❌ No        │ 3     │ handshake/       │
│ AES-256-GCM    │ ✅ Yes       │ 45    │ (throughout)     │
│ SHA-256        │ ✅ Yes*      │ 67    │ (throughout)     │
│ SHA-384        │ ✅ Yes       │ 12    │ cert/            │
└──────────────────────────────────────────────────────────┘
* SHA-256 is quantum-safe but below CNSA 2.0 minimum for NSS

Step 2: Categorize and Prioritize

Rank your cryptographic assets by migration urgency:

Tier 1 — Migrate immediately:

• Public-key operations protecting long-lived secrets
• Key exchange in network protocols (TLS, SSH, VPN)
• Digital signatures on software releases

Tier 2 — Migrate within 12 months:

• Authentication token signing (JWT, SAML)
• API request signing
• Database encryption key wrapping

Tier 3 — Monitor and plan:

• Symmetric algorithms (AES-256 is already quantum-safe)
• Hash functions (SHA-256+ are quantum-safe for most uses)
• Short-lived ephemeral keys

Step 3: Select Your Target Algorithms

Based on NIST and CNSA 2.0 guidance:

Step 4: Implement and Test

For each system, follow this migration pattern:

1. Add PQC library support — integrate liboqs, OpenSSL 3.2+, or AWS-LC
2. Implement hybrid mode — run classical + PQC in parallel
3. Validate with KeyLens — confirm PQC algorithms are detected

# After migration, verify compliance
cbom scan . --check cnsa-2.0

# Expected output after successful migration:
# ✅ ML-KEM-1024 detected (src/crypto/kem.rs:23) — CNSA 2.0 compliant
# ✅ ML-DSA-87 detected (src/auth/signing.rs:45) — CNSA 2.0 compliant
# ✅ AES-256-GCM detected (src/crypto/encrypt.rs:12) — Compliant
# ✅ SHA-384 detected (src/hash/digest.rs:8) — Compliant

4. Remove classical algorithms — once PQC is validated, remove deprecated crypto
5. Update CBOM — regenerate and archive for compliance records

Step 5: Prevent Regression

Set up CI/CD to block reintroduction of quantum-vulnerable algorithms:

# .github/workflows/pqc-gate.yml
name: PQC Compliance Gate
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: keylens/cbom-action@v1
        with:
          policy: cnsa-2.0
          fail-on-violation: true
          comment-on-pr: true

Write a custom Rego policy for granular control:

# block-quantum-vulnerable.rego
package cbom.policy

deny[msg] {
    input.components[i].cryptoProperties.assetType == "algorithm"
    algo := input.components[i].name
    quantum_vulnerable := {"RSA", "ECDSA", "ECDH", "DH", "DSA"}
    quantum_vulnerable[algo]
    loc := input.components[i].evidence.location
    msg := sprintf("Quantum-vulnerable algorithm %v at %v — migrate to PQC", [algo, loc])
}

Harvest Now, Decrypt Later: Understanding the Threat

The Harvest Now, Decrypt Later (HNDL) attack model is the primary driver behind urgent PQC adoption:

How HNDL Works

1. Intercept — adversary captures encrypted network traffic today
2. Store — encrypted data is archived in bulk storage (cheap and scalable)
3. Wait — adversary waits for a sufficiently powerful quantum computer
4. Decrypt — quantum computer breaks the encryption, revealing all stored data

What Data Is at Risk

Any data encrypted with RSA, ECDH, or DH key exchange that has value beyond 2035:

• Diplomatic communications — foreign policy implications lasting decades
• Trade secrets — pharmaceutical formulas, manufacturing processes
• Financial records — merger plans, strategic investments
• Healthcare data — patient records, genomic data
• Intelligence — sources, methods, classified operations
• Legal communications — attorney-client privilege

Why Classical “Key Size Increases” Don’t Help

Doubling an RSA key from 2048 to 4096 bits only marginally increases quantum attack cost. Shor’s algorithm breaks RSA regardless of key size — it just takes slightly more qubits. The only defense is fundamentally different mathematics: lattice-based (ML-KEM, ML-DSA) or hash-based (SLH-DSA) algorithms.

Performance Considerations

PQC algorithms have different performance characteristics than classical algorithms. Plan for these differences:

Key and Signature Sizes

Impact on Your Systems

• TLS handshakes — slightly larger key exchange, negligible latency impact
• Certificate chains — larger certificates may impact mobile networks
• JWT tokens — PQC signatures are larger; consider token compression
• Code signing — SLH-DSA signatures are large but signing is infrequent
• API calls — minimal impact for most use cases

Most applications will see less than 5% performance overhead from PQC migration. The critical exception is bandwidth-constrained environments (IoT, satellite) where larger key sizes matter.

Frequently Asked Questions

When should I start my PQC migration?

Now. Even if your regulatory deadline is 2030, PQC migration involves library upgrades, protocol changes, testing, and deployment across potentially hundreds of systems. Starting today gives you time to do it properly rather than as an emergency.

Is PQC ready for production use?

Yes. NIST finalized FIPS 203, 204, and 205 in August 2024. Major libraries (OpenSSL 3.2+, AWS-LC, BoringSSL, liboqs) support these algorithms. Google Chrome and Cloudflare have been using ML-KEM in production TLS since 2024.

What if a PQC algorithm is broken later?

This is why crypto-agility matters. Design your systems so algorithms can be swapped without redesigning your architecture. Use hybrid mode during the transition period to maintain security even if one algorithm is compromised.

How do I know if my migration is complete?

Run KeyLens with the CNSA 2.0 compliance check after migration. A clean scan (zero violations) confirms your codebase is fully PQC-compliant. Set up continuous scanning to prevent regression.

What about symmetric cryptography?

AES-256 and SHA-384/512 are considered quantum-safe. Grover’s algorithm provides only a quadratic speedup against symmetric algorithms, so AES-256 provides approximately 128 bits of post-quantum security — more than sufficient.

Next Steps

• Generate your CBOM now → — Discover your cryptographic surface area in under 2 minutes
• CNSA 2.0 Compliance Checklist → — Detailed algorithm requirements for national security systems
• EO 14412 Guide → — Federal contractor compliance requirements
• What is a CBOM? → — Complete guide to Cryptographic Bills of Materials