# Embedding Large PQC KEMs in IKEv2

DevFeed: [Embedding Large PQC KEMs in IKEv2](<https://devfeed.tech/articles/embedding-large-pqc-kems-in-ikev2-100289.md>)

Original publisher: [Read original article](<https://arxiv.org/abs/2610.32356>)

Author: Daniel Herzinger, Marco Thomas, Tobias Handirk, Stefan-Lukas Gazdag, Daniel Loebenberger, Marian Margraf

Published: 2026-10-26T04:00:00Z

Content type: article

Language: en

Sources: [arXiv: Cryptography and Security](<https://devfeed.tech/sources/arxiv-cryptography-and-security.md>)

Topics: [Cryptography](<https://devfeed.tech/topics/cryptography.md>), [QUIC](<https://devfeed.tech/topics/quic.md>), [Virtual Private Network](<https://devfeed.tech/topics/vpn.md>)

Tags: [compatibility](<https://devfeed.tech/tags/compatibility.md>), [computer](<https://devfeed.tech/tags/computer.md>), [cs-cr](<https://devfeed.tech/tags/cs-cr.md>), [data](<https://devfeed.tech/tags/data.md>), [error-correcting-codes](<https://devfeed.tech/tags/error-correcting-codes.md>), [exchange](<https://devfeed.tech/tags/exchange.md>), [handshake](<https://devfeed.tech/tags/handshake.md>), [handshakes](<https://devfeed.tech/tags/handshakes.md>), [ietf](<https://devfeed.tech/tags/ietf.md>), [key](<https://devfeed.tech/tags/key.md>), [keys](<https://devfeed.tech/tags/keys.md>), [measurements](<https://devfeed.tech/tags/measurements.md>), [ml-kem](<https://devfeed.tech/tags/ml-kem.md>), [open-source](<https://devfeed.tech/tags/open-source.md>), [performance](<https://devfeed.tech/tags/performance.md>), [post-quantum](<https://devfeed.tech/tags/post-quantum.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [quic](<https://devfeed.tech/tags/quic.md>), [size](<https://devfeed.tech/tags/size.md>), [specification](<https://devfeed.tech/tags/specification.md>), [transport](<https://devfeed.tech/tags/transport.md>)

## AI overview

The study compares eight ways to carry large post-quantum KEM keys in IKEv2, implemented on one open-source codebase and tested in 126,500 handshakes across 1,296 configurations. No approach fully offsets the key-size impact. Under challenging conditions, none handles Classic McEliece acceptably: approaches either congest the link or average nearly two minutes per handshake. For ML-KEM and FrodoKEM, the authors identify two paths: standardized IKEv2 extensions, which preserve compatibility but require larger implementation changes and further optimization, or delegating transport to QUIC. The latter can avoid those drawbacks through a composite key exchange; QUIKE-composite had the best overall performance. These findings reflect the tested bandwidth, latency, loss, and KEM configurations.

## Source excerpt

arXiv:2610.32356v1 Announce Type: new 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.