Pith. sign in

REVIEW 4 major objections 4 minor 64 references

Hybrid Quantum Security for IPsec

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read By packing the post-quantum key and the QKD key identifier into one IKE_SA_INIT exchange, parallel hybrid QKD-PQC key establishment avoids the extra round trips of RFC 9370's sequential IKE_INTERMEDIATE exchanges, keeping IPsec handshakes…

desk verdict Parallel QKD-PQC hybrid for IPsec: real implementation, useful comparison, but the headline latency number is partly a measurement-placement artifact. read the letter →

arxiv 2507.09288 v1 pith:3MNF7HI2 submitted 2025-07-12 cs.CR cs.NI

Javier Blanco-Romero , Pedro Otero García , Daniel Sobral-Blanco , Florina Almenares Mendoza , Ana Fernández Vilas , Manuel Fernández-Veiga This is my paper · ORCID
classification cs.CRcs.NI
keywords QuantumKeyDistributionIPsecIKEv2Post-QuantumCryptographyHybridexchangeML-KEMETSIQKDAPIHandshakelatency
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that when combining Quantum Key Distribution (QKD) with post-quantum cryptography inside IPsec, the way the two key sources are sequenced matters as much as the cryptography itself. The standardized sequential approach of RFC 9370 moves the second key exchange into extra IKE_INTERMEDIATE round trips, each paying the full network latency, while the paper's parallel approach packs the QKD key identifier and the post-quantum public key into the same IKE_SA_INIT exchange and keeps the handshake at one round trip. Measured with IDQuantique QKD hardware under emulated latency, the parallel hybrid keeps its timing advantage as network delay grows, and pure QKD needs only 270-319 bytes per initial exchange because it transmits 16-byte identifiers instead of key material. The authors present this as a protocol design principle: prefer parallel composition when the combined payload fits the path MTU, and reserve sequential exchanges for cases where fragmentation must be avoided.

What carries the argument

The load-bearing object is the QKD-KEM abstraction: a unified key-encapsulation interface that hides whether the 'KEM' operation is pure post-quantum, pure QKD, or a parallel composition of both, implemented as a strongSwan plugin and an OpenSSL provider. Embedded in the standard IKE_SA_INIT KEY_EXCHANGE payload, it lets a single round trip carry the QKD key identifier (16 bytes, plus an optional 4-byte index for ETSI 004 stream positioning) next to the ML-KEM public key or ciphertext. The counterpoint is RFC 9370's sequential machinery, which routes the second key source through IKE_INTERMEDIATE exchanges enabled by RFC 9242; each such exchange costs a full network round trip. The ETSI API wrapper, supporting 004's stateful OPEN_CONNECT/GET_KEY/CLOSE and 014's stateless REST GET_KEY/GET_KEY_WITH_IDS, is what resolves the identifiers to actual quantum keys, and the concatenation rule $\mathit{shared\_secret} = \mathit{PQC\_secret} \parallel \mathit{QKD\_key}$ is what gives the hybrid its defense-in-depth property: the session stays secure as long as either component holds.

What would settle it

Re-run the same handshake measurements with the same netem emulation applied to the Alice-KME and Bob-KME links as well as to the tunnel, for example 100 ms of added latency on the ETSI API traffic; if the parallel hybrid's end-to-end advantage over the sequential RFC 9370 approach collapses or reverses once KME round trips dominate, then the claimed multiplicative-latency penalty is an artifact of the unperturbed KME assumption rather than a general protocol property.

Watch

Extended reading notes

Core claim

The central claim is that parallel hybrid key establishment outperforms the sequential hybrid exchange that RFC 9370 mandates, under realistic network conditions, by eliminating the multiplicative latency penalty of extra round trips. Concretely, the parallel hybrid composed through the QKD-KEM abstraction preserves the native IKEv2 flow: the initiator sends one KEY_EXCHANGE payload carrying both an ML-KEM public key and a 16-byte QKD key identifier, the responder answers with the ciphertext, and both sides concatenate the post-quantum secret with the quantum key ($\mathit{shared\_secret} = \mathit{PQC\_secret} \parallel \mathit{QKD\_key}$). The sequential alternative needs IKE_INTERMEDIATE exchanges that each add a full round trip, measured at roughly 200 ms extra under 100 ms artificial delay for two additional exchanges, with the penalty growing proportionally with latency. Pure QKD replaces key material entirely with identifiers: the initiator sends only the key ID, the responder retrieves the corresponding quantum key from the Key Management Entity, and no Diffie-Hellman values travel. Across both ETSI GS QKD 004 (stateful) and ETSI GS QKD 014 (stateless) APIs, pure QKD achieves 270-319 bytes per exchange, lower than the classical baselines, and QKD+ML-KEM-512 (816 bytes) and QKD+ML-KEM-768 (1200 bytes) payloads fit within the standard 1500-byte MTU, making the parallel approach fragmentation-free for the most likely deployments.

Load-bearing premise

The measured speed advantage assumes that retrieving quantum keys from the Key Management Entity is fast and unaffected by network conditions, because the emulated latency and loss were applied only to IPsec tunnel traffic and not to the endpoints' communication with their QKD nodes; if a real deployment's KMEs sit behind high-latency links, the blocking ETSI calls would add comparable delay to both the sequential and the parallel approach and shrink the gap.

Editorial extensions

If this is right

  • Parallel hybridization through a single IKE_SA_INIT round trip keeps IPsec handshake latency roughly flat as network round-trip time grows, whereas each IKE_INTERMEDIATE exchange in the sequential scheme adds the full round-trip delay; the paper measures two extra exchanges at about 200 ms under 100 ms emulated latency.
  • Because QKD+ML-KEM-512 (816 bytes) and QKD+ML-KEM-768 (1200 bytes) payloads fit inside the 1500-byte MTU, the parallel hybrid needs neither IP fragmentation nor IKE-level fragmentation, eliminating both the latency penalty and the extra header bytes of sequential exchanges.
  • Pure QKD mode's identifier-based coordination transmits only 16-byte key identifiers, giving 270-319 byte IKE_SA_INIT packets that beat the classical ECC baseline on bandwidth and remove the need to exchange any public key material at all.
  • The latency penalty of sequential hybridization is inherent to the extra round trips rather than specific to QKD: the paper's sequential classical+PQC baseline (x25519 plus Kyber via IKE_INTERMEDIATE) shows the same elevated network time, so the design rule extends to any hybrid whose components could fit in one exchange.
  • The performance gap between sequential and parallel stems from network-level protocol overhead, not cryptography: processing overhead $\Delta t_{\text{overhead}}$ stays roughly constant across proposals while network time $t_{\text{net}}$ is what separates the two strategies.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's payload-size estimation rule admits a concrete engineering corollary the authors only gesture at: adaptive flow initiation, choosing client- versus server-initiated QKD depending on whether the post-quantum public key or ciphertext is larger, could shave fragments for asymmetric algorithms such as HQC while preserving the single-round-trip structure.
  • The parallel-advantage result is conditional on where the Key Management Entity sits; a deployment with remote or congested KMEs would make both strategies pay the blocking ETSI call latency, so the practical recommendation to prefer parallel hybrids should be read as valid for co-located or low-latency key management.
  • The identifier-based design relocates the trust boundary: security now hinges on the secrecy and availability of the KME and its links, and the same abstraction could be reused in other protocols, such as TLS or SSH, once they offer a single-flight key exchange slot that can carry an identifier alongside a KEM key.
  • A testable extension is to quantify the parallel scheme's reliability edge under packet loss: one round trip means fewer packets that can be lost, so the completion-rate advantage the paper observes qualitatively should be measurable as a curve of handshake success versus increasing loss on the tunnel link.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper presents two QKD integration strategies for IKEv2/IPsec: a pure QKD plugin that replaces Diffie-Hellman exchange with QKD key identifiers, and a QKD-KEM plugin that packages QKD key retrieval into a KEM-like interface for parallel composition with ML-KEM. The authors compare these with RFC 9370 sequential hybrids using strongSwan on Docker containers, Pumba network emulation, and two IDQuantique Cerberis XGR QKD nodes. The main claim is that parallel hybrid key establishment avoids the extra round trips imposed by sequential IKE_INTERMEDIATE exchanges, reducing handshake latency under network delay, while pure QKD minimizes bandwidth overhead by exchanging only key identifiers.

Significance. If sustained, the paper would be a useful practical contribution: it demonstrates real QKD hardware integration with both ETSI QKD-004 and QKD-014 APIs, provides open-source plugins and a reproducible Docker testbed, and gives a protocol-level comparison of sequential versus parallel hybrid key establishment. The qualitative point that parallel composition removes at least one network round trip relative to IKE_INTERMEDIATE-based sequential composition is well motivated by the protocol structure and by the packet-capture evidence. However, the quantitative support for the central latency claim is weakened by a measurement-placement confound involving which QKD API flow is used, by missing statistical detail such as error bars, and by references to a 500 ms condition that does not appear in the reported figures. These issues are repairable and do not appear to invalidate the qualitative conclusion.

major comments (4)
  1. [Section 7, Figure 5, Section 6.5.1] The attribution of the ~200 ms penalty for kyber1-ke1_qkd to two additional IKE_INTERMEDIATE network trips is not supported by the reported measurements. Section 6.5.1 states that tnet includes blocking HTTPS calls to QKD nodes, and Section 6.3 states that Pumba netem targets only IPsec tunnel traffic, leaving KME communication unperturbed. The parallel qkd_kyber1 uses the client-initiated QKD flow, whose KME retrieval occurs before the first IKE_SA_INIT packet and is excluded from tnet, while kyber1-ke1_qkd uses the server-initiated flow, so Alice's GET_KEY_WITH_IDS() call falls inside the tnet window. The ~200 ms difference may therefore combine one IKE_INTERMEDIATE round trip with one KME API call that is counted as network time, rather than being purely two full network round trips. The concluding sentence that the 200 ms difference 'directly corresponds to the two extra trips' should be reworked, or the experiment should be rerun with matched QKD flow types in the sequential and parallel arms.
  2. [Section 7, Figures 4-6] The paper makes quantitative claims of 'significant performance improvements' and states that under 500 ms latency the gap widens considerably, but Figure 4 only shows conditions labeled 'No Network Conditions', 'Lat:10ms', and 'Lat:100ms'; the 500 ms condition is never plotted. None of Figures 4-6 shows error bars or standard deviations, despite Section 6.5.1 presenting an uncertainty-propagation analysis and promising conservative error estimates. Without per-iteration statistics or at least a table of means and standard deviations, the reader cannot assess whether the reported differences between sequential and parallel hybrids are distinguishable from run-to-run variation. Please add the missing 500 ms data and report error bars or confidence intervals for all timing figures.
  3. [Section 6.3, Section 8] The generalizable claim that parallel hybrids are superior 'under realistic network conditions' is based on an experiment in which KME communication is deliberately left unperturbed. In real deployments the ETSI API calls to a remote Key Management Entity may traverse high-latency links, and because these calls are blocking and, for server-initiated flows, fall inside the measured tnet window, the size of the advantage could shrink or even change. The paper should state this boundary condition prominently and should either include experiments with latency applied to the KME links or explicitly restrict the conclusion to deployments with co-located or low-latency KMEs.
  4. [Section 9, Section 4.1] The manuscript itself states in Section 9 that the integration lacks explicit proof-of-possession and is 'potentially leaving it vulnerable to replay attacks without active key verification or mutual possession proof.' This is a substantive security limitation for a protocol proposed for 'critical infrastructure deployments requiring defense-in-depth security.' It should be moved from a brief closing caveat into the security analysis of Section 4.1, and the abstract and conclusions should be qualified so that the security claim matches the proof-of-possession gap.
minor comments (4)
  1. [Figure 5 caption] The caption uses 'toverhead' without the Delta symbol; for consistency with Equation (3) it should read 'Δtoverhead'.
  2. [Section 7] The sentence 'we observed IP fragmentation occurring only for ML-KEM-1024 combinations' is easily read as contradicting Table 2, which lists multiple algorithms with multiple fragments. Please clarify that this refers to IP-level fragmentation, as opposed to the IKE-level fragmentation used for large post-quantum payloads.
  3. [Section 3.2 and Table 1] The notation 'QKD + 816 768 800 784' in Table 1 is hard to parse; a clearer layout with explicit Request/Response columns for each flow would improve readability.
  4. [Section 5.2] The relationship to the authors' prior TLS work [46] is stated, but the sentence would be clearer if it said explicitly that the QKD-KEM plugin reuses the OpenSSL provider from that work rather than only 'adapting concepts' from it.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the parallel-versus-sequential latency claim rests on direct wire-protocol measurements, not on fitted inputs or a self-citation chain.

full rationale

The paper's central result, that parallel QKD-KEM hybrid key establishment avoids the extra IKE_INTERMEDIATE round trips required by RFC 9370 sequential hybrids, is grounded in direct measurements on a Docker testbed with IDQuantique hardware and packet captures, not in a model fitted to its conclusion. No parameter is fitted to produce the latency advantage; the advantage follows from the wire protocol itself: sequential hybrids add extra round trips while parallel hybrids preserve the original two-message IKE_SA_INIT exchange. The only self-citation is [46], used to state that the QKD-KEM plugin 'adapts concepts from our previous TLS integration work'; that provenance claim is not the load-bearing evidence for the IPsec latency or bandwidth results, so it does not constitute circularity. A genuine measurement concern exists but is not circularity: tnet is defined in Section 6.5.1 to include blocking HTTPS calls to QKD nodes, while Pumba's netem in Section 6.3 perturbs only Alice-Bob traffic; the paper's attribution of the full ~200 ms kyber1-ke1_qkd penalty to 'two extra trips' in Section 7 is partly confounded by the server-initiated GET_KEY_WITH_IDS() KME call acknowledged in the Figure 5 caption. This affects the quantitative decomposition, not the qualitative conclusion that parallel composition avoids at least one network RTT. Accordingly, no circular step is established by the quoted text; score 1 reflects the minor, non-load-bearing self-citation and the questionable quantitative attribution, not derivation-by-construction.

Assumptions & free parameters 5 free parameters · 6 assumptions · 0 invented entities

The central performance claim rests on empirical measurements in a specific testbed. The main assumptions are that the ETSI QKD APIs deliver shared keys correctly, that hybrid key concatenation is secure, and that the network emulation isolates the IPsec tunnel from QKD backend latency. Configuration parameters such as buffer sizes and timeouts were chosen by hand for the testbed and could affect absolute numbers, though not the qualitative round-trip argument.

free parameters (5)
  • max_packet = 25000 bytes
    strongSwan maximum IKE packet size raised from the default 10,000 bytes to carry large post-quantum payloads; affects whether packets are fragmented and thus the byte counts in Table 2 and Figure 6.
  • fragment_size = 1472 bytes
    strongSwan IKE fragment size set to Ethernet MTU minus IP and UDP headers; chosen to balance compatibility and bandwidth, directly affecting the fragmentation measurements in Table 2.
  • retransmit_timeout = 3 s
    IKE retransmission timeout reduced from the default 4 s to speed up test iterations; affects handshake timing under packet loss.
  • half_open_timeout = 20 s
    IKE half-open SA timeout reduced from the default 30 s; affects behavior when peers fail to complete the handshake.
  • retransmit_tries = 3
    Number of retransmission attempts reduced from the default 5; affects reliability measurements in lossy scenarios.
assumptions (6)
  • domain assumption QKD hardware and ETSI APIs provide genuinely shared secret keys to both IPsec endpoints.
    The entire scheme assumes the Key Management Entities deliver the same key material to Alice and Bob via ETSI GS QKD 004/014; any synchronization failure breaks the protocol (Sections 3.1, 5.3).
  • domain assumption Concatenation of the post-quantum shared secret and the QKD key is a secure hybrid combiner when either component is secure.
    Used in Section 4.2, citing the TLS hybrid design framework [18]; no standalone proof is given for the IKEv2 context.
  • domain assumption strongSwan 6.0's RFC 9370 multiple key exchange implementation is a correct and representative sequential baseline.
    The sequential comparison relies on this implementation (Section 6.4, [54]); any performance artifact in strongSwan could bias the comparison.
  • ad hoc to paper Network emulation does not alter QKD backend communication latency, isolating the IPsec tunnel as the only variable.
    Pumba netem rules target only IPsec traffic (Section 6.3); real deployments with remote KMEs would add latency to QKD API calls and could change the relative timing.
  • domain assumption IKEv2 authentication detects any active substitution of QKD key identifiers that occurs during IKE_SA_INIT.
    Security analysis in Section 4.1 relies on AUTH failure to detect MITM; the paper notes this can be hard to distinguish from legitimate failures and provides no proof-of-possession.
  • domain assumption The measured tnet window from the first IKE_SA_INIT packet to the last message before IKE_AUTH captures the key-establishment phase cleanly.
    Defined in Section 6.5.1; blocking QKD API calls occurring outside this window are attributed to plugin overhead, which affects the decomposition in Figure 5.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Hybrid Quantum Security for IPsec." pith.science (2026). https://pith.science/paper/3MNF7HI2

@misc{pith2026250709288,
  author       = {Pith},
  title        = {Pith review of: Hybrid Quantum Security for IPsec},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3MNF7HI2}},
  note         = {Machine review of arXiv:2507.09288}
}
read the original abstract

Quantum Key Distribution (QKD) offers information-theoretic security against quantum computing threats, but integrating QKD into existing security protocols remains an unsolved challenge due to fundamental mismatches between pre-distributed quantum keys and computational key exchange paradigms. This paper presents the first systematic comparison of sequential versus parallel hybrid QKD-PQC key establishment strategies for IPsec, revealing fundamental protocol design principles that extend beyond specific implementations. We introduce two novel approaches for incorporating QKD into Internet Key Exchange version 2 (IKEv2) with support for both ETSI GS QKD 004 stateful and ETSI GS QKD 014 stateless API specifications: (1) a pure QKD approach that replaces computational key derivation with identifier-based quantum key coordination, and (2) a unified QKD-KEM abstraction that enables parallel composition of quantum and post-quantum cryptographic methods within existing protocol frameworks. Our key insight is that parallel hybrid approaches eliminate the multiplicative latency penalties inherent in sequential methods mandated by RFC 9370, achieving significant performance improvements under realistic network conditions. Performance evaluation using a Docker-based testing framework with IDQuantique QKD hardware demonstrates that the parallel hybrid approach significantly outperforms sequential methods under network latency conditions, while pure QKD achieves minimal bandwidth overhead through identifier-based key coordination. Our implementations provide practical quantum-enhanced IPsec solutions suitable for critical infrastructure deployments requiring defense-in-depth security.

Figures

Figures reproduced from arXiv: 2507.09288 by the authors.

Figure 1
Figure 1. IKEv2 handshake with QKD integration using the client-initiated approach. The diagram [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Software architecture of our QKD-IPsec integration. The diagram shows the interaction between strongSwan plugins, the QKD ETSI API C wrapper, and different QKD backends including QUBIP’s Python-based KMS for ETSI 004 and na￾tive REST clients for ETSI 014. 5.2 QKD-KEM Plugin The QKD-KEM plugin implements hybrid quantum/post-quantum security through a unified KEM interface. This approach maintains the original IKEv2 m… view at source ↗
Figure 3
Figure 3. The setup consists of two IDQuantique Cerberis XGR nodes (N_A and N_B) connected via dedicated dark fiber for the quantum channel and a separate classical channel. Both nodes con￾nect to a network switch (SW) that provides access to the Internet cloud and a gateway (GW) machine. The GW serves as the management endpoint where Docker containers (Alice and Bob) are deployed for the VPN testing environment. 6.2 Containe… view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Average time per iteration for the different proposals with different values for latency (no [PITH_FULL_IMAGE:figures/full_fig_p016_4.png]
Figure 5
Figure 5. Figure 5: Network communication time (tnet) versus plugin processing additional overhead (∆toverhead) for different cryptographic proposals under 100ms artificial network delay. Network time (green circles) captures the complete IKE hand￾shake duration from Alice’s perspective, …
Figure 6
Figure 6. Figure 6: Bytes per message type evident in [PITH_FULL_IMAGE:figures/full_fig_p017_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

64 extracted references · 61 canonical work pages

  1. [1]

    Introduction to post- quantum cryptography,

    D. J. Bernstein et al., “Introduction to post- quantum cryptography,”Post-quantum cryp- tography, vol. 1, pp. 1–10, 2009

    work page 2009

  2. [2]

    Quantum cryptography: Public key distribution and coin tossing,

    C. H. Bennett and G. Brassard, “Quantum cryptography: Public key distribution and coin tossing,” Theoretical computer science, vol. 560, pp. 7–11, 2014

    work page 2014

  3. [3]

    Quantum cryptography,

    N. Gisin, G. Ribordy, W. Tittel, and H. Zbinden, “Quantum cryptography,” Reviews of modern physics, vol. 74, no. 1, p. 145, 2002

    work page 2002

  4. [4]

    2024.doi: 10

    National Institute of Standards and Tech- nology,FIPS 203: Module-Lattice-Based Key- Encapsulation Mechanism Standard, Federal Information Processing Standards Publica- tion, Gaithersburg, MD, Aug. 2024.doi: 10. 6028 / NIST . FIPS . 203. [Online]. Available: https://doi.org/10.6028/NIST.FIPS.203

    doi:10.6028/nist.fips.203 2024

  5. [5]

    Kent and R

    S. Kent and R. Atkinson,RFC 2401: Security architecture for the Internet Protocol,Internet Requests for Comments, RFC, Nov. 1998

    work page 1998

  6. [6]

    Kent and K

    S. Kent and K. Seo, RFC 4301: Security ar- chitecture for the Internet Protocol, Internet Requests for Comments, RFC, Dec. 2005

    work page 2005

  7. [7]

    Harkins and D

    D. Harkins and D. Carrel, RFC 2409: The Internet Key Exchange (IKE), Internet Re- quests for Comments, RFC, Nov. 1998

    work page 1998

  8. [8]

    Maughan, M

    D. Maughan, M. Schertler, M. Schneider, and J. Turner,RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP), Internet Requests for Comments, RFC, Nov. 1998

    work page 1998

Show all 64 references
  1. [9]

    Kaufman, RFC 4306: Internet Key Ex- change (IKEv2) Protocol, Internet Requests for Comments, RFC, Dec

    C. Kaufman, RFC 4306: Internet Key Ex- change (IKEv2) Protocol, Internet Requests for Comments, RFC, Dec. 2005

    2005

  2. [10]

    Internet key exchange pro- tocol version 2 (ikev2),

    C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, “Internet key exchange pro- tocol version 2 (ikev2),” Internet Engineer- ing Task Force, RFC 7296, Oct. 2014, RFC 7296 (Obsoletes RFC 5996). [Online]. Avail- able: https://www.rfc- editor.org/rfc/ rfc7296.txt

    2014

  3. [11]

    Law and J

    L. Law and J. Solinas,Suite B Cryptographic Suites for IPsec, RFC 6379, Oct. 2011.doi: 10 . 17487 / RFC6379 . [Online]. Available: https : / / www . rfc - editor . org / info / rfc6379

    2011

  4. [12]

    strongSwanProject, Strongswan: Open source IPsec-based VPN solution, Version 5.9.14,

  5. [13]

    Position paper on quantum key distribution,

    French Cybersecurity Agency (ANSSI), Fed- eral Office for Information Security (BSI), Netherlands National Communications Secu- rity Agency (NLNCSA), and Swedish Na- tional Communications Security Authority, Swedish Armed Forces, “Position paper on quantum key distribution,” J...

    2024

  6. [14]

    Smyslov, Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2), RFC 9242, May 2022

    V. Smyslov, Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2), RFC 9242, May 2022. doi: 10 . 17487/RFC9242. [Online]. Available: https: //www.rfc-editor.org/info/rfc9242

    2022

  7. [15]

    Tjhai et al., Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2), RFC 9370, May 2023

    C. Tjhai et al., Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2), RFC 9370, May 2023. doi: 10 . 17487/RFC9370. [Online]. Available: https: //www.rfc-editor.org/info/rfc9370

    2023

  8. [16]

    Fluhrer, P

    S. Fluhrer, P. Kampanakis, D. McGrew, and V. Smyslov, Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security , RFC 8784, Jun. 2020. doi: 10 . 17487 / RFC8784. [Online]. Available: https : / / www . rfc - editor.org/info/rfc8784

    2020

  9. [17]

    Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CRE- ATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security,

    V. Smyslov, “Mixing Preshared Keys in the IKE_INTERMEDIATE and in the CRE- ATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security,” Internet Engineer- ing Task Force, Internet-Draft draft-ietf- ipsecme-ikev2-qr-alt-08, Apr. 2025, Work in Progress, 13 pp. [Online]. Available...

    2025

  10. [18]

    Hy- brid key exchange in tls 1.3,

    D. Stebila, S. Fluhrer, and S. Gueron, “Hy- brid key exchange in tls 1.3,” Internet Engi- neering Task Force (IETF), Network Working Group, Internet-Draft, 2025. [Online]. Avail- 20 able: https://datatracker.ietf.org/doc/ draft-ietf-tls-hybrid-design/

    2025

  11. [19]

    IKE for IPsec with QKD,

    S. Nagayama and R. V. Meter, “IKE for IPsec with QKD,” Internet Engineering Task Force, Internet-Draft draft-nagayama- ipsecme-ipsec-with-qkd-01, Oct. 2014, Work inProgress,18pp.[Online].Available: https: / / datatracker . ietf . org / doc / draft - nagayama-ipsecme-ipsec-with-qkd/01/

    2014

  12. [20]

    Etsi GS QKD 004 V2.1.1: Quantum Key Distribution (QKD); Application Inter- face,

    ETSI, “Etsi GS QKD 004 V2.1.1: Quantum Key Distribution (QKD); Application Inter- face,” European Telecommunications Stan- dards Institute, Group Specification GS QKD 004 V2.1.1, Aug. 2020

    2020

  13. [21]

    Etsi gs qkd 014 v1.1.1: Quantum key distribution (qkd); protocol and data format of rest-based key delivery api,

    ETSI, “Etsi gs qkd 014 v1.1.1: Quantum key distribution (qkd); protocol and data format of rest-based key delivery api,” Eu- ropean Telecommunications Standards Insti- tute, Technical Specification GS QKD 014 V1.1.1, 2020

    2020

  14. [22]

    Using quantum key distribu- tion within ipsec to secure man communica- tions,

    M. Sfaxi, S. Ghernaouti-Hélie, G. Ribordy, and O. Gay, “Using quantum key distribu- tion within ipsec to secure man communica- tions,” Proceedings of metropolitan area net- works (man2005), 2005

    2005

  15. [23]

    Berzanskis, H

    A. Berzanskis, H. Hakkarainen, K. Lee, and M. R. Hussain, Method of integrating QKD with IPSec, US Patent US7602919B2, US Patent Office, Oct. 2009

    2009

  16. [24]

    Darpa quantum net- work testbed,

    C. Elliott and H. Yeh, “Darpa quantum net- work testbed,” BBN Technologies Cambridge MA, Final Technical Report AFRL-IF-RS- TR-2007-180, Jul. 2007, Sponsored by De- fense Advanced Research Projects Agency, DARPA Order No. L750

    2007

  17. [25]

    Overview of quantum key distribution technique within ipsec architecture,

    E. Dervisevic and M. Mehic, “Overview of quantum key distribution technique within ipsec architecture,” arXiv preprint arXiv:2112.13105, 2021

    2021 arXiv

  18. [26]

    Quantum key distribution: A networking perspective,

    M. Mehic et al., “Quantum key distribution: A networking perspective,”ACM Computing Surveys (CSUR), vol. 53, no. 5, pp. 1–41, 2020

    2020

  19. [27]

    Manyamicklemakesamuckle:Aframe- work for provably quantum-secure hybrid key exchange,

    B. Dowling, T. B. Hansen, and K. G. Pater- son,“Manyamicklemakesamuckle:Aframe- work for provably quantum-secure hybrid key exchange,” in International Conference on Post-Quantum Cryptography, Springer, 2020, pp. 483–502

    2020

  20. [28]

    A practical hybrid quantum-safe cryptographic scheme between data centers,

    L. Huang, K. Feng, and C. Xie, “A practical hybrid quantum-safe cryptographic scheme between data centers,” in Emerging Imag- ing and Sensing Technologies for Security and Defence V; and Advanced Manufacturing Technologies for Micro-and Nanosystems in Security and Defence III,...

    2020

  21. [29]

    A proto- col for synchronizing quantum-derived keys in ipsec and its implementation,

    S. Marksteiner and O. Maurhart, “A proto- col for synchronizing quantum-derived keys in ipsec and its implementation,” in9th Int. Conf. Quantum, Nano/Bio, and Micro Tech- nologies, 2015, pp. 35–40

    2015

  22. [30]

    Alternative Approach for Mix- ing Preshared Keys in IKEv2 for Post- quantumSecurity,

    V. Smyslov, “Alternative Approach for Mix- ing Preshared Keys in IKEv2 for Post- quantumSecurity,” InternetEngineeringTask Force, Internet-Draft draft-smyslov-ipsecme- ikev2-qr-alt-06, 2023, Work in Progress, 8 pp. [Online]. Available: https://datatracker. ietf . org / doc / d...

    2023

  23. [31]

    ETSI GS QKD 002 V1.1.1: Quan- tum Key Distribution (QKD); Use Cases,

    ETSI, “ETSI GS QKD 002 V1.1.1: Quan- tum Key Distribution (QKD); Use Cases,” European Telecommunications Standards In- stitute, Group Specification GS QKD 002 V1.1.1, Jun. 2010

    2010

  24. [32]

    Applying qkd to im- prove next-generation network infrastruc- tures,

    V. Lopez, A. Pastor, D. Lopez, A. Aguado, and V. Martin, “Applying qkd to im- prove next-generation network infrastruc- tures,” in 2019 European Conference on Net- works and Communications (EuCNC), IEEE, 2019, pp. 283–288

    2019

  25. [33]

    [Online]

    Fortinet, Fortios 7.4.2 new features guide: Ipsec key retrieval with a qkd system using the etsi standardized api, Accessed: March 10, 2025, Fortinet, Inc., 2024. [Online]. Available: https : / / docs . fortinet . com / document / fortigate/7.4.2/new- features/620668/ ipsec - ...

    2025

  26. [34]

    Juniper Networks, Junos os ipsec vpn user guide: Quantum safe ipsec vpn , Accessed: March 10, 2025, Juniper Networks, Inc., Feb

    2025

  27. [35]

    Field trial of quantum- secured ipsec tunnels with chip-based qkd,

    P. Sibson et al., “Field trial of quantum- secured ipsec tunnels with chip-based qkd,” in Optical Fiber Communication Conference, Optica Publishing Group, 2024, Th3B–4

    2024

  28. [36]

    Moreno and C

    J. Moreno and C. Proctor, Implementing a quantum-secured network in a metropolitan area, AWS Quantum Technologies Blog, Ac- cessed: March 10, 2025, Mar. 2023. [Online]. Available: https : / / aws . amazon . com / blogs/quantum-computing/implementing- a - quantum - secured - ne...

    2025

  29. [37]

    100 gbps quantum-safe ipsec vpn tunnels over 46 km deployed fiber,

    O. Alia, A. Huang, H. Luo, O. Amer, M. Pistoia, and C. Lim, “100 gbps quantum-safe ipsec vpn tunnels over 46 km deployed fiber,” arXiv preprint arXiv:2405.04415, 2024

    2024 arXiv

  30. [38]

    Hybrid conventional and quantumsecurityforsoftwaredefinedandvir- tualized networks,

    A. Aguado et al., “Hybrid conventional and quantumsecurityforsoftwaredefinedandvir- tualized networks,” Journal of Optical Com- munications and Networking, vol. 9, no. 10, pp. 819–825, 2017

    2017

  31. [39]

    Integration of quantum key distribution in openssl,

    B. Rijsman, Y. Keuter, and T. Janssen, “Integration of quantum key distribution in openssl,” inPan-European Quantum Internet Hackathon, Developed at QuTech, TU Delft, Delft: RIPE Labs, Nov. 2019. [Online]. Avail- able: https://github.com/brunorijsman/ openssl-qkd

    2019

  32. [40]

    Quantum key distribution as a ser- viceanditsinjectionintotls,

    S. Kozlovičs, K. Petručen,a, D. L¯ arin,š, and J. Viksna, “Quantum key distribution as a ser- viceanditsinjectionintotls,” in International Conference on Information Security Practice and Experience, Springer, 2023, pp. 527–545

    2023

  33. [41]

    Enhancing the secu- rity of software defined networks via quan- tum key distribution and post-quantum cryp- tography,

    C. R. García, S. Rommel, J. J. V. Olmos, and I. T. Monroy, “Enhancing the secu- rity of software defined networks via quan- tum key distribution and post-quantum cryp- tography,” in International Symposium on Distributed Computing and Artificial Intelli- gence, Springer, 2023,...

    2023

  34. [42]

    Quantum- resistant tls 1.3: A hybrid solution combining classical, quantum and post-quantum cryp- tography,

    C. R. Garcia, A. C. Aguilera, J. J. V. Olmos, I. T. Monroy, and S. Rommel, “Quantum- resistant tls 1.3: A hybrid solution combining classical, quantum and post-quantum cryp- tography,” in 2023 IEEE 28th International Workshop on Computer Aided Modeling and Design of Communicat...

    2023

  35. [43]

    Integrating quantum key distribution into tls 1.3: A transport layer approach to quantum-resistant communica- tions in optical networks,

    C. R. Garcia, A. Cano, J. V. Olmos, S. Rom- mel, and I. T. Monroy, “Integrating quantum key distribution into tls 1.3: A transport layer approach to quantum-resistant communica- tions in optical networks,” in Optical Fiber Communication Conference, Optica Publish- ing Group, 2...

    2024

  36. [44]

    Hybrid qkd- based framework for secure enterprise com- munication system,

    E. Rencis, J. Viksna, S. Kozlovičs, E. Celms, D. J. L¯ arin,š, and K. Petručen,a, “Hybrid qkd- based framework for secure enterprise com- munication system,” Procedia Computer Sci- ence, vol. 239, pp. 420–428, 2024

    2024

  37. [45]

    Practical hybrid pqc-qkd protocols with enhanced security and per- formance,

    P. Zeng et al., “Practical hybrid pqc-qkd protocols with enhanced security and per- formance,” arXiv preprint arXiv:2411.01086, 2024

    2024 arXiv

  38. [46]

    Qkd-kem: Hybrid qkd inte- gration into tls with openssl providers,

    J. Blanco-Romero, P. O. García, D. Sobral- Blanco, F. A. Mendoza, A. F. Vilas, and R. P. Díaz-Redondo, “Qkd-kem: Hybrid qkd inte- gration into tls with openssl providers,”arXiv preprint arXiv:2503.07196, 2025

    2025 arXiv

  39. [47]

    An etsi gs qkd compliant tls implementation,

    T. Prévost, B. Martin, and O. Alibart, “An etsi gs qkd compliant tls implementation,” arXiv preprint arXiv:2506.19409, 2025

    2025 arXiv

  40. [48]

    Draft Recommendation ITU-T Y.QKD-TLS: Quantum Key Distribution in- tegration with Transport Layer Security 1.3,

    ITU-T, “Draft Recommendation ITU-T Y.QKD-TLS: Quantum Key Distribution in- tegration with Transport Layer Security 1.3,” International Telecommunication Union, Draft Recommendation SG13-TD412/WP3, Mar. 2024, Expected Q3 2024

    2024

  41. [49]

    Using quantum key dis- tribution for cryptographic purposes: A sur- vey,

    R. Alléaume et al., “Using quantum key dis- tribution for cryptographic purposes: A sur- vey,” Theoretical Computer Science, vol. 560, pp. 62–81, 2014

    2014

  42. [50]

    Hacking commercial quantum cryptography systems by tailored bright illumination,

    L. Lydersen, C. Wiechers, C. Wittmann, D. Elser, J. Skaar, and V. Makarov, “Hacking commercial quantum cryptography systems by tailored bright illumination,”Nature pho- tonics, vol. 4, no. 10, pp. 686–689, 2010

    2010

  43. [51]

    Simulations of denial of service attacks in quantum key distribu- tion networks,

    E. Dervisevic et al., “Simulations of denial of service attacks in quantum key distribu- tion networks,” in2022 XXVIII International Conference on Information, Communication and Automation Technologies (ICAT), IEEE, 2022, pp. 1–5

    2022

  44. [52]

    Tackling denial of service attacks on key management in software-defined quantum key distribution networks,

    M. Mehic, S. Rass, E. Dervisevic, and M. Voz- nak, “Tackling denial of service attacks on key management in software-defined quantum key distribution networks,”IEEE Access, vol. 10, pp. 110512–110520, 2022

    2022

  45. [53]

    Monitoring andphysical-layer attack mitigation in sdn-controlled quantum key dis- tribution networks,

    E. Hugues-Salas, F. Ntavou, D. Gkounis, G. T. Kanellos, R. Nejabati, and D. Sime- onidou, “Monitoring andphysical-layer attack mitigation in sdn-controlled quantum key dis- tribution networks,”Journal of Optical Com- munications and Networking, vol. 11, no. 2, A209–A218, 2019

    2019

  46. [54]

    strongSwan Project, strongSwan 6.0.0 re- lease, Accessed: March 10, 2025, Dec. 2024. [Online]. Available: https : / / github . com / strongswan/strongswan/releases/tag/6. 0.0

    2025

  47. [55]

    [Online]

    QURSA, Qkd plugins for strongswan, Plug- ins for strongSwan that integrate quantum key distribution (QKD) for key establish- ment, 2025. [Online]. Available: https : / / github . com / qursa - uc3m / qkd - plugins - strongswan. 22

    2025

  48. [56]

    Project, Qkd etsi api c wrapper, C wrap- per for different ETSI GS QKD 004/014 API clients integrating Quantum Key Distribution (QKD) systems into security protocols., 2024

    Q. Project, Qkd etsi api c wrapper, C wrap- per for different ETSI GS QKD 004/014 API clients integrating Quantum Key Distribution (QKD) systems into security protocols., 2024. [Online]. Available: https : / / github . com / qursa-uc3m/qkd-etsi-api-c-wrapper

    2024

  49. [57]

    Project, Qkd-kem provider, OpenSSL 3.0 provider implementing hybrid QKD-PQC key encapsulation, 2024

    Q. Project, Qkd-kem provider, OpenSSL 3.0 provider implementing hybrid QKD-PQC key encapsulation, 2024. [Online]. Available: https : / / github . com / qursa - uc3m / qkd - kem-provider

    2024

  50. [58]

    Project, Etsi qkd-004 implementation , Dockerized Python implementation of the ETSI GS QKD 004 API Standard with QKD link emulation, 2024

    Q. Project, Etsi qkd-004 implementation , Dockerized Python implementation of the ETSI GS QKD 004 API Standard with QKD link emulation, 2024. [Online]. Avail- able: https : / / github . com / QUBIP / etsi - qkd-004

    2024

  51. [59]

    [Online]

    QURSA, Qkd-ipsec docker testing environ- ment, Accessed: 2024-11-05, 2024. [Online]. Available: https : / / github . com / qursa - uc3m/qkd-ipsec-docker-test

    2024

  52. [60]

    [Online]

    strongX509, Docker-based strongswan test- ing environment, Accessed: 2024-11-05, 2024. [Online]. Available: https : / / github . com / strongX509/docker

    2024

  53. [61]

    Ledenev, Pumba: Chaos testing tool for docker, Chaos testing, network emulation, and stress testing tool for containers, 2024

    A. Ledenev, Pumba: Chaos testing tool for docker, Chaos testing, network emulation, and stress testing tool for containers, 2024. [Online]. Available: https : / / github . com / alexei-led/pumba

    2024

  54. [62]

    [Online]

    strongSwan Team, Strongswan documenta- tion: Strongswan.conf configuration refer- ence, Version 6.0, Accessed: December 2024, strongSwan Project, 2024. [Online]. Available: https : / / docs . strongswan . org / docs / latest/config/strongswanConf.html. 23

    2024

  55. [2024]

    Available: https : / / strongswan.org

    [Online]. Available: https : / / strongswan.org

  56. [2025]

    Available: https : / / www

    [Online]. Available: https : / / www . juniper . net / documentation / us / en / software / junos / vpn - ipsec / topics / topic - map / quantum - safe - ipsec - vpn . html

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.