Post-Quantum Cryptography in Practice: Migrating TLS, Signatures, and Secrets

Quantum computing is not yet breaking RSA or ECC at production scale, but the migration clock is already running. Encrypted data captured today can be stored until a cryptographically relevant quantum computer arrives. This harvest now, decrypt later risk turns post-quantum cryptography from a future concern into an immediate architecture problem. This guide focuses on the engineering work: crypto agility, hybrid key exchange, post-quantum signatures, PKI, key management, and a migration roadmap that fits real systems.

Why Post-Quantum Migration Is Different

Most cryptographic transitions replace one algorithm with a stronger one of the same family. Post-quantum migration changes the mathematical foundations, key sizes, signature sizes, performance profiles, and sometimes the protocol shape. Shor’s algorithm breaks RSA, Diffie-Hellman, and elliptic-curve cryptography. Grover’s algorithm weakens symmetric cryptography, but AES-256 still provides roughly 128-bit security in a quantum model when used correctly. The hard part is not replacing a single cipher; it is replacing the key exchange and signature layers across every protocol, device, certificate, and secret store.

The NIST Standards and What They Mean

NIST has finalized three primary post-quantum standards: FIPS 203 for ML-KEM, a module-lattice key encapsulation mechanism derived from Kyber; FIPS 204 for ML-DSA, a module-lattice digital signature derived from Dilithium; and FIPS 205 for SLH-DSA, a stateless hash-based signature derived from SPHINCS+. Additional algorithms, such as FN-DSA and HQC, are part of a broader portfolio. For engineering teams, the practical takeaway is not to memorize every parameter set, but to design systems that can negotiate, rotate, and retire algorithms without redeploying every dependency.

• ML-KEM: Fast key encapsulation with relatively small keys. A strong default for TLS, VPNs, messaging, and any place that needs a shared secret.
• ML-DSA: General-purpose signatures suitable for certificates, code signing, and authentication. Larger than Ed25519 but practical.
• SLH-DSA: Conservative hash-based signatures. Large and slow, but valuable for firmware roots, long-lived trust anchors, and backup signing keys.
• FN-DSA: Compact signatures with a different performance and implementation profile. Useful where signature size matters, but requires careful validation.
• HQC: A code-based KEM selected as an additional hedge against future cryptanalysis of lattice assumptions.

Threat Model and Timelines

Not all data and systems need the same urgency. Build a threat model around confidentiality lifetime, signature lifetime, and system lifetime.

• Long-lived confidential data: Health records, legal documents, source code, diplomatic cables, financial records, and backup archives may need secrecy for 10 to 50 years. These are prime candidates for harvest-now-decrypt-later attacks.
• Long-lived signatures: Firmware, code-signing certificates, root CAs, legal signatures, and blockchain transactions may need to remain verifiable for years. A quantum adversary could forge signatures after the fact.
• Short-lived sessions: A TLS session protecting a cat video has a different risk profile from a session protecting a root certificate key. Prioritize by impact and lifetime.
• Embedded and IoT: Devices may stay in the field for 10 to 20 years with no update path. These require early planning or replacement strategies.

Regulatory timelines reinforce urgency. NIST IR 8547 outlines a transition where RSA and ECC are deprecated after 2030 and disallowed after 2035 for many uses. CNSA 2.0 sets aggressive timelines for national security systems. Even if your organization is not directly regulated, your supply chain and customers will pass these requirements downstream.

Crypto Agility Is the Real Project

Crypto agility means treating cryptographic algorithms as replaceable configuration, not hardcoded assumptions. Without agility, every algorithm change becomes a multi-year rewrite. With agility, you can deploy a new algorithm, negotiate it, measure adoption, and retire the old one.

Start with an inventory. You cannot migrate what you cannot see.

• Protocols: TLS, SSH, IPsec, WireGuard, Signal, S/MIME, QUIC, DTLS, MQTT, and proprietary protocols.
• Libraries: OpenSSL, BoringSSL, LibreSSL, Go crypto, Rustls, Java JCA, .NET, wolfSSL, mbedTLS, and embedded stacks.
• Credentials: X.509 certificates, SSH keys, code-signing keys, API keys, JWT signing keys, database encryption keys, and HSM-backed keys.
• Data stores: Backups, object storage, databases, key-value stores, message queues, and logs that may contain encrypted payloads.
• Hardware: HSMs, TPMs, secure elements, smart cards, network appliances, load balancers, and IoT gateways.

Design principles for agility include algorithm identifiers in policy, runtime negotiation, dual-stack support, feature flags for crypto changes, telemetry on algorithm usage, and a documented deprecation process.

Hybrid Key Exchange in TLS 1.3

TLS is the first place many teams enable post-quantum cryptography because it is internet-facing, well-instrumented, and supports negotiation. Hybrid key exchange combines a classical algorithm such as X25519 with a post-quantum KEM such as ML-KEM. The shared secret is derived from both, so the connection remains secure if either algorithm holds.

In TLS 1.3, hybrid groups appear as named groups. A common group is X25519MLKEM768, which combines X25519 with ML-KEM-768. The client sends its supported groups and key shares. The server selects a mutually supported group and returns its key share. Both sides derive the shared secret using a KDF over the concatenated classical and post-quantum secrets.

1. Client sends supported_groups with hybrid and classical options.
2. Client sends one or more key_share entries, ideally including the hybrid group.
3. Server selects a group, computes its own key share, and sends it back.
4. Both sides derive the handshake secret from the hybrid shared secret.
5. If the hybrid group fails, the server can fall back to a classical group only if policy allows it.

Hybrid TLS introduces larger ClientHello and ServerHello messages. ML-KEM public keys and ciphertexts are measured in kilobytes, not bytes. This can cause TCP segmentation, middlebox issues, and increased bandwidth. In practice, modern TLS stacks handle fragmentation, but you should test with real clients, proxies, firewalls, and load balancers. Monitor handshake size, failure rates, and latency by client type.

Migration steps for TLS:

• Enable hybrid key exchange on a subset of edge servers.
• Keep classical fallback for old clients while measuring usage.
• Update libraries and load balancers to support the selected groups.
• Instrument handshake metrics and alert on negotiation failures.
• Move to PQ-only key exchange only when client support and policy justify it.

Post-Quantum Signatures and PKI

Signatures are often harder than key exchange because they are embedded in certificates, trust stores, firmware, and long-lived artifacts. ML-DSA signatures are thousands of bytes; SLH-DSA signatures can be tens of kilobytes. Certificate chains, OCSP responses, and Certificate Transparency logs all grow. Constrained devices may not have the flash or RAM to store or verify them.

Strategies for PKI migration:

• Hybrid certificates: Include both classical and post-quantum public keys and signatures. This maintains compatibility while adding PQ assurance.
• Parallel PKI: Operate a classical PKI and a post-quantum PKI side by side, with policy-based selection.
• Shorter chains: Reduce the number of intermediates to control certificate size. Use cross-signing carefully.
• Root and intermediate choices: Use SLH-DSA or ML-DSA for roots depending on lifetime and risk. Hash-based signatures are conservative but large.
• Code signing: Plan for larger signatures, timestamping, and long-term validation. Build a dual-signing pipeline.
• Firmware: Secure boot keys may need PQ signatures. Some bootloaders cannot handle large signatures, so a two-stage boot chain or hash-based root may be necessary.

For code signing, consider signing a hash or manifest with ML-DSA while keeping the artifact itself unchanged. For firmware, verify a small root of trust that can accommodate larger signatures, then use that root to authorize smaller classical or PQ signatures for individual components. Blockchain and distributed ledger systems face similar constraints: larger signatures reduce transactions per block and increase fees.

Long-Lived Data and Key Management

Data encrypted today may need to remain confidential for decades. Symmetric encryption with AES-256 or ChaCha20-Poly1305 is generally considered quantum-resistant enough when keys are 256 bits. The weak link is how symmetric keys are established or wrapped. If you use RSA or ECDH to wrap a symmetric key, a quantum adversary can recover it later.

Practical guidance:

• Use AES-256-GCM or XChaCha20-Poly1305 for data at rest where appropriate.
• Wrap keys with hybrid or post-quantum KEMs instead of RSA-OAEP or ECDH.
• Re-encrypt priority data with PQ-wrapped keys, or re-wrap data encryption keys under PQ key-encryption keys.
• Rotate keys and maintain versioned key metadata so algorithms can change without re-encrypting all data at once.
• Use envelope encryption with a KMS or HSM. Verify that your HSM supports the new algorithms or can store opaque PQ keys.
• Plan for crypto-shredding: If data must be destroyed, deleting keys may be more practical than deleting replicated data.

Classify data by confidentiality lifetime. A session token may need minutes; a medical record may need decades. The longer the lifetime, the higher the priority for post-quantum protection today.

Implementation Roadmap

1. Discover: Inventory cryptographic algorithms, protocols, libraries, certificates, keys, and data lifetimes. Include cloud services, on-prem systems, and embedded devices.
2. Prioritize: Start with internet-facing TLS, long-lived secrets, code signing, VPNs, and firmware. Map dependencies and owners.
3. Pilot: Enable hybrid key exchange on non-critical endpoints. Test PQ signatures in an internal PKI. Measure performance and compatibility.
4. Instrument: Track handshake algorithms, certificate sizes, failure rates, latency, CPU usage, and client support. Build dashboards.
5. Migrate: Roll out hybrid modes first. Use policy to prefer PQ when both sides support it. Keep classical fallback with an expiration date.
6. Retire: Deprecate RSA and ECC for vulnerable use cases. Remove weak fallbacks. Document exceptions and risk acceptances.

Operational Considerations

Post-quantum algorithms have different performance profiles. ML-KEM is generally fast, but key sizes are larger. ML-DSA signing is slower than Ed25519, while verification remains practical. SLH-DSA signing is very slow and signatures are large, so it is best for low-volume, high-assurance use cases.

• CPU and memory: Benchmark on your actual hardware. Lattice-based operations can be optimized, but embedded devices may struggle.
• Bandwidth: Larger handshakes and certificates increase latency, especially on lossy networks.
• HSM support: Check vendor roadmaps. Some HSMs support ML-KEM or ML-DSA via firmware updates; others require replacement.
• Libraries: OpenSSL, BoringSSL, Go, Rustls, and other stacks are adding PQ support. Use vetted implementations and keep them updated.
• Compliance: Align with NIST, CNSA 2.0, BSI, ANSSI, and industry requirements. Document your crypto policy.
• Monitoring: Alert on unexpected algorithm downgrades, negotiation failures, and certificate validation errors.

Testing and Validation

Testing must cover interoperability, performance, negative cases, and failure recovery.

• Interoperability: Test client-server combinations across browsers, operating systems, libraries, and devices.
• Test vectors: Use official NIST test vectors for ML-KEM, ML-DSA, and SLH-DSA implementations.
• Negative tests: Verify that invalid signatures, malformed keys, and downgrade attempts are rejected.
• Fuzzing: Fuzz parsers and protocol state machines that handle larger PQ messages.
• Performance regression: Include crypto benchmarks in CI. Track handshake latency and certificate chain size.
• Chaos testing: Simulate algorithm negotiation failure, HSM outage, and fallback policy changes.

Common Pitfalls

• Assuming quantum computers are the only threat. Harvest-now-decrypt-later is a today problem.
• Hardcoding algorithms and key sizes in application code.
• Focusing only on encryption and ignoring signatures and PKI.
• Underestimating certificate, signature, and handshake sizes.
• Skipping telemetry, so you cannot measure adoption or detect downgrades.
• Forgetting embedded devices, IoT, backups, and third-party dependencies.
• Treating hybrid mode as a permanent destination instead of a transition mechanism.
• Using unvetted or experimental PQ implementations in production without review.

Conclusion

Post-quantum migration is a decade-long engineering program, not a single library upgrade. The winning strategy is crypto agility: inventory what you have, prioritize long-lived secrets and signatures, deploy hybrid key exchange first, and build a PKI and key-management roadmap for PQ signatures. Treat algorithms as replaceable components with versions, policies, and telemetry. The goal is not to predict the exact arrival date of a quantum computer. The goal is to make your systems ready to move before the threat becomes urgent.