VPN/IPsec & SSH PQC
Explore post-quantum key exchange in IKEv2, SSH, and WireGuard protocols.
Why this matters: IKEv2 and SSH key exchange are two of the most widely deployed protocols on earth — hybrid ML-KEM support already exists in production tools like WireGuard's Rosenpass, making this one of the more immediately actionable PQC migrations.
Start here: Choose a key exchange mode — Classical, Hybrid or Pure PQC — and an ML-KEM size, then press Start Daemon: a real IKEv2 exchange runs between initiator and responder, phase by phase in the diagram.
For your role
- Developer / Engineer
- Step through IKEv2 in Classical, Hybrid and Pure PQC modes, compare SSH key exchange with curve25519, sntrup761 and mlkem768, and compare IKEv2, SSH, WireGuard and TLS 1.3 sizes and round trips.
- Researcher / Academic
- The protocol comparison of sizes, RTTs and features across IKEv2, SSH, WireGuard and TLS 1.3 is the measurement; the VPN and SSH simulators produce the packets.
- IT Ops / DevOps
- The IKEv2 modes and the SSH KEX comparison are what your VPN and SSH configurations will carry; the simulators produce the strongSwan config and the sshd changes.
IKEv2 Handshake Overview
(Internet Key Exchange version 2, RFC 7296) is the key negotiation protocol for VPNs. It establishes Security Associations (SAs) through a two-phase handshake: IKE_SA_INIT for key exchange and IKE_AUTH for identity verification.
The KE payload carries public values. Both parties derive the same shared secret (SKEYSEED) from their DH exchange, nonces, and SPIs, then derive encryption and integrity keys for the IKE SA.
in IKEv2
The IETF draft draft-ietf-ipsecme-ikev2-mlkem defines how to integrate ML-KEM () into IKEv2 using the Additional Key Exchange (AKE) framework (RFC 9370). This enables hybrid key exchange without modifying the core IKEv2 state machine.
“The initiator generates an ML-KEM keypair (pk, sk) using KeyGen(), and sends the public key (pk) to the responder inside a KEi(1) payload. The responder will encapsulate a shared secret ss using Encaps(pk) and the resulting ciphertext (ct) is sent to initiator using the KEr(1).”
— draft-ietf-ipsecme-ikev2-mlkem-09, Appendix A
ECP-256 or MODP-2048 in KE payload during IKE_SA_INIT. Quantum-vulnerable.
ML-KEM-768 encapsulation key (1,184 B) in IKE_INTERMEDIATE. Adds one round trip.
SKEYSEED derived from both DH and KEM shared secrets via PRF. Secure if either holds.
Pure ML-KEM in IKEv2: Known Limits
A pure (quantum-resistant-only) IKEv2 handshake has no classical key exchange to fall back on, so ML-KEM must travel in the very first message, IKE_SA_INIT. That is where the draft's main restriction sits: IKEv2 fragmentation (RFC 7383) only works on encrypted messages, and IKE_SA_INIT is sent before any keys exist. In the draft's words, these messages “could not be IKEv2 fragmented”. A payload bigger than the path MTU falls back to IP fragmentation, which NATs and firewalls often drop and which is a known denial-of-service target.
| Parameter set | KE payload (key / ciphertext) | Pure PQC in IKE_SA_INIT over UDP |
|---|---|---|
| ML-KEM-512 (35) | 808 / 776 B | MAY be used |
| ML-KEM-768 (36) | 1,192 / 1,096 B | SHOULD NOT when the path MTU is unknown, unless IKE runs over TCP |
| ML-KEM-1024 (37) | 1,576 / 1,576 B | SHOULD NOT when the path MTU is unknown, unless IKE runs over TCP |
CNSA 2.0 requires ML-KEM-1024, but ML-KEM-512 is the only size the draft allows in a pure UDP IKE_SA_INIT without conditions. A pure CNSA 2.0 IKEv2 deployment therefore has to run IKE over TCP (RFC 9329), guarantee the path MTU, or accept IP fragmentation.
Appendix A runs a classical exchange in IKE_SA_INIT and carries ML-KEM-768/1024 in IKE_INTERMEDIATE (RFC 9242 / RFC 9370). Those messages are encrypted, so RFC 7383 fragmentation applies. The cost: the first exchange is no longer quantum-resistant on its own. That makes this a hybrid design, not pure PQC.
The draft also requires a fresh ML-KEM key pair and fresh encapsulation randomness for every exchange. The responder must check the initiator's encapsulation key (FIPS 203 §7.2) before encapsulating, and should reject a bad key with INVALID_SYNTAX to limit resource-exhaustion attacks. The draft further warns that an on-path attacker with a quantum computer could steer peers onto a classical-only group unless local policy forbids one. None of this makes the draft a dead end. It sits in the RFC Editor queue, and several firewall vendors already ship hybrid ML-KEM IKEv2. Only pure-PQC IKEv2 at the higher security levels over plain UDP remains an open engineering problem.
Key Exchange with
OpenSSH has been a pioneer in deploying post-quantum key exchange. Since version 8.5 (March 2021), it has shipped with sntrup761x25519-sha512 — a hybrid of Streamlined NTRU Prime and X25519. In OpenSSH 9.9 (September 2024), NIST-standard mlkem768x25519-sha256 was added.
sntrup761x25519-sha512sntrup761x25519-sha512mlkem768x25519-sha256SSH hybrid KEX works by concatenating the classical and PQC public keys in SSH_MSG_KEX_ECDH_INIT, and concatenating the classical share and KEM ciphertext in SSH_MSG_KEX_ECDH_REPLY. The shared secret is derived from both components.
& PQC
WireGuard uses the Noise IK protocol framework with a fixed cipher suite: , ChaCha20-Poly1305, BLAKE2s. This minimal design makes WireGuard fast and auditable, but also means it has zero — algorithms cannot be negotiated.
WireGuard's fixed X25519 is quantum-vulnerable. Adding PQC requires modifying the protocol or layering a separate negotiation on top.
runs a separate PQC key exchange (ML-KEM + Classic McEliece) and feeds the resulting PSK into WireGuard's pre-shared key slot.
The Rosenpass approach preserves WireGuard's simplicity while adding quantum resistance. The PSK is rotated periodically, and WireGuard's security holds even if Rosenpass is compromised (defense in depth).
Protocol Size Impact
Post-quantum key exchange significantly increases handshake sizes across all protocols. ML-KEM-768 adds approximately 1,184 bytes for the encapsulation key and 1,088 bytes for the ciphertext. For protocols like WireGuard that use UDP, this can cause IP fragmentation issues.
| Protocol | Classical | Hybrid | Increase |
|---|---|---|---|
| IKEv2 | 1,400 B | 3,784 B | +170% |
| SSH | 984 B | 3,296 B | +235% |
| WireGuard | 304 B | 6,800 B | +2137% |
| TLS 1.3 | 1,200 B | 3,500 B | +192% |
WireGuard sees the largest relative increase (22x) because its classical handshake is extremely compact. IKEv2 handles fragmentation explicitly (RFC 7383) over UDP, but only for encrypted messages, so it cannot help IKE_SA_INIT. SSH handles larger payloads natively because it relies on TCP transport.
Authentication: The Missing Half
While PQC Key Exchange (ML-KEM) secures connections against future decryption, Authentication using secures against active attackers. Both IKEv2 and SSH uniquely require multiple layers of authentication that must be migrated.
In addition to the AKE payloads, draft-ietf-ipsecme-ikev2-pqc-auth updates the IKE_AUTH phase to support (). The Auth payload verifies identities using post-quantum certificates.
SSH requires PQC host keys (server identity) and user keys (UserAuth). While OpenSSH 9.9 supports ML-KEM, standardizing ML-DSA keys for host and user authentication is still an active effort.
Control Plane vs. Data Plane
The migration to PQC only applies to the Control Plane (key exchange & auth). The actual Data Plane (the VPN tunnel) already uses symmetric algorithms like AES-GCM or ChaCha20-Poly1305. These algorithms are naturally quantum-resistant, requiring only standard key lengths (256-bit) to be secure against Grover's algorithm.
Related Resources
Step through IKEv2 and SSH handshakes, compare classical vs hybrid vs pure PQC modes.
Products shown here are a representative selection — not an exhaustive list. For the full vendor landscape with PQC readiness status, visit the Tools & Products tab in this module or browse the Migrate catalog →
Check off all sections and mark this reading done.
Related modules
- Hybrid CryptographySame migration phase · Shares ML-KEM, ECDH
- TLS BasicsSame track · Protocols · Same migration phase · Shares ML-KEM
- MLS — Group MessagingSame track · Protocols · Same migration phase · Shares ML-KEM
- PKI Enrollment Protocols (EST & CMP)Same track · Protocols · Same migration phase · Shares ML-KEM
In the Industry Landscape
- Cross-IndustryRemote-access & site-to-site VPN
- IT Industry / SoftwareCrypto libraries & TLS stacks — key exchange · Crypto libraries & TLS stacks — PQC signatures · Administrative access (SSH)
- Aerospace / AviationBy protocol · Satellite communications & ground links
- Critical Infrastructure / EnergyBy protocol · Pipeline & OT remote-access VPNs
- Education / ResearchBy protocol · Research data protection (CUI)
- Government & DefenseBy protocol · National security systems — transport (CNSA 2.0) · National security systems — protocol authentication (CNSA 2.0) · Classified communications & NC3
- Rail / TransitBy protocol · Railway mobile communications (GSM-R → FRMCS)
- TelecommunicationsBy protocol · Backhaul & core transport (IPsec/TLS) · Legacy subscriber authentication
- Water / WastewaterBy protocol · Treatment plant SCADA & remote ops · Dam & hydropower remote access
Check your understanding
10 questions on VPN/IPsec & SSH, each with its answer and the reason.
Take the quizNext step
Practice it: PQC VPN SimulatorPQC VPN Simulator is the hands-on version of this module: the same ideas, run in your browser.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.