An ETSI GS QKD compliant TLS implementation

Bruno Martin (I3S); Olivier Alibart (INPHYNI); Thomas Pr\'evost (I3S)

REVIEW 4 major objections 6 minor 1 cited by

An ETSI GS QKD compliant TLS implementation

T0 review · 4 major / 6 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 This paper presents a working TLS 1.3 variant that swaps the public-key exchange for quantum keys issued by an ETSI GS QKD 014-compliant manager, stays backward compatible with classic TLS, and demonstrates a quantum-encrypted video call.

desk verdict Useful, working TLS-QKD implementation with honest measurements; the advertised harvest-now-decrypt-later protection is not supported because key delivery rides on classic HTTPS. read the letter →

arxiv 2506.19409 v1 pith:DPRHPUVZ submitted 2025-06-24 cs.CR

Thomas Prévost (I3S) , Bruno Martin (I3S) , Olivier Alibart (INPHYNI) This is my paper · ORCID

classification cs.CR

keywords TLSQuantumKeyDistributionETSIGSQKD014Rustlsharvest-now-decrypt-laterbackwardcompatibilityhandshakelatencyBBM92

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

The paper claims that the TLS 1.3 handshake can be modified so that the session key comes from a quantum key distribution (QKD) network instead of an ephemeral public-key exchange. The authors replace the public-key exchange with requests to a local key-management entity (KME) that follows the ETSI GS QKD 014 standard, and they implement this in a fork of the Rustls TLS library. The resulting protocol, TLS-QKD, is backward compatible in both directions, so a quantum-enabled client can talk to a classic TLS server and vice versa. As proof of usefulness, the authors ran a 720p, 10-frames-per-second video conference between two sites 25 km apart, with handshake times averaging 38.2 ms compared with 21.5 ms for TLS 1.3 on a low-latency link. The stated purpose is to protect against harvest-now-decrypt-later attacks by ensuring the session key is distributed by quantum means.

What carries the argument

The load-bearing mechanism is the key-provisioning chain defined by ETSI GS QKD 014: a Secure Application Entity (the TLS client or server) asks its local Key Management Entity for a key to talk to a named peer, the KMEs synchronise the same key over a QKD link, and the client marks the key by UUID in a ClientHello extension. Authentication of the initiating SAE is carried by a 256-bit random token and seed encrypted with the quantum key, sent from server to client in a ServerHello extension, with the client returning the token and a changed seed in a new ChallengeAck message type. This challenge proves that the client actually holds the quantum key and is what replaces the certificate-based handshake authentication; without it the protocol would have no way to tie the key to the right peer. The custom extension codes 0xFEA6 and 0xFEA7 and the message code 0x50 are the wires on which the whole mechanism runs.

What would settle it

Record the HTTPS requests and responses by which a TLS-QKD client and server fetch keys from their KMEs and the KMEs notify each other of key use, then later break the public-key cryptography protecting those links (for example with a quantum computer); if the recorded TLS-QKD session ciphertext then decrypts, the harvest-now-decrypt-later protection the paper claims has failed. A simpler check on the same assumption is to confirm that stripping the 0xFEA6 ClientHello extension from a backward-compatible TLS-QKD client makes the session fall back to classic TLS 1.3, showing that an active network attacker can downgrade the connection.

Watch

Extended reading notes

Core claim

The paper's central claim is that cryptography based on QKD can be made practical inside TLS 1.3 by routing the handshake's key exchange through the ETSI GS QKD 014 key-delivery interface. In this design, each endpoint is a Secure Application Entity (SAE) that fetches a symmetric key from its local Key Management Entity (KME); the KMEs themselves already share keys generated by QKD, so both SAEs end up with the same 256-bit quantum key. The client advertises the key's UUID and an initialization vector in a custom ClientHello extension (0xFEA6), the server retrieves the matching key from its own KME, and a cryptographic challenge exchanged through a ServerHello extension (0xFEA7) and a new ChallengeAck message (0x50) authenticates the client's possession of the key. Once the challenge succeeds, the two parties encrypt the session with AES-AEAD using the quantum key, and the original public-key exchange and certificate-based server authentication are dropped. The authors argue that this defeats harvest-now-decrypt-later attacks because the session key is not produced by any public-key algorithm that an attacker could later break.

Load-bearing premise

The protocol assumes that the HTTPS connections used to deliver quantum keys from a KME to an SAE, and from one KME to another, cannot be decrypted by an attacker at the time the keys are exchanged; if an attacker records those HTTPS exchanges and later breaks the public-key encryption, it obtains the same quantum key and can decrypt the recorded TLS-QKD traffic.

Editorial extensions

If this is right

A TLS-QKD client can connect to a standard TLS 1.3 server, and a TLS-QKD server can accept classic TLS clients, so QKD protection can be adopted incrementally without replacing the whole infrastructure.
If the key-delivery HTTPS links are safe at the time of use, archived TLS-QKD sessions resist later decryption by an attacker who breaks RSA or ECC, which is precisely the harvest-now-decrypt-later scenario.
The protocol is usable for interactive traffic: the reported video conference at 720p and 10 fps ran without audible latency, and handshakes completed in tens of milliseconds on a 1 ms-latency link.
Operators who want strict QKD guarantees can disable TLS 1.3 backward compatibility, at the cost of giving up interoperability with classic TLS peers.

Reading between the lines

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

Because the handshake involves 29 messages across SAEs and KMEs, the latency gap versus TLS 1.3 will grow on longer-latency wide-area links; measuring the handshake over a 50 ms-latency path would quantify how much the extra round trips cost.
The fixed 256-bit key with no regeneration means long sessions accumulate ciphertext under a single quantum key; a natural extension is to trigger key rotation through the ETSI 014 API after a traffic threshold and measure the resulting handshake overhead.
The security argument depends on the two KMEs agreeing on which key a given UUID refers to; a natural interoperability test is to run the client SAE against a KME from a different vendor and check whether a mismatched UUID mapping fails the challenge instead of silently using a wrong key.

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.

Desk Editor's Note

read the letter

Short version: this is a real implementation, not vaporware. The authors forked Rustls, added two TLS extensions and a ChallengeAck message, integrated with an ETSI QKD 014 KME, made it backward compatible with plain TLS, and demonstrated a video call over 25 km of fiber. Handshake timings (38 ms mean vs 21.5 ms for TLS 1.3, 10 runs each) are plausible and the code is public. That is a useful engineering contribution for the QKD networking community.

The paper's own words in Section 3.1 are the problem: the KME-to-SAE and KME-to-KME delivery of the quantum key is done over ordinary HTTPS, and the authors write 'we assume that at the time of the exchange, the attacker is not able to break the public key encryption.' That assumption is precisely what a harvest-now-decrypt-later adversary violates: it records ciphertexts now and breaks the public key later. Once the PKC is broken, it can decrypt the HTTPS transcripts, recover the 32-byte QKD key and IV, and then decrypt the recorded TLS-QKD session. So the HNDL guarantee advertised in the introduction and conclusion does not follow from the implementation as described. The stress-test note is correct.

This is a substantive flaw in the security narrative, but not necessarily in the engineering. The protocol would still be meaningful under a weaker threat model, e.g., an adversary who cannot break PKC during the exchange and who does not record for later decryption. The paper should state that honestly. It should also include the ProVerif proof or at least specify whether the adversary model includes later PKC compromise. The proof is self-cited and not reproduced.

Other soft spots are minor in proportion: client certificate validation is dropped because the protocol supposedly authenticates the server, the downgrade vulnerability is acknowledged, and keys are never regenerated, so forward secrecy is absent if the quantum key leaks. Performance is measured with only 10 runs and no variance, but for a proof of concept that is fine.

Bottom line: for engineers working on QKD network integration, this is a valuable reference implementation with reproducible code. As a security paper, it overclaims. It deserves a serious referee, but with a request for major revision: fix the HNDL claim, state the actual threat model, and either ship the proof or clearly bound its assumptions.

Referee Report

4 major / 6 minor

Summary. The paper presents TLS-QKD, a modification of the TLS 1.3 protocol implemented in the Rustls library. The TLS handshake's public-key key exchange is replaced by a request to an ETSI GS QKD 014 KME: the client obtains a 256-bit key from its local KME, sends a key identifier and IV in a new ClientHello extension, the server retrieves the same key from its local KME, and a challenge-response message (ChallengeAck) authenticates the client. The authors report a successful video conference over a 25 km link and compare handshake times (TLS-QKD mean 38.2 ms vs TLS 1.3 mean 21.5 ms over 10 runs). They claim backward compatibility with classic TLS in both directions and state that the protocol addresses harvest-now-decrypt-later attacks.

Significance. If the security claims were fully established, the paper would be a useful practical integration of QKD into TLS, with credible engineering details and reproducible code. The authors provide links to the KME server, the modified Rustls library, the video-conferencing client, and the benchmark code, and they are transparent about arbitrary protocol constants and acknowledged limitations such as the lack of key regeneration and the downgrade risk. The main value of the paper is therefore as an engineering demonstration and performance study. The advertised harvest-now-decrypt-later guarantee is not demonstrated under the stated assumptions, the security argument depends on a self-cited ProVerif proof that is not included or mapped to the modified TLS handshake, and the forward-secrecy claim is contradicted by the implementation's own admission that it does not regenerate keys.

major comments (4)

[§3.1 and §5] The claim that the protocol 'offers a solution against harvest now-decrypt later attacks' is not supported by the described design. The QKD key is delivered from the KME to the SAE over HTTPS, and the KME-to-KME notification is also sent over HTTPS. Section 3.1 states only that 'at the time of the exchange, the attacker is not able to break the public key encryption.' A harvest-now-decrypt-later adversary records ciphertext during the exchange and breaks the public-key cryptography later; if such an adversary can observe the key-delivery HTTPS traffic, it can recover the same QKD key and decrypt recorded TLS-QKD sessions. The paper must either specify a threat model in which the attacker cannot observe the secure-zone key-delivery channels or weaken the conclusion in Section 5.
[§3.2.7 and §5] The security assertion rests on the ProVerif verification in Prévost et al. (2024), but that proof is not reproduced or summarized in this paper, and it was reportedly for the ETSI QKD 014 protocol rather than for the specific TLS 1.3 modifications made here, including the removal of certificate verification and the Finished message, the new extensions, and the ChallengeAck message. The authors should include the formal model or provide a precise statement of its assumptions and explain how they map to the modified TLS handshake before claiming that authentication is 'as proven by ProVerif.'
[§3.2.8 and §4] The implementation never regenerates the symmetric key, and Section 4 acknowledges that 'the property of forward secrecy is in fact not assured if an attacker were to discover the quantum key.' This directly contradicts the introduction's statement that QKD 'enables theoretically perfect forward secrecy' in the context of this protocol. The forward-secrecy claim should be removed or reframed as a property of QKD key generation generally, not of a TLS-QKD session that reuses a key without regeneration.
[§3.4] The handshake timing comparison is based on only 10 runs per condition with no statistical characterization. The reported averages (38.2 ms for TLS-QKD, 21.5 ms for TLS 1.3) are plausible, but the paper does not report variance, confidence intervals, or the measurement methodology beyond stating that the two sites are connected by a low-latency fiber link. The quantitative claim that the TLS-QKD handshake is 'significantly longer' needs additional data or statistical support.

minor comments (6)

[§2] There is a typo in 'Two types of actors interact in the this protocol'; 'the' should be removed.
[Figure 1 caption] The caption says KME 1 'communicates the key enciphered within a TLS response to the remote KME,' which is ambiguous. It should clarify whether the key material itself or only a key identifier and SAE association are sent between KMEs over HTTPS, as this is directly relevant to the harvest-now-decrypt-later analysis.
[§3.1] The UUID of keys is generated from their SHA-1 fingerprint. Even though the UUID is not a secret, using SHA-1 for identifiers should be justified or replaced with a stronger hash to avoid unnecessary scrutiny.
[§3.2.4] The IV is sent in cleartext in the ClientHello extension. If the same QKD key is used for multiple sessions, the protocol should specify how IV uniqueness is guaranteed; the current text does not discuss this.
[§3.4] The statement that a total of 29 messages is exchanged during the handshake would benefit from a message-flow diagram or a list showing how the count was obtained, since the handshake in Figure 3 appears to have fewer displayed messages.
[References] The reference to Prévost et al. (2024) is published in 'GTMFS,' which is not expanded or identified; the authors should provide the full venue or a DOI to make the self-citation verifiable.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: measured performance and arbitrary protocol constants are self-contained; the self-cited ProVerif verification is formal evidence, and the HTTPS key-delivery assumption is a threat-model gap rather than a circular reduction.

full rationale

This paper contains no fitted-parameter-then-prediction structure: the handshake delays are reported measurements (Section 3.4), and the protocol constants (0x0E00, 0xFEA6, 0xFEA7, 0x50) are explicitly arbitrary design choices rather than values derived from the security or performance claims. The main self-citation is Prévost et al. (2024), used in Sections 2 and 3.2.7 to justify dropping the TLS certificate check in favor of QKD-based authentication; this is a formal ProVerif verification by the same authors, and relying on such a verified result is normal academic practice rather than a circular reduction. The Section 3.1 assumption that the attacker cannot break public-key encryption “at the time of the exchange” does create a serious threat-model gap for the “harvest now, decrypt later” claim, because that adversary records now and breaks PKC later; however, that is a correctness and security weakness, not a circular derivation in which the conclusion is equal to an input by construction. Accordingly, no circular step is identified.

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

The ledger is bounded: the system is an engineering contribution whose security still depends on classical PKC during key delivery, on trusted KMEs, on the standard QKD assumptions, and on the correctness and fidelity of the authors' prior ProVerif model. The only hand-chosen numerical parameters are protocol constants and key sizes; the performance results are measurements, not fitted outputs.

free parameters (3)

Quantum key size = 256 bits
Hardcoded key size in the implementation, chosen as a quantum-safe standard per Section 3.2.8.
Challenge token and seed sizes = 256 bits each
The cryptographic challenge in ServerHello uses 256-bit random token and seed, a design choice not derived from analysis.
Protocol constants = version 0x0E00, extensions 0xFEA6 and 0xFEA7, message type 0x50
Arbitrarily chosen identifiers for the new TLS version, extensions, and ChallengeAck message (Sections 3.2.2, 3.2.4, 3.2.6, 3.2.7). They do not affect security but are ad hoc choices.

assumptions (5)

domain assumption Public key cryptography used in HTTPS connections between SAE and KME and between KMEs is secure at the time of the key exchange.
Section 3.1 states 'we assume that at the time of the exchange, the attacker is not able to break the public key encryption.' This is load-bearing for harvest-now-decrypt-later protection.
domain assumption KMEs are trusted entities within secure zones and their bilateral X.509 authentication is sound.
The ETSI standard's trust model (Section 2) places KMEs inside secure zones; the SAE-KME and KME-KME connections use HTTPS with certificates.
domain assumption The underlying QKD protocol (BBM92) and privacy amplification produce a uniformly random, secret key.
Section 3.1 invokes BBM92 and privacy amplification as standard QKD results; the paper does not analyze device imperfections.
ad hoc to paper The ProVerif formal verification in Prévost et al. (2024) is correct and applies to this implementation.
The security claims in Sections 3.2.7 and 3.2.8 rely on this cited proof, but the model details are not included here.
domain assumption The cryptographic challenge-response (token/seed) is sufficient for mutual authentication under the trust model.
Sections 3.2.6-3.2.7 replace TLS certificate validation with the QKD-based challenge; the paper argues this is proven but does not provide independent evidence.

how reviews work

0 comments

Cite this review

Pith. "Pith review of An ETSI GS QKD compliant TLS implementation." pith.science (2026). https://pith.science/paper/DPRHPUVZ

@misc{pith2026250619409,
  author       = {Pith},
  title        = {Pith review of: An ETSI GS QKD compliant TLS implementation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DPRHPUVZ}},
  note         = {Machine review of arXiv:2506.19409}
}

read the original abstract

A modification of the TLS protocol is presented, using our implementation of the Quantum Key Distribution (QKD) standard ETSI GS QKD 014 v1.1.1. We rely on the Rustls library for this. The TLS protocol is modified while maintaining backward compatibility on the client and server side. We thus wish to participate in the effort to generalize the use of QKD on the Internet. We used our protocol for a video conference call encrypted by QKD. Finally, we analyze the performance of our protocol, comparing the time needed to establish a handshake to that of TLS 1.3.

Figures

Figures reproduced from arXiv: 2506.19409 by the authors.

**Figure 2.** Flow of a key exchange using the verified imple [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

**Figure 3.** Handshake on TLS-QKD camera and the audio from the microphone. To make a videoconference call, it is therefore needed to first launch the server on both machines, then the client. Code is available at: https://github.com/thomasarmel/ qkd camera streaming client/. During our tests between the INRIA center, in Sophia Antipolis (France) and the InPhyNi site, in Nice (France) at 25km distance, we managed to set up a vid… view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Hybrid Quantum Security for IPsec
cs.CR 2025-07 conditional novelty 5.0 of 10

Parallel hybrid QKD-PQC key exchange for IKEv2 avoids extra round trips and outperforms the sequential RFC 9370 approach under high network latency.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages · cited by 1 Pith paper

[1]

and Wood, C

Benjamin, D. and Wood, C. (2022). RFC 9258: Importing external pre-shared keys ( PSKs ) for TLS 1.3

work page 2022
[2]

Bennett, C., Bessette, F., Brassard, G., Salvail, L., and Smolin, J. (1992a). Experimental quantum cryptography. Journal of cryptology

work page 1992
[3]

Bennett, C., Brassard, G., and Mermin, N. (1992b). Quantum cryptography without B ell’s theorem. Physical review letters

work page 1992
[4]

and Ramkumar, K

Bhatia, V. and Ramkumar, K. (2020). An efficient quantum computing technique for cracking RSA using Shor’s algorithm. In 2020 IEEE 5th international conference on computing communication and automation (ICCCA) . IEEE

work page 2020
[5]

Quantum-Safe integration of TLS in SDN networks

Buruaga, J. S., M \'e ndez, R. B., Brito, J. P., and Martin, V. (2025). Quantum-safe integration of TLS in SDN networks. arXiv preprint arXiv:2502.17202

work page Pith review arXiv 2025
[6]

Dervisevic, E., Fehri \'c , M., Pivac, D., Fazio, P., Voznak, M., and Mehic, M. (2024). Simulations of selected quantum key distribution network use-cases. In 2024 International Conference on Quantum Communications, Networking, and Computing (QCNC) . IEEE

work page 2024
[7]

ETSI, G. (2019). 014. Quantum Key Distribution ( QKD ); protocol and data format of REST-based key delivery API

work page 2019
[8]

Housley, R., Hoyland, J., Sethi, M., and Wood, C. (2022). RFC 9257: Guidance for external pre-shared key ( PSK ) usage in TLS

work page 2022

Show all 21 references

[9]

Huang, A., Navarrete, \'A ., Sun, S., Chaiwongkhot, P., Curty, M., and Makarov, V. (2019). Laser-seeding attack in quantum key distribution. Physical Review Applied

2019
[10]

o wis, F., Grangier, P., H \

Huttner, B., All \'e aume, R., Diamanti, E., Fr \"o wis, F., Grangier, P., H \"u bel, H., Martin, V., Poppe, A., Slater, J. A., Spiller, T., et al. (2022). Long-range QKD without trusted nodes is not possible with current technology. npj Quantum Information

2022
[11]

Kaluderovic, N. (2022). Attacks on some post-quantum cryptographic protocols: The case of the Legendre PRF and SIKE . Technical report, EPFL

2022
[12]

Liu, C., Che, X., Xie, J., and Dong, Y. (2024). A multi-path QKD algorithm with multiple segments. Journal of Cyber Security and Mobility

2024
[13]

P., Ort \' z, L., Mendez, R., Buruaga, J., Vicente, R., Sebastian-Lombrana, A., Rincon, D., Perez, F., Sanchez, C., et al

Martin, V., Brito, J. P., Ort \' z, L., Mendez, R., Buruaga, J., Vicente, R., Sebastian-Lombrana, A., Rincon, D., Perez, F., Sanchez, C., et al. (2024a). Madqci: a heterogeneous and scalable SDN-QKD network deployed in production facilities. npj Quantum Information

2024
[14]

Martin, V., Peev, M., Brito, J., Ort \' z, L., Brito-M \'e ndez, R., Vicente, R., Saez-Buruaga, J., Sebastian-Lombra \ n a, A., Garc \' a-Cid, M., Faba, J., et al. (2024b). Towards large scale QKD networks. In 2024 24th International Conference on Transparent Optical Networks ...

2024
[15]

Paul, S. (2022). On the transition to post-quantum cryptography in the industrial Internet of things

2022
[16]

Prévost, T., Martin, B., and Alibart, O. (2024). Formal verification of the ETSI proposal on a standard QKD protocol. GTMFS

2024
[17]

Prévost, T., Martin, B., and Alibart, O. (2025). A secret key spreading protocol for extending ETSI quantum key distribution. In Proceedings of the 11th International Conference on Information Systems Security and Privacy - Volume 2: ICISSP . INSTICC, SciTePress

2025
[18]

Rescorla, E. (2018). The transport layer security ( TLS ) protocol version 1.3. Technical report

2018
[19]

Tankovic, A., Burdiak, P., Dervisevic, E., Voznak, M., Mehic, M., and Kaljic, E. (2024a). Performance analysis of ETSI GS QKD 014 protocol in 5G/6G networks. In Future of Information and Communication Conference . Springer

2024
[20]

Tankovic, A., Dervisevic, E., Voznak, M., Mehic, M., and Kaljic, E. (2024b). Performance analysis of ETSI GS QKD 014 protocol in multi-user environment. In 2024 23rd International Symposium INFOTEH-JAHORINA (INFOTEH) . IEEE

2024
[21]

Zygelman, B. (2018). No-cloning theorem, quantum teleportation and spooky correlations. A First Introduction to Quantum Computing and Information

2018

Pith tools

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

[1] [1]

and Wood, C

Benjamin, D. and Wood, C. (2022). RFC 9258: Importing external pre-shared keys ( PSKs ) for TLS 1.3

work page 2022

[2] [2]

Bennett, C., Bessette, F., Brassard, G., Salvail, L., and Smolin, J. (1992a). Experimental quantum cryptography. Journal of cryptology

work page 1992

[3] [3]

Bennett, C., Brassard, G., and Mermin, N. (1992b). Quantum cryptography without B ell’s theorem. Physical review letters

work page 1992

[4] [4]

and Ramkumar, K

Bhatia, V. and Ramkumar, K. (2020). An efficient quantum computing technique for cracking RSA using Shor’s algorithm. In 2020 IEEE 5th international conference on computing communication and automation (ICCCA) . IEEE

work page 2020

[5] [5]

Quantum-Safe integration of TLS in SDN networks

Buruaga, J. S., M \'e ndez, R. B., Brito, J. P., and Martin, V. (2025). Quantum-safe integration of TLS in SDN networks. arXiv preprint arXiv:2502.17202

work page Pith review arXiv 2025

[6] [6]

Dervisevic, E., Fehri \'c , M., Pivac, D., Fazio, P., Voznak, M., and Mehic, M. (2024). Simulations of selected quantum key distribution network use-cases. In 2024 International Conference on Quantum Communications, Networking, and Computing (QCNC) . IEEE

work page 2024

[7] [7]

ETSI, G. (2019). 014. Quantum Key Distribution ( QKD ); protocol and data format of REST-based key delivery API

work page 2019

[8] [8]

Housley, R., Hoyland, J., Sethi, M., and Wood, C. (2022). RFC 9257: Guidance for external pre-shared key ( PSK ) usage in TLS

work page 2022