Performing Post Quantum Cryptography Migration

Performing Post-Quantum Cryptography Migration

When to Use

• When assessing organizational readiness for the NIST post-quantum cryptography transition
• When building a cryptographic inventory to identify quantum-vulnerable algorithms across infrastructure
• When evaluating hybrid TLS 1.3 configurations using X25519MLKEM768 key exchange
• When testing CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) algorithm support
• When implementing crypto-agility to support both classical and post-quantum algorithms
• When preparing migration roadmaps aligned with NIST IR 8547 deprecation timelines
• When configuring oqs-provider with OpenSSL 3.x for post-quantum algorithm support

Common Misconfigurations & Verification

• PQC-only instead of hybrid: deploying ML-KEM alone (not X25519MLKEM768) during the transition removes the classical safety net if the lattice scheme is later broken. Always negotiate a hybrid group; verify with openssl s_client -groups X25519MLKEM768 -connect host:443 that the negotiated group is the hybrid, not a fallback to x25519.
• Silent downgrade to classical: a server that advertises hybrid but selects ECDH for most clients still leaves traffic quantum-vulnerable. Confirm the ServerHello selected_group is the hybrid and that classical-only fallback is intentional, not accidental.
• Inventory blind spots: scans that cover TLS but miss code-signing keys, SSH, S/MIME, VPN/IPsec, embedded firmware, and HSM/KMS-held keys. "Harvest now, decrypt later" makes long-lived data the top migration priority — confirm those channels are in the inventory.
• Wrong security level / non-FIPS params: using ML-KEM-512 where Level 3 (ML-KEM-768) is required, or a pre-standard "Kyber" build instead of FIPS-203 ML-KEM. Pin standardized parameter sets.
• Capacity not planned: larger ML-KEM/ML-DSA keys and signatures can exceed MTU/record/cert-store limits; benchmark handshake cost under load.
• Verification: assert all quantum-vulnerable algos (RSA, ECDH, ECDSA, DH, DSA) are enumerated; ML-KEM encapsulate→decapsulate yields matching 32-byte secrets; an ML-DSA signature over a tampered message is REJECTED; CA/HSM/KMS PQC support is confirmed before declaring readiness.

Prerequisites

• Python 3.8+ with cryptography, requests, pyOpenSSL libraries
• OpenSSL 3.0+ (3.5+ recommended for native ML-KEM/ML-DSA support)
• oqs-provider for OpenSSL (for hybrid TLS testing with older OpenSSL)
• Network access to target servers for TLS assessment
• Administrative access for infrastructure scanning
• Familiarity with PKI, TLS, and cryptographic protocols

Core Concepts

NIST Post-Quantum Cryptography Standards

NIST published three finalized PQC standards on August 13, 2024:

ML-KEM (FIPS 203) -- Primary standard for key exchange and encryption. Replaces RSA and ECDH for key establishment. Three security levels: ML-KEM-512, ML-KEM-768, ML-KEM-1024.

ML-DSA (FIPS 204) -- Primary standard for digital signatures. Replaces RSA and ECDSA for signing. Three security levels: ML-DSA-44, ML-DSA-65, ML-DSA-87.

SLH-DSA (FIPS 205) -- Backup signature standard using hash-based approach. Intended as fallback if lattice-based ML-DSA is found vulnerable. Larger signatures but conservative security assumptions.

Quantum-Vulnerable Algorithms

These classical algorithms are vulnerable to quantum attack via Shor's algorithm:

NIST Migration Timeline (IR 8547)

• 2024: Standards published, migration planning should begin
• 2030: Deprecation of quantum-vulnerable algorithms for most federal systems
• 2035: Complete removal of quantum-vulnerable algorithms from NIST standards
• Now: "Harvest now, decrypt later" attacks make early migration essential for long-lived secrets and data requiring long-term confidentiality

Hybrid TLS Key Exchange

During the transition period, hybrid key exchange combines a classical algorithm with a post-quantum algorithm. If either algorithm is secure, the connection remains protected.

Hybrid Key Exchange: X25519MLKEM768
  = X25519 (classical ECDH) + ML-KEM-768 (post-quantum)

Client Hello:
  supported_groups: X25519MLKEM768, X25519, secp256r1
  key_share: X25519MLKEM768

Server Hello:
  selected_group: X25519MLKEM768
  key_share: X25519MLKEM768

Shared Secret = KDF(X25519_shared || MLKEM768_shared)

Instructions

Phase 1: Cryptographic Inventory Scanning

The first step in PQC migration is discovering all cryptographic algorithm usage across the enterprise. This includes TLS configurations, certificates, code libraries, key stores, and protocol configurations.

# Scan TLS endpoints for quantum-vulnerable algorithms
python scripts/agent.py --action scan_tls \
    --targets targets.txt \
    --output tls_inventory.json

The scanner identifies:

• TLS protocol versions in use
• Key exchange algorithms (RSA, ECDH, DH -- all quantum-vulnerable)
• Certificate signature algorithms (RSA, ECDSA)
• Cipher suite configurations
• Certificate key sizes and expiration dates

Phase 2: Crypto-Agility Assessment

Evaluate the organization's ability to swap cryptographic algorithms without major infrastructure changes:

# Assess crypto-agility readiness
python scripts/agent.py --action assess_agility \
    --scan-results tls_inventory.json \
    --output agility_report.json

Key assessment areas:

1. Protocol flexibility: Can TLS configurations be updated without downtime?
2. Library versions: Do deployed crypto libraries support PQC algorithms?
3. Certificate infrastructure: Can CA issue PQC certificates?
4. Key management: Can KMS handle larger PQC key sizes?
5. Hardware constraints: Can HSMs support PQC operations?

Phase 3: Hybrid TLS Readiness Testing

Test whether infrastructure supports hybrid key exchange with X25519MLKEM768:

# Test hybrid TLS support on target servers
python scripts/agent.py --action test_hybrid_tls \
    --target server.example.com:443 \
    --output hybrid_tls_report.json

OpenSSL 3.5+ (native ML-KEM support):

# Test with native PQC support
openssl s_client -connect server.example.com:443 \
    -groups X25519MLKEM768

OpenSSL 3.0-3.4 with oqs-provider:

# Configure oqs-provider
# /etc/ssl/openssl-oqs.cnf
[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[default_sect]
activate = 1

[oqsprovider_sect]
activate = 1
module = /usr/lib/oqs-provider/oqsprovider.so

# Test hybrid TLS
OPENSSL_CONF=/etc/ssl/openssl-oqs.cnf \
openssl s_client -connect server.example.com:443 \
    -groups x25519_mlkem768

Web Server Configuration for Hybrid TLS:

Apache httpd:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1
SSLProtocol -all +TLSv1.2 +TLSv1.3

NGINX:

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

Phase 4: ML-KEM Key Encapsulation Validation

Validate that ML-KEM (CRYSTALS-Kyber) key encapsulation works correctly in your environment:

# Test ML-KEM key encapsulation at all security levels
python scripts/agent.py --action test_mlkem \
    --output mlkem_validation.json

ML-KEM parameter comparison:

Phase 5: ML-DSA Digital Signature Validation

Validate ML-DSA (CRYSTALS-Dilithium) signature operations:

# Test ML-DSA digital signatures
python scripts/agent.py --action test_mldsa \
    --output mldsa_validation.json

ML-DSA parameter comparison:

Phase 6: Migration Roadmap Generation

Generate a prioritized migration roadmap based on inventory and assessment results:

# Generate complete migration roadmap
python scripts/agent.py --action roadmap \
    --scan-results tls_inventory.json \
    --agility-results agility_report.json \
    --output migration_roadmap.json

The roadmap prioritizes systems by:

1. Data sensitivity: Systems handling long-lived secrets migrate first
2. Exposure level: Internet-facing services before internal
3. Crypto-agility: Systems that can easily swap algorithms first
4. Compliance requirements: Federal/regulated systems per NIST IR 8547 timeline
5. Dependency chains: Libraries and frameworks before applications

Examples

Full Assessment Pipeline

# Step 1: Scan all TLS endpoints
python scripts/agent.py --action scan_tls --targets hosts.txt --output scan.json

# Step 2: Assess crypto-agility
python scripts/agent.py --action assess_agility --scan-results scan.json --output agility.json

# Step 3: Test hybrid TLS on critical servers
python scripts/agent.py --action test_hybrid_tls --target critical.example.com:443

# Step 4: Validate ML-KEM support
python scripts/agent.py --action test_mlkem --output mlkem.json

# Step 5: Validate ML-DSA support
python scripts/agent.py --action test_mldsa --output mldsa.json

# Step 6: Generate migration roadmap
python scripts/agent.py --action roadmap --scan-results scan.json --agility-results agility.json --output roadmap.json

Quick Server Assessment

# Single server PQC readiness check
python scripts/agent.py --action scan_tls --target server.example.com:443

Validation Checklist

• Cryptographic inventory covers all TLS endpoints, certificates, and key stores
• All quantum-vulnerable algorithms (RSA, ECDH, ECDSA, DH, DSA) are identified
• Crypto-agility assessment documents library versions and upgrade paths
• Hybrid TLS (X25519MLKEM768) tested on representative server configurations
• ML-KEM key encapsulation validated at target security level (768 recommended)
• ML-DSA signature verification validated for certificate chain use
• SLH-DSA (FIPS 205) evaluated as backup signature algorithm
• Migration roadmap prioritizes by data sensitivity and compliance timeline
• OpenSSL version and oqs-provider compatibility confirmed
• Key size increases accounted for in network and storage capacity planning
• HSM/KMS compatibility with PQC algorithms verified
• Performance impact of PQC algorithms benchmarked under production load
• "Harvest now, decrypt later" risk assessed for sensitive data channels
• Certificate Authority PQC readiness confirmed for certificate issuance

References

• NIST PQC Standards: https://csrc.nist.gov/projects/post-quantum-cryptography
• FIPS 203 (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
• FIPS 204 (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
• FIPS 205 (SLH-DSA): https://csrc.nist.gov/pubs/fips/205/final
• NIST SP 1800-38 Migration Guide: https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms
• NIST IR 8547 Transition Timeline: https://csrc.nist.gov/pubs/ir/8547/ipd
• Open Quantum Safe Project: https://openquantumsafe.org/
• oqs-provider for OpenSSL: https://github.com/open-quantum-safe/oqs-provider
• OQS TLS Integration: https://openquantumsafe.org/applications/tls.html
• CISA PQC Migration Strategy: https://www.cisa.gov/sites/default/files/2024-09/Strategy-for-Migrating-to-Automated-PQC-Discovery-and-Inventory-Tools.pdf
• IETF Hybrid Key Exchange Draft: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
• CycloneDX Crypto BOM: https://cyclonedx.org/use-cases/cryptographic-key/