Migrating to Hybrid Key Exchange

The threat, restated plainly

A cryptographically relevant quantum computer (CRQC) doesn't exist today and probably won't for a decade. But:

1. Adversaries record encrypted traffic now. ISPs, intelligence agencies, and well-resourced actors store encrypted bulk traffic indefinitely.
2. Once a CRQC exists, all that recorded traffic decrypts retroactively if its key exchange used pre-quantum primitives (RSA, DH, ECDH).
3. Symmetric crypto (AES, ChaCha20) is largely fine. Doubling key length defeats Grover's algorithm. The problem is asymmetric, in KEMs and signatures.

Migration timing depends on secrecy horizon: how long does the data need to stay confidential? If the answer is "5 years," you can wait. If the answer is "30 years," you need to be migrating now.

Triage by secrecy horizon

The harvest-now-decrypt-later threat is real for the bottom half of this list. For the top half, migrate when your stack supports it; no urgency.

TLS 1.3 migration

Today (mid-2026)

Most modern stacks support X25519MLKEM768 as a hybrid KEM:

• BoringSSL (Chrome, Edge): default since 2024.
• rustls ≥ 0.23: opt-in flag.
• OpenSSL ≥ 3.5: native ML-KEM/ML-DSA/SLH-DSA; GA shipped March 2026.
• Go 1.24+: default-on.
• Apple (Safari/iOS 26): iOS 26, macOS Tahoe 26, visionOS 26 ship ML-KEM-768/1024 in CryptoKit; hybrid X25519MLKEM768 default for URLSession and Network.framework (WWDC 2025, production since late 2025).
• Cloudflare: enabled at edge; >65% of human traffic is PQ-encrypted as of April 2026; IPsec GA since April 2026 (Cisco + Fortinet interoperability confirmed).
• AWS: ML-KEM hybrid TLS by default across KMS, Secrets Manager, ACM, Payment Cryptography, and S3 since April 2026.

Server configuration:

# nginx with OpenSSL 3.5+
ssl_protocols TLSv1.3;
ssl_curves X25519MLKEM768:X25519:secp256r1;

Verify with openssl s_client -connect host:443 -groups X25519MLKEM768.

Caveats

• Older clients fall back to X25519. That's fine, the negotiation is by design backward-compatible.
• Middleboxes (some legacy SSL inspection) drop hybrid handshakes. Test rollouts with --alt-svc toggles.
• Performance: about 2 KB extra per handshake. For most applications, negligible.

What about pure-PQ?

Don't deploy pure ML-KEM yet. Hybrid is the production pattern in 2026 and will remain so for years. Pure PQ deployment requires more confidence in the lattice security level than the community currently has.

SSH migration

OpenSSH has offered post-quantum key agreement by default since 9.0. The ML-KEM/X25519 hybrid mlkem768x25519-sha256 was added in 9.9 and became the default in OpenSSH 10.0 (April 2025).

If you maintain an explicit algorithm list on OpenSSH 10.0 or later, include the default hybrid. Otherwise, use the upstream defaults.

Server sshd_config:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Client config (~/.ssh/config):

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Modern OpenSSH on both sides means already migrated. No further action for most users.

Encrypted messengers

For users: most messengers don't need active migration; providers handle it transparently. Audit which messengers you trust for long-secrecy traffic.

VPN / mesh migration

For high-stakes mesh / overlay deployments, layer with TLS-over-TCP using PQ TLS rather than relying on the underlay's pre-quantum keys.

Code signing

Long-lived signed artifacts (firmware, OS distributions, vendor tools) need migration first. The signature on a kernel binary signed today must verify in 30 years; the verifier will exist in a quantum world.

Migration paths:

• Hybrid signatures: classical Ed25519 + ML-DSA-65 (or SLH-DSA for conservative). Verify both.
• Sigstore: PQ extension in discussion.
• OS package managers: per-distro roadmaps. Debian, Fedora exploring; Arch leaning on upstream.

For long-lived embedded systems (cars, satellites, industrial control): re-sign existing firmware with hybrid signatures during scheduled updates.

Encrypted backups and archives

For long-secrecy archives, check the recipient type as well as the tool version. Existing classical recipients do not become post-quantum recipients after a software update.

• age 1.3.0: native hybrid post-quantum recipients use HPKE with ML-KEM-768. Generate a key pair with age-keygen -pq; its recipient begins age1pq1. A compatibility plugin exists for older clients.
• GPG: OpenPGP PQ draft RFC; mainline OpenPGP support is emerging and remains outside routine production defaults.
• Roll-your-own with libsodium-PQ: practical for new systems, not for migration.

For age archives that need post-quantum recipients, use age 1.3.0 or later and generate a PQ key pair with age-keygen -pq. Re-encrypting an archive requires selecting the new recipient; changing the installed program alone does not change existing ciphertext. See age File Encryption.

Bitcoin and crypto-currencies

Bitcoin's signatures (ECDSA legacy and Schnorr Taproot) are pre-quantum. The migration:

• Pubkey reuse increases exposure. Once an address has spent, its pubkey is on-chain and a future quantum computer can derive the private key.
• Send-only-once practice: derive a new address per receive; spend once; new address.
• Cold storage (P2PK addresses) are the highest risk. Many old satoshis sit at P2PK addresses with revealed public keys.
• BIP-360 and similar drafts propose adding PQ-friendly signature support; none deployed as of 2026.

The actionable 2026 guidance: avoid address reuse; don't be one of the public-key-revealed-at-rest holders.

Database / at-rest encryption

Most database / disk encryption uses symmetric primitives (AES-256-GCM, XTS), which are fine post-quantum. The vulnerable layer is key wrapping and key escrow, the asymmetric layer that wraps the symmetric key.

Audit:

• AWS KMS: ML-KEM hybrid TLS for API calls (April 2026); ML-DSA key pair generation now available in KMS. If using AWS SDK with latest version, KMS operations already route over PQ TLS.
• Azure Key Vault, GCP KMS: classical RSA / EC key wrap. Some PQ pilot offerings; check vendor roadmaps.
• HSMs: confirm ML-KEM support in firmware.
• Custom key-wrap protocols: migrate to hybrid wraps.

For most cloud users, the cloud KMS team handles this; ensure your key-wrap algorithm choice points to PQ-supporting variants when available.

Crypto-agility

The right architecture isn't "deploy ML-KEM today and forget it." It's crypto-agility: the ability to swap primitives quickly when one breaks. Practical:

• Negotiate algorithms at protocol layer; don't hardcode.
• Version your protocols so policy can be tightened without breaking deployment.
• Monitor the field. New attacks on Module-LWE could change parameter recommendations.
• Hybrid by default. Single-primitive deployment is the anti-pattern.

Trade-offs

Strengths

• Hybrid migration is mature and battle-tested.
• Wide library support in 2026.
• Operationally manageable. Most stacks need configuration, not custom code.

Limitations

• Bandwidth cost. Hybrid handshakes are 2-5 KB larger.
• Library bugs still being shaken out in newer PQ implementations.
• Long-tail systems (legacy embedded, IoT, blockchains) need protocol-specific migration paths.
• Coordination across PKI hierarchies (X.509, code signing) is slow.

Quick reference: 2026 migration checklist

[ ] TLS 1.3 servers updated to OpenSSL 3.5+ / boringssl with X25519MLKEM768 enabled
[ ] SSH client + server on OpenSSH ≥ 9.0
[ ] Encrypted messengers in use confirmed PQ-capable (Signal: yes; iMessage: yes; ...)
[ ] Long-lived code-signing keys planned for hybrid migration
[ ] Long-lived encrypted archives re-encryption planned
[ ] HSM firmware audited for ML-KEM/ML-DSA support
[ ] Crypto-agility — algorithms negotiable in custom protocols
[ ] Bitcoin / crypto: avoid address reuse; track BIP migrations

Primary sources

• OpenSSH post-quantum cryptography

• age v1.3.0 release: native hybrid post-quantum recipients

• IETF, Hybrid key exchange in TLS 1.3, draft-ietf-tls-hybrid-design.

• Cloudflare PQC blogs — blog.cloudflare.com.
• Apple, iMessage with PQ3, security blog Feb 2024.
• Signal, PQXDH, Sep 2023.
• NIST PQC project — csrc.nist.gov/projects/post-quantum-cryptography.
• liboqs — openquantumsafe.org.
• Migrating to Post-Quantum Cryptography (NIST IR 8413, 2024).

Continue with Build a post-quantum cryptographic inventory.