{"id":"8d97aed1-d93c-47d3-baf7-6e2bd299551a","arxiv_id":"2505.13158","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A simulation study finds that onion-routing key relay in QKD networks adds modest overhead to key distribution, while the authenticated variant is significantly slower.","lead":"This paper simulates a quantum key distribution network that relays keys through intermediate nodes using onion routing with post-quantum encryption, and compares its speed with standard key-relay and trusted-node designs. The basic scheme adds only modest delay while improving confidentiality, but adding end-to-end authentication makes it much slower.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Basic ORR lacks end-to-end authentication, so a malicious intermediate can substitute the relayed key; the 'unconditionally secure' claim is false because the construction uses computational PQC and AES.","rationale":"I read the paper as a performance evaluation of an onion-routing key relay with PQC layers. The timing measurements are plausible: the code is public, the trends match expectations, and the ORR-Ext overhead is consistent with larger ciphertexts. The main problem is that the paper packages this evaluation with a security claim that is both overbroad and internally inconsistent. The 'unconditionally secure' phrasing contradicts the paper's own background section, and the basic ORR design lacks the authentication that would be needed for end-to-end integrity against active malicious nodes. This is not a disagreement with community consensus; it is a mismatch between the claim and the protocol as described. A conditional acceptance is appropriate: require the authors to (1) replace 'unconditionally' with a computational-security claim qualified by the PQC assumptions, (2) specify an adversary model (passive vs active, node corruption, collusion), and (3) either add an end-to-end authentication mechanism to basic ORR or restrict the security claim to confidentiality and anonymity under passive/honest-but-curious intermediate nodes. The concrete test above would settle whether the active-substitution attack lands; the static analysis of Table 2 already points to the answer.","tokens_in":5833,"tokens_out":7795,"duration_ms":79821,"concrete_test":"Extend the provided C simulator with one malicious intermediate node M in a 5-node basic-ORR circuit. Let M, after receiving the onion, create a fresh onion containing an attacker-chosen key K' encapsulated under the public keys of the remaining nodes and forward that onion. Record whether the destination outputs K' and whether any receiver-side check rejects it. Run the unmodified protocol as a control. If K' is accepted, the end-to-end integrity/authenticity claim for basic ORR is falsified. As a static check, search the basic-ORR code path for any keyed MAC or signature verification at the destination; Table 2 already indicates none, but the code should confirm.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central security claim in Section 4 ('guarantees unconditionally secure key distribution within QKDN', 'ensures end-to-end security') is not supported by the described construction and is partly contradicted by the paper's own design. First, the scheme uses Kyber-768 PQC-KEM and AES-256-CBC (Table 1); these are computationally secure under hardness assumptions, so the word 'unconditionally' is incorrect. Second, the basic ORR variant evaluated in Section 6 has no end-to-end authentication mechanism. The authors separate ORR-Ext from ORR precisely because ORR-Ext adds 'end-to-end authentication' (Section 5), and Table 2 reports zero bytes of signature/MAC material for ORR. Without any binding tag from the initiator, an active malicious intermediate node can decrypt its layer, discard the inner onion, and construct a fresh onion that encapsulates an attacker-chosen key K' under the public keys of the remaining nodes. Because neither the destination nor the initiator verifies an end-to-end integrity/authenticity tag, the destination will accept K' as the distributed key. This is a man-in-the-middle key-substitution attack, not merely loss of anonymity, and it invalidates the claimed CIA guarantee for the basic model. The performance comparison may remain useful, but the headline security property it is meant to demonstrate is absent or at best unproven in this paper.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper describes and evaluates Onion Routing Relay (ORR), a key-relay protocol for QKD networks that wraps a QKD-generated secret in layered PQC-KEM and symmetric encryption along a path, and compares its simulated performance (encryption time and key-distribution time for circuits of 3 to 11 nodes) with key-relay (KR) and trusted-node (TN) models. It also evaluates an extension, ORR-Ext, that adds end-to-end authentication via HMAC or PQC signatures. The central assertion is that ORR improves confidentiality, integrity, authenticity, and anonymity over KR/TN while retaining competitive key-distribution latency, and that ORR 'guarantees unconditionally secure key distribution within QKDN'. The experiments use a localhost threaded simulation in C, with one pair of real Cerberis QKD nodes supplying key material through a RESTful API. The paper concludes that basic ORR is a feasible compromise between efficiency and security, whereas ORR-Ext is expensive and suitable only for high-security applications.","tokens_in":6079,"tokens_out":5252,"duration_ms":50715,"significance":"If the security claims were supported, ORR would be a practical way to protect relayed QKD keys from malicious intermediate nodes at modest latency cost, and the open-source implementation plus the explicit comparative timing would be a useful resource for the QKD networking community. The manuscript has concrete strengths: it ships a public GitHub repository, reports a clear parameter table, and provides reproducible measurement scripts. However, the headline security claims are not supported by the described construction. The protocol uses computationally secure primitives (Kyber-768, AES-256-CBC) while claiming unconditional security, and the basic ORR variant has no end-to-end authentication, leaving it open to an active key-substitution attack by an intermediate node. The performance measurements may still be a valid contribution if the claims are re-scoped to a well-defined threat model, but the security claims as written are not defensible.","major_comments":[{"comment":"The claim that ORR 'guarantees unconditionally secure key distribution within QKDN' is contradicted by the paper's own implementation choices in Table 1 (Kyber-768 PQC-KEM, AES-256-CBC) and by Section 3, which correctly defines PQC as providing computational security against quantum attacks. A protocol built on PQC-KEM and AES cannot provide unconditional security; at best it offers computational security under the hardness assumptions of Kyber and the security of AES. This is a load-bearing error because the abstract and introduction sell the protocol on this guarantee.","section":"Section 4 and Abstract"},{"comment":"The basic ORR variant has no end-to-end authentication. Table 2 reports zero bytes for both the Signature and MAC columns for ORR, and the text separates ORR-Ext precisely because it adds end-to-end authentication. Without an end-to-end integrity tag, an active malicious intermediate node can decrypt its onion layer, discard the inner payload, and construct a fresh onion that encapsulates an adversary-chosen key K' under the public keys of the remaining nodes; the destination will accept K' because nothing binds the inner payload to the initiator. This key-substitution attack invalidates the claimed end-to-end confidentiality, integrity, and authenticity for basic ORR, and it is not merely an anonymity loss. The authors must either add and evaluate an authentication mechanism in the basic model or explicitly restrict the security claims to a threat model that excludes active intermediate adversaries.","section":"Section 5 and Table 2"},{"comment":"HMAC-256 is repeatedly called a 'signature scheme' (e.g., 'the HMAC-256 algorithm was employed as signature scheme'), but HMAC is a keyed message-authentication code, not a digital signature, and cannot provide public-key authenticity or non-repudiation. More importantly, the manuscript does not specify how the HMAC key is established end-to-end between initiator and destination in a way that is unknown to the intermediate nodes. Without this key-management step, the authentication extension is underspecified and its security cannot be evaluated.","section":"Section 5, ORR-Ext description"},{"comment":"No adversary model is ever defined. The paper claims CIA principles and anonymity but does not state what an adversary can do (passive or active, which nodes are corrupt, whether the adversary is quantum or classical, whether the QKD backbone itself is trusted). Consequently, phrases like 'guarantees unconditionally secure key distribution,' 'ensures end-to-end security,' and 'enhanced protection against malicious intermediaries' are not checkable. This is not merely a presentation issue: Section 6 measures only time, not security, so the conclusions in Section 7 overstate what the experiments can support.","section":"Section 4 and Section 6"}],"minor_comments":[{"comment":"The phrase 'The ORR model is detailed described in our previous work' is ungrammatical and should read 'is described in detail'; the same section also contains the typo 'key-managment-system' in Section 5.","section":"Section 4"},{"comment":"The column header 'Signature' is misleading for the HMAC row; HMAC output is a message-authentication tag, not a signature. The table would benefit from a separate 'MAC' column or clearer terminology, especially since the text itself uses 'signature scheme' for HMAC.","section":"Table 2"},{"comment":"The results are averages of 100 iterations, but no confidence intervals, standard deviations, or quartiles are reported in Figure 2 or the text. Given that the key-distribution times for ORR-Ext span from 465.8 to 6571.89 microseconds, error bars would materially help the reader assess the stability of the comparison.","section":"Section 6 and Figure 2"},{"comment":"The conclusion that ORR and ORR-Ext 'strengthen the security of key relaying in QKD networks at the cost of some extra bandwidth only' is contradicted by the paper's own Section 6 data, which show ORR-Ext encryption time more than 1800 times higher than KR at 11 nodes. The overhead is computational as well as bandwidth-related, and this should be acknowledged.","section":"Section 7"},{"comment":"The protocol details are delegated to the authors' own preprint [9], but the security-critical aspects (onion construction, key encapsulation sequence, and any per-hop authentication) should be summarized in the present paper so that the security claims are self-contained and reviewable.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The core problem is that the security claims outrun the construction: basic ORR is not actively secure, and the protocol is not unconditionally secure. If the authors are willing to re-scope the paper to a performance comparison of onion-style relaying under an explicit passive-adversary model, and to present ORR-Ext as the variant providing active end-to-end security, the evaluation could be a useful contribution. I also note that much of the protocol description is deferred to the authors' own preprint [9]; for a standalone security claim, the current manuscript needs either a full protocol specification or a substantial summary of the relevant details."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nPunchline: this is a performance comparison paper, not a security paper. The measurement work is legitimate and the numbers are probably useful to people building QKD relays. But the paper overclaims: Section 4 states that ORR 'guarantees unconditionally secure key distribution' and 'ensures end-to-end security.' Neither is true for the basic ORR variant that the evaluation actually tests.\n\nWhat's new: the paper reports simulated encryption and key distribution times for KR, TN, ORR, and ORR-Ext circuits of 3 to 11 nodes. The code is on GitHub, the algorithms are listed, and the experimental setup is concrete. The headline result — basic ORR adds a manageable overhead relative to KR while ORR-Ext becomes expensive — is plausible and internally consistent. That is a real contribution, and the authors deserve credit for shipping the code and for separating the basic and authenticated variants in the evaluation.\n\nSoft spots, in order. First, the central security claim is not proven and is contradicted by the design. Basic ORR has no end-to-end authentication: Table 2 shows zero bytes of MAC/signature material for ORR, and Section 5 explicitly treats ORR-Ext as the variant that adds 'end-to-end authentication.' Without a binding tag from the initiator, an active malicious intermediate can peel its layer and re-wrap an attacker-chosen key. The destination cannot detect the substitution. That is a serious vulnerability for the CIA guarantee, not a minor technicality. Second, 'unconditionally secure' is wrong when the layers are Kyber-768 and AES-256 — those are computational. Third, the HMAC-labeled-as-signature and the unexplained ciphertext lengths are minor but show the implementation section was not scrubbed carefully. Fourth, error bars are missing; 100 iterations without variance is hard to interpret, though the gap between ORR-Ext and the others is large enough that this is a minor concern.\n\nCitation pattern is fine: the protocol comes from their earlier work [9] and they say so. The attack I described is a key-substitution, not an anonymity failure, and it applies to the basic model they promote.\n\nWho this is for: researchers working on QKD network relays who want benchmark numbers for onion-routing overhead. They should not cite this paper for the security guarantee. An editor should send this to peer review, because the performance study is solid and the security overreach needs to be corrected in revision.","headline":"A useful, reproducible performance comparison of onion-routing key relay for QKD, but the security claims in Section 4 are unsupported and internally contradicted by the paper's own basic-vs-authenticated split.","tokens_in":6608,"tokens_out":2783,"would_cite":false,"duration_ms":25739,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes onion-routed QKD relay so that intermediate nodes never see the relayed key, at a modest delay cost.","keywords":["quantum key distribution","QKD networks","onion routing","post-quantum cryptography","key relay","trusted nodes","end-to-end security","quality of service"],"falsifier":"Set up a three-node ORR circuit in which the middle node is adversarial: give it the private key that opens the next node's encryption layer, or let it replace its own public key during path setup, then check whether it recovers the relayed secret $S$ or modifies the onion without the receiver detecting it. A successful peel or undetected modification would falsify the paper's end-to-end security claim.","tokens_in":5622,"feed_emoji":"🔐","tokens_out":8118,"duration_ms":76776,"temperature":0.7,"pith_summary":"The paper evaluates Onion Routing Relay (ORR), a way to distribute quantum keys across a QKD network that wraps the relayed secret in successive layers of post-quantum encryption, one layer per intermediate node. In standard key-relay and trusted-node models every hop sees the secret or must be trusted; ORR's layering is meant to let each node peel one layer and learn only the next hop, so no intermediate node learns or tampers with the end-to-end key. Simulated circuits of 3 to 11 nodes show that basic ORR stays competitive with key relay: at 11 nodes its key distribution time is about 117 microseconds above the fastest scheme, while the trusted-node model climbs well above it. Adding an end-to-end authentication extension (ORR-Ext) multiplies the time cost dramatically, so the paper positions ORR as the practical security upgrade and ORR-Ext for applications where security outranks responsiveness. The value, if the paper is right, is a middle path between today's trusted-node QKDN and fully quantum-secure end-to-end key distribution.","feed_headline":"Hide QKD relay keys from intermediate nodes with onion routing","feed_subtitle":"Basic onion-routing relay stays within ~117 µs of the fastest scheme on 3-to-11-node circuits.","key_machinery":"The load-bearing object is the onion ciphertext: a layered message in which each layer is encrypted for one node in the relay path using a post-quantum Key Encapsulation Mechanism, with the innermost secret protected by symmetric encryption. Each intermediate node owns a KEM key pair, peels exactly its layer, learns only the address of the next hop, and forwards the smaller onion; the destination finally unwraps the secret $S$. The optional ORR-Ext variant appends an end-to-end authentication tag so the receiver can verify that no hop modified the onion. The argument's quantitative core is the measured scaling of this peeling process: encryption time in ORR grows only from 33.4 to 47.25 microseconds as circuits grow from 3 to 11 nodes, whereas ORR-Ext grows from 238.78 to 5327.31 microseconds because authentication operations accumulate at every layer.","core_discovery":"ORR keeps the key-relay architecture of QKD networks but changes what each intermediate node can see. The initiator generates a secret $S$, wraps it in layers using PQC-KEM encapsulation keys for each node along the path, and applies symmetric encryption (AES-256) on the innermost payload; each hop unwraps its own layer and forwards the rest, so the whole path never exposes $S$ in the clear. The paper asserts this guarantees unconditionally secure key distribution and preserves confidentiality, integrity, authenticity, and destination anonymity against malicious intermediate nodes. Benchmarking a C simulation against real QKD hardware-driven key requests, the paper measures average key distribution times: KR starts at 167.7 microseconds (3 nodes) and reaches 272.31 microseconds (11 nodes); TN goes from 224.24 to 862.55 microseconds; ORR goes from 227.62 to 389.02 microseconds; ORR-Ext goes from 465.8 to 6571.89 microseconds. From these numbers the paper concludes that basic ORR gives a meaningful security upgrade without breaking quality of service, while ORR-Ext's end-to-end authentication carries a latency cost that limits it to high-security settings.","pith_inferences":["The paper's phrasing 'guarantees unconditionally secure' goes beyond what its measurements can show; the security claim would need a formal adversary model proving that onion layers cannot be peeled or forged by a malicious insider, which the paper does not provide.","A natural next experiment is to make one simulated intermediate node actively malicious, substituting its own KEM key during circuit setup or replaying or splicing onions, and measure how often it can recover or alter $S$; the current benchmarks assume honest-but-curious nodes.","The anonymity property could be reused beyond key relay: because each node learns only the next hop, ORR could hide the final destination of a key from all earlier routers, which standard KR/TN key management does not offer.","If end-to-end authentication is needed at scale, the largest lever is reducing per-layer signature overhead, for instance one aggregate signature for the whole circuit instead of a signature in every layer, since the measurements show ORR-Ext's cost growing superlinearly with circuit length."],"forward_implications":["Basic ORR can be dropped into a key-relay QKDN without redesigning the network: only the initiator and per-hop nodes need PQC-KEM layer handling, and the measured delay penalty stays under roughly 120 microseconds at 11-node circuits.","Trusted-node networks that want to shed the all-or-nothing trust assumption can adopt ORR without the latency blowup of ORR-Ext; at 11 nodes ORR (389.02 microseconds) actually distributes keys faster than TN (862.55 microseconds).","ORR-Ext is viable only where key requests are infrequent or latency-tolerant; its 3-node cost already exceeds ORR's 11-node cost, and at 11 nodes it is about 17 times slower than ORR.","Using PQC signature schemes inside each onion layer for end-to-end authentication makes ciphertexts grow to tens of kilobytes, so bandwidth, not just CPU, limits ORR-Ext.","If ORR's security assumption holds, QKDN operators can offer end-to-end key confidentiality and destination anonymity without trusting every intermediate node, addressing a known vulnerability of current KR/TN models."],"supporting_citations":[{"why":"Defines the ORR protocol being evaluated; this paper benchmarks that earlier scheme.","marker":"[9]"},{"why":"Supplies the layered onion-encryption mechanism that ORR adapts to relayed QKD keys.","marker":"[10]"},{"why":"Describes the key-relay model that ORR extends and uses as its fastest baseline.","marker":"[7]"},{"why":"Defines the trusted-node key-management model used as the second baseline.","marker":"[8]"},{"why":"Identifies the least-trusted-node vulnerability that motivates protecting keys from intermediate nodes.","marker":"[12]"},{"why":"Provides the end-to-end integrity extension that ORR-Ext adds to onion routing.","marker":"[22]"},{"why":"Supplies the real QKD node pair that generates the keys driving the simulations.","marker":"[23]"},{"why":"Specifies the REST key-delivery API used to retrieve keys in the simulated network.","marker":"[24]"}],"fun_headline_variants":["Onion-wrapped QKD keys keep relay nodes blind","Quantum key relay gets onion-layer secrecy with modest overhead","Hide QKD keys from intermediate nodes with onion routing","Onion routing for QKD: end-to-end key secrecy, competitive speed"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire security benefit rests on the assumption that an intermediate node cannot peel or forge an onion layer and cannot substitute itself during circuit setup; the paper invokes this assumption without giving a threat model or proof.","fun_headline_variants_meta":{"raw":{"variants":["Onion-wrapped QKD keys keep relay nodes blind","Quantum key relay gets onion-layer secrecy with modest overhead","Hide QKD keys from intermediate nodes with onion routing","Onion routing for QKD: end-to-end key secrecy, competitive speed"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000852,"raw_usage":{"total_tokens":3736,"prompt_tokens":1013,"completion_tokens":2723,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":629,"completion_tokens_details":{"reasoning_tokens":2654}},"tokens_in":629,"tokens_out":2723,"duration_ms":20920,"temperature":1.0,"reasoning_tokens":2654,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T20:18:02.492001+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Set up a three-node ORR circuit in which the middle node is adversarial: give it the private key that opens the next node's encryption layer, or let it replace its own public key during path setup, then check whether it recovers the relayed secret $S$ or modifies the onion without the receiver detecting it. A successful peel or undetected modification would falsify the paper's end-to-end security claim.","supporting_citations":[{"cited_title":"Hacking the least trusted node: Indirect eavesdropping in quantum networks,","cited_arxiv_id":null,"evidence_quote":"Identifies the least-trusted-node vulnerability that motivates protecting keys from intermediate nodes."},{"cited_title":"Onion Routing Key Distribution for QKDN","cited_arxiv_id":"2502.06657","evidence_quote":"Defines the ORR protocol being evaluated; this paper benchmarks that earlier scheme."},{"cited_title":"Onion routing,","cited_arxiv_id":null,"evidence_quote":"Supplies the layered onion-encryption mechanism that ORR adapts to relayed QKD keys."},{"cited_title":"Building the quantum network,","cited_arxiv_id":null,"evidence_quote":"Describes the key-relay model that ORR extends and uses as its fastest baseline."},{"cited_title":"Quantum key distribution networks – Key management,","cited_arxiv_id":null,"evidence_quote":"Defines the trusted-node key-management model used as the second baseline."},{"cited_title":"Cerberis XGR QKD System,","cited_arxiv_id":null,"evidence_quote":"Supplies the real QKD node pair that generates the keys driving the simulations."},{"cited_title":"Quantum Key Distribution (QKD); Protocol and data format of REST- based key delivery API,","cited_arxiv_id":null,"evidence_quote":"Specifies the REST key-delivery API used to retrieve keys in the simulated network."}],"review_version":1}