Embedding large post-quantum keys into IKEv2 VPN handshakes
Embedding Large PQC KEMs in IKEv2
Cryptography and Security
Summary
VPNs use a protocol called IKEv2 to exchange keys and create secure connections, but newer encryption methods made to resist quantum computers have much larger keys that IKEv2 wasn't designed to handle. The authors compared several proposals and their own new ideas to fit these big keys into the VPN handshake without breaking performance or stability. They tested these methods on multiple encryption schemes and network conditions, finding that no one fix works perfectly, especially for the very large keys. Two promising paths involve either extending the existing protocol or using a newer transport layer called QUIC, with the latter offering faster and more reliable handshakes.
What this means in practice
- •For vpn developers: Integrate tested methods to embed large post-quantum keys into IKEv2 to enhance quantum-resistant VPN handshakes.
- •For network infrastructure engineers: Deploy QUIC-based key exchange mechanisms for faster and more reliable VPN connections under challenging network conditions.
Authors
Daniel Herzinger, Marco Thomas, Tobias Handirk, Stefan-Lukas Gazdag, Daniel Loebenberger, Marian Margraf
Abstract
Post-quantum key encapsulation mechanisms carry public keys far larger than the established VPN handshake protocol IKEv2 was designed for. At the same time, its initial exchange comprising the public keys cannot be fragmented. In response, the IETF discusses a range of protocol adjustments, yet these proposals have never been compared in terms of their performance and stability under identical conditions. We systematically screened the IETF document corpus for such proposals, added three of our own (one using forward error correction and two using IKEv2 with QUIC, namely QUIKE and QUIKE with a composite key exchange), identified two specification gaps in existing acknowledgment drafts, and implemented all eight on the same open-source codebase. Measurements across different bandwidths, latencies, and packet loss rates, and with ML-KEM, FrodoKEM, and Classic McEliece, total 126 500 handshakes in 1296 different configurations and show that no mechanism fully compensates for the effect of the key size on performance. For Classic McEliece, no approach handles challenging conditions acceptably. The approaches either congest the link or take up to nearly two minutes per handshake on average. For ML-KEM and FrodoKEM, there are two ways forward: building on already standardized extensions or delegating the transport. The former requires the larger implementation change and needs further optimization, such as acknowledgment mechanisms or error-correcting codes, but grants continuity and compatibility. The latter can use a composite key exchange to avoid these drawbacks and achieve a faster, more resilient handshake and leaner implementation, with QUIKE-composite offering the best overall performance.