{"id":"774b0e11-0c13-48c3-8a01-9cb65e011407","arxiv_id":"2507.00658","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A proof-of-concept showing quantum random number generators can supply entropy to post-quantum TLS connections over a network with under 30% handshake overhead and a negligible device-level contribution.","lead":"This paper shows how quantum random number generators can supply randomness to post-quantum TLS connections over a network, using commercial hardware and open-source libraries. It reports that this adds under 30% to handshake time in their test setups, with the QRNG device itself contributing less than one part in 100,000.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The trustworthiness claim rests on an unauthenticated entropy delivery path; an adversary with write access to EaaS responses can substitute known randomness, nullifying the QRNG security benefit. No authentication or integrity analysis for the entropy channel appears in the manuscript.","rationale":"The reader's weakest_assumption already identifies the entropy delivery path and the unanalyzed adversarial network as the key weakness. My reading agrees: the paper's own conclusion frames the contribution as improving trustworthiness, and that claim cannot survive an unauthenticated entropy channel. I do not see this as grounds to reject the paper, because the work is explicitly a proof-of-concept and the performance measurements are internally consistent; the missing piece is a clearly stated threat model for the EaaS channel and either an authenticated transport or an explicit trusted-network assumption. The CONDITIONAL verdict therefore remains appropriate. Other potential concerns, such as the absence of a direct no-EaaS baseline for handshake overhead, are secondary: Figure 3 already reports the measured EaaS latency as a fraction of handshake time, and the QRNG device-level overhead is genuinely negligible at the stated bit rates. The single most load-bearing issue is the security assumption on the entropy path, matching the reader's assessment.","tokens_in":6434,"tokens_out":6623,"duration_ms":78226,"concrete_test":"Instrument the EaaS client-to-server exchange and perform a man-in-the-middle test: intercept an entropy response, replace it with a deterministic byte string, and let the PQC TLS handshake proceed. If the handshake completes and the substituted values propagate into the KEM encapsulation (so an attacker can reconstruct the session secret), the current EaaS implementation does not provide the claimed trustworthiness without an authenticated entropy channel. Additionally, inspect the EaaS API configuration for TLS or message authentication; if none is present, the finding is confirmed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central security conclusion is that combining QRNG with PQC via EaaS 'improve[s] the trustworthiness of these schemes.' For that to hold, the bytes that PQC algorithms consume must be the bytes generated by the QRNG. The manuscript describes an entropy network (Fig. 1) over which random bytes are served to clients and servers, but it does not specify any authentication, integrity protection, or tamper-resistance for that channel. A network attacker who can intercept and modify EaaS responses can replace quantum-generated bytes with chosen values. TLS will accept those bytes as ordinary randomness, and because the attacker knows the substituted values, any ephemeral keys or KEM secrets derived from them may be recoverable, defeating the PQC key establishment. The QRNG's certified min-entropy and real-time monitoring only guarantee quality at the device output; they provide no evidence about the integrity of the bytes after network transit. Thus the 'improved trustworthiness' claim is load-bearing on an assumption that is neither stated nor analyzed. If the intended threat model excludes adversaries on the entropy network, that exclusion must be explicit; otherwise the security advantage over a local software RNG is unsupported.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript reports a proof-of-concept integration of a commercial QRNG device (Quside Garnet PCIE 400) with PQC-enabled TLS, using an Entropy-as-a-Service (EaaS) model. The authors describe two use cases: a local virtualized private PKI network and a client connecting to the external OQS PQC server. They measure TLS handshake time, bandwidth, response latency of the entropy service, and the number of random bytes requested by several hybrid KEMs (Kyber, BIKE, HQC, Frodo variants). The main experimental claims are that EaaS introduces temporal overheads typically below 30% of the handshake time, with the QRNG device itself contributing a negligible fraction below 10^-5, and that the approach 'improve[s] the trustworthiness' of PQC schemes.","tokens_in":6621,"tokens_out":3890,"duration_ms":46901,"significance":"If the security claim were substantiated, the work would be a useful practical demonstration that centralized quantum entropy can be delivered to PQC TLS with low overhead and with real-time monitoring of entropy quality. The paper's strengths include the use of open-source tools (OpenSSL and libOQS), measurements on a real commercial QRNG, two distinct deployment scenarios, and the presentation of error bars in Fig. 3. The architecture, the metrics chosen, and the measured overheads are valuable for practitioners seeking to deploy QRNG-based entropy in operational networks. However, the central 'improved trustworthiness' conclusion is load-bearing and is not backed by any security analysis of the entropy delivery path; this weakens the contribution as it stands.","major_comments":[{"comment":"The claim that the EaaS approach 'improve[s] the trustworthiness of these schemes' is unsupported because the manuscript never specifies or analyzes the security of the entropy delivery path. In Fig. 1, random bytes are delivered from the EaaS node over the 'entropy network' to the PQC TLS endpoints, but no authentication, integrity protection, or tamper-resistance is described. An on-path attacker who can modify EaaS responses can substitute chosen bytes for the QRNG output; TLS and libOQS will consume those bytes as ordinary randomness, and the attacker's knowledge of the substituted values can compromise ephemeral keys and KEM secrets. Thus the QRNG's certified min-entropy and real-time monitoring do not, by themselves, improve trustworthiness unless the channel from the device to the consuming application is trustworthy. The authors should either add an explicit threat model that excludes adversaries on the entropy network, or provide an integrity/authentication mechanism for that channel and analyze its security.","section":"IV (Conclusions); Abstract"},{"comment":"Table I presents point estimates for encapsulation random-byte demand, EaaS latency, and QRNG temporal overhead without any variance, sample count, or raw data. Since the paper's headline quantitative claims (overheads below 30%, QRNG contribution below 10^-5) rest on these measurements, the absence of statistical information makes the results difficult to assess or reproduce. The authors should report the number of measurements taken, the distribution of latencies (e.g., mean and standard deviation, or box plots), and ideally make the raw Wireshark measurement data available.","section":"III, Table I"},{"comment":"The paper takes the vendor-provided 'average quantum min-entropy of 0.93 bits per bit' and the related dashboard metrics as given, without independent validation or a sensitivity analysis. If the device's entropy estimate is optimistic, or if the monitoring metrics are not cryptographically tied to the bytes actually consumed by the PQC algorithms, then the security benefit of the EaaS architecture is correspondingly weaker. Since the manuscript's central security claim is about trustworthiness, the trust placed in vendor attestation should be stated explicitly as an assumption, and the authors should explain how the monitored metrics relate to a concrete security bound (e.g., how many min-entropy bits are guaranteed per requested byte).","section":"III, first paragraph"},{"comment":"The definition of the reported overheads is ambiguous. Section II.B says the authors 'measured the latency of the entropy provided by the QRNG and divided it by the time to perform the handshakes,' while Fig. 3's caption describes 'the ratio between EaaS latency (generation + transmission) and the total TLS handshake time,' and Table I lists a 'QRNG temporal overhead.' These are different quantities (device generation time, EaaS response time, and total handshake time). The paper should define each quantity precisely and give the formula used to compute the percentages in Fig. 3 and Table I, otherwise the relationship between the 'typically less than 30%' claim and the 'less than 10^-5' QRNG fraction is not verifiable.","section":"II.B and Fig. 3"}],"minor_comments":[{"comment":"There is a missing space in 'cryptography.TLS' at the end of the abstract; please correct the typo.","section":"Abstract and Section I"},{"comment":"The hardware name 'Quside Garnet™ PCIE 400' should be 'PCIe 400' for consistency with the standard spelling.","section":"II.A"},{"comment":"The text uses 'Sphincs' in the bandwidth discussion; use 'SPHINCS+' consistently with the figure and the NIST nomenclature.","section":"III.B"},{"comment":"The Grafana dashboard in Fig. 2 is referenced but not discussed in the text; a short sentence describing the monitored metrics and their role in the experiments would help the reader understand the monitoring capability.","section":"Fig. 2"},{"comment":"The phrase 'randomness demand placed on the QRNG during the encapsulation step' should clarify whether this is the number of bytes requested from the entropy service or the number of bytes actually drawn from the QRNG device, since a caching or DRBG layer could alter the effective demand.","section":"II.B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a systems/experimental report rather than a new theoretical result, which is appropriate for an applied venue. Note that several authors are affiliated with Quside Technologies, and the disclosure statement only mentions VP's shareholding; the editors may wish to ensure that the COI declaration covers all Quside-affiliated authors. On the substance, the measured-overhead part of the paper is plausible and useful, but the 'improved trustworthiness' claim in the abstract and conclusions needs either a proper security analysis or a substantially weakened and explicitly scoped statement."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a solid proof-of-concept paper, not a breakthrough. What's new is the specific measurement set: hybrid PQC KEMs (Kyber, BIKE, HQC, Frodo variants) over TLS, with entropy supplied by a commercial QRNG through an Entropy-as-a-Service model, plus real-time monitoring integration. The overhead numbers are internally consistent—dividing device generation time by handshake time reproduces the 10^-6 QRNG fractions, and Fig. 3 has propagated error bars. The paper is properly scoped, says what it does not do, and uses open-source tools (OpenSSL + libOQS) in a reproducible way. That is real value for practitioners.\n\nSoft spots: three, in increasing order. First, Table I gives point estimates without variance or sample counts; the paper would be stronger with raw data or a small table of handshake times. Second, there is no direct baseline without EaaS, so the 30% overhead is only relative to the online/local handshake, not against a no-EaaS configuration. Third—the one I'd push on—the conclusion claims EaaS QRNG can 'improve the trustworthiness of these schemes.' That is only true if the entropy delivery path is authenticated and tamper-resistant. The manuscript does not specify any integrity protection for the entropy network. An attacker who can modify EaaS responses can substitute chosen bytes, and TLS will accept them. The QRNG's certified min-entropy guarantees quality only at the device output, not after transit. This is a real gap in the security argument, though it may be outside the intended threat model; the paper should state the assumption explicitly or weaken the claim.\n\nOverall: the measurements are plausible and the engineering is honest. The paper is a demonstration, not a security analysis, and it doesn't try to be one—except in that one concluding sentence. I'd send it to a serious referee; a revision that addresses the entropy-channel threat model and provides more raw data would make it a clean accept.\n\nFor a reading group, it's a maybe—useful for people working on QRNG integration or PQC deployment, but not conceptually deep.","headline":"A useful, honest engineering demonstration of QRNG-as-a-service for PQC TLS; the measured overheads are credible, but the security claim needs an authenticated entropy channel.","tokens_in":7208,"tokens_out":1654,"would_cite":true,"duration_ms":18324,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Quantum entropy can feed post-quantum TLS over a network with negligible handshake cost.","keywords":["quantum random number generation","entropy as a service","post-quantum cryptography","TLS handshake","key encapsulation mechanism","public key infrastructure","min-entropy monitoring","quantum-safe cryptography"],"falsifier":"Replace the entropy service's output with a known deterministic bit stream while keeping all monitoring dashboards active; if TLS handshakes still complete normally and the dashboards report healthy entropy, then the deployment cannot detect substitution, and the improved-trustworthiness claim fails against an adversarial network. Alternatively, independently re-measure the device's per-bit entropy; if it falls materially below 0.93 bits per bit, the certified-randomness premise fails.","tokens_in":6240,"feed_emoji":"🔐","tokens_out":8261,"duration_ms":87233,"temperature":0.7,"pith_summary":"This paper tries to establish that quantum random number generators can be embedded in real communication networks through an Entropy-as-a-Service (EaaS) model and feed randomness directly to post-quantum cryptography (PQC) algorithms inside TLS handshakes. The motivation is that PQC key generation and encapsulation need high-quality entropy, and a monitored quantum source can supply it with a certified, real-time quality signal. Working with a commercial QRNG device, an open-source TLS stack, and two network settings (a local private PKI and an external PQC-enabled server), the authors show that EaaS delivery adds less than 30% to handshake time, with the QRNG itself contributing below one part in 100,000. If correct, the result supports practical, centralized deployment of quantum entropy as an upgrade that existing software can adopt without redesign.","feed_headline":"Quantum entropy feeds post-quantum TLS with negligible handshake cost","feed_subtitle":"Entropy delivered as a network service adds less than 30% handshake overhead; the QRNG itself contributes below one part in 100,000.","key_machinery":"The load-bearing mechanism is the Entropy-as-a-Service model: a commercial QRNG card inserted in a server, a network service distributing its random bytes to TLS endpoints, and a monitoring layer that reports quantum min-entropy, a statistical Q-Factor, and device-level physical metrics on every request. To make PQC use this entropy, the authors adapt an open-source post-quantum library so that its key generation and encapsulation routines call the entropy service instead of a local software RNG. The measured quantities that carry the argument are the per-KEM random-byte demand, the EaaS latency per request, and the ratio of that latency to total TLS handshake time.","core_discovery":"The central claim is that a QRNG need not sit inside each endpoint to protect PQC: a single networked entropy service can serve certificates, servers, and clients, and the PQC algorithms can consume its bits directly. In the paper's experiments, each PQC key encapsulation draws only 24–64 random bytes from the entropy service, and the measured QRNG contribution to TLS latency is at most $9.79\\times 10^{-6}$ of the handshake, while total EaaS overhead stays below 32% locally and reaches about 10% online. The QRNG also provides continuous metrics—an average quantum min-entropy of 0.93 bits per bit, statistical randomness measures, and photonic health indicators—that make the delivered entropy auditable in real time. The bandwidth cost of moving to PQC, by contrast, is dominated by certificate and key sizes: Dilithium adds over 10 kB and SPHINCS+ more than 70 kB relative to traditional signatures, and Frodo variants add nearly 28 kB over Kyber.","pith_inferences":["A production deployment would additionally need to authenticate the entropy channel, since the measured handshake does not itself detect substituted entropy; an attacker who controls that path could feed a deterministic stream into key generation.","The same latency numbers suggest EaaS could be pooled across many clients, since the bottleneck is per-request network latency rather than device throughput; batching or caching entropy locally would cut overhead further.","The monitored metrics could be repurposed as a policy input: if quantum min-entropy or Q-Factor drops below threshold, key-management software could automatically switch KEMs or refuse to issue certificates.","A natural testable extension is to repeat the measurements at higher security levels and over realistic wide-area jitter, where handshake times rise and the relative EaaS impact should shrink further."],"forward_implications":["A single QRNG can serve many TLS endpoints over a network because each PQC handshake consumes only tens of bytes of randomness, far below the device's extraction rate.","Real-time entropy monitoring can be built into PKI operations, giving administrators live visibility into the quality of randomness used for keys.","EaaS overhead is dominated by network round-trips, not by quantum generation, so remote entropy services on well-connected LANs add little to handshake latency.","PQC migration's practical cost is bandwidth and packet fragmentation from large certificates and keys, not entropy provisioning.","Using a monitored QRNG lets PQC key generation rely on certified physical randomness rather than an unmeasured software RNG assumption."],"supporting_citations":[{"why":"It establishes that low-quality randomness can facilitate attacks on PQC algorithms, motivating the need for certified entropy.","marker":"[3]"},{"why":"It specifies an open API for QRNG devices that supports the entropy service interface used in the deployment.","marker":"[4]"},{"why":"It defines the Entropy-as-a-Service concept that gives the deployment its structure.","marker":"[5]"},{"why":"It demonstrates earlier methods for integrating a QRNG into a TLS software stack, which the authors adapt to a networked setting.","marker":"[9]"},{"why":"It supplies the open-source post-quantum algorithm implementations that the authors modify to draw randomness from the QRNG.","marker":"[12]"},{"why":"It provides the external PQC-enabled server used to test the online use case.","marker":"[13]"}],"fun_headline_variants":["Quantum entropy as a service for post-quantum TLS","QRNG as a service enables PQC TLS with near-zero overhead","Quantum entropy service slashes PQC handshake cost","Networked quantum randomness for PQC TLS with minimal latency","Entropy-as-a-service integrates QRNG with post-quantum TLS"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The security argument rests on trusting both the QRNG's certified randomness quality and the network path that delivers that randomness to the TLS software; if the vendor's per-bit entropy estimate is optimistic or the entropy channel can be tampered with, the generated PQC keys can be silently weakened.","fun_headline_variants_meta":{"raw":{"variants":["Quantum entropy as a service for post-quantum TLS","QRNG as a service enables PQC TLS with near-zero overhead","Quantum entropy service slashes PQC handshake cost","Networked quantum randomness for PQC TLS with minimal latency","Entropy-as-a-service integrates QRNG with post-quantum TLS"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000892,"raw_usage":{"total_tokens":3854,"prompt_tokens":959,"completion_tokens":2895,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":575,"completion_tokens_details":{"reasoning_tokens":2810}},"tokens_in":575,"tokens_out":2895,"duration_ms":23829,"temperature":1.0,"reasoning_tokens":2810,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T21:09:29.834952+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Replace the entropy service's output with a known deterministic bit stream while keeping all monitoring dashboards active; if TLS handshakes still complete normally and the dashboards report healthy entropy, then the deployment cannot detect substitution, and the improved-trustworthiness claim fails against an adversarial network. Alternatively, independently re-measure the device's per-bit entropy; if it falls materially below 0.93 bits per bit, the certified-randomness premise fails.","supporting_citations":[{"cited_title":"Benchmarking Attacks on Learning with Errors,","cited_arxiv_id":null,"evidence_quote":"It establishes that low-quality randomness can facilitate attacks on PQC algorithms, motivating the need for certified entropy."},{"cited_title":"QRNG Open API,","cited_arxiv_id":null,"evidence_quote":"It specifies an open API for QRNG devices that supports the entropy service interface used in the deployment."},{"cited_title":"Entropy as a service (EaaS),","cited_arxiv_id":null,"evidence_quote":"It defines the Entropy-as-a-Service concept that gives the deployment its structure."},{"cited_title":"Evaluating integration methods of a quantum random number generator in OpenSSL for TLS,","cited_arxiv_id":null,"evidence_quote":"It demonstrates earlier methods for integrating a QRNG into a TLS software stack, which the authors adapt to a networked setting."},{"cited_title":"libOQS - OpenQuantumSafe library,","cited_arxiv_id":null,"evidence_quote":"It supplies the open-source post-quantum algorithm implementations that the authors modify to draw randomness from the QRNG."},{"cited_title":"Post-quantum key exchange for the Internet and the Open Quantum Safe project,","cited_arxiv_id":null,"evidence_quote":"It provides the external PQC-enabled server used to test the online use case."}],"review_version":1}