Integration of quantum random number generators with post-quantum cryptography algorithms

Fernando de la Iglesia; Jordi Mur-Petit; Jos\'e Ram\'on Mart\'inez Saavedra; Luis Trigo Vidarte; Marc Romeu Casas; Paula Alonso Blanco; Valerio Pruneri

REVIEW 4 major objections 5 minor 14 references

Integration of quantum random number generators with post-quantum cryptography algorithms

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

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

Pith's one-line read Quantum entropy can feed post-quantum TLS over a network with negligible handshake cost.

desk verdict 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. read the letter →

arxiv 2507.00658 v2 pith:ZKE27VGJ submitted 2025-07-01 quant-ph

Paula Alonso Blanco , Luis Trigo Vidarte , Marc Romeu Casas , José Ramón Martínez Saavedra , Fernando de la Iglesia , Jordi Mur-Petit , Valerio Pruneri This is my paper · ORCID

classification quant-ph

keywords quantumrandomnumbergenerationentropyasaservicepost-quantumcryptographyTLShandshakekeyencapsulationmechanismpublicinfrastructuremin-entropymonitoringquantum-safe

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 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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

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

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 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.

Soft 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.

Overall: 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.

For a reading group, it's a maybe—useful for people working on QRNG integration or PQC deployment, but not conceptually deep.

Referee Report

4 major / 5 minor

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.

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 (4)

[IV (Conclusions); Abstract] 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.
[III, Table I] 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.
[III, first paragraph] 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).
[II.B and Fig. 3] 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.

minor comments (5)

[Abstract and Section I] There is a missing space in 'cryptography.TLS' at the end of the abstract; please correct the typo.
[II.A] The hardware name 'Quside Garnet™ PCIE 400' should be 'PCIe 400' for consistency with the standard spelling.
[III.B] The text uses 'Sphincs' in the bandwidth discussion; use 'SPHINCS+' consistently with the figure and the NIST nomenclature.
[Fig. 2] 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.
[II.B] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports direct measurements of an implemented QRNG-EaaS-PQC-TLS system, with no fitted parameter renamed as a prediction and no load-bearing self-citation chain.

full rationale

The paper is an experimental systems demonstration rather than a derivation, so there is no chain of equations in which an output is equivalent to an input by construction. The central quantitative claims—that EaaS introduces temporal overheads of typically less than 30% and that the QRNG's own contribution is below 10^-5 of handshake time—are computed from directly measured latencies reported in Table I and Figure 3; they are observed ratios of measured quantities, not predictions deduced from an assumed result. The average quantum min-entropy of 0.93 bits per bit is a vendor-stated device characteristic used as an input premise, not a conclusion derived by the paper, and relying on it is a trust and validation concern rather than circular reasoning. The paper cites external standards and tools (NIST EaaS, QRNG Open API, libOQS, OQS) as implementation components, and no argument in the paper is justified solely by a self-citation; the only disclosure of affiliation (VP being a Quside shareholder) is a conflict-of-interest statement, not a load-bearing citation. The absence of authentication or integrity analysis for the entropy delivery channel is a genuine threat-model and scope gap, but it is not a circular step: the security conclusion is unsupported by that analysis, not derived from it. Overall, the manuscript's claims are self-contained measurements against an implemented system, and no reduction of a claim to its own inputs was found.

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

No free parameters or invented entities appear in the paper. The work depends on vendor-supplied entropy metrics, correct open-source cryptographic implementations, and a trusted entropy distribution channel. These are the main assumptions on which the central claim rests.

assumptions (3)

domain assumption The Quside Garnet PCIE 400 QRNG output has genuine quantum min-entropy of at least 0.93 bits per bit and is suitable for cryptographic use.
Invoked in Section III and essential for the security motivation; the paper relies on vendor-provided metrics rather than an independent entropy evaluation.
domain assumption libOQS 0.9.0 and OpenSSL 3.2.0-beta1 correctly implement the PQC and hybrid algorithms used.
Used throughout Section II.A; no formal verification or conformance test results are provided.
domain assumption The EaaS network path over which random bytes are delivered is trusted and not adversarial.
Implied by the architecture in Section II.A and Fig. 1; no authentication or encryption of entropy requests is described, so an attacker on that path could influence or observe randomness.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Integration of quantum random number generators with post-quantum cryptography algorithms." pith.science (2026). https://pith.science/paper/ZKE27VGJ

@misc{pith2026250700658,
  author       = {Pith},
  title        = {Pith review of: Integration of quantum random number generators with post-quantum cryptography algorithms},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZKE27VGJ}},
  note         = {Machine review of arXiv:2507.00658}
}

read the original abstract

As quantum technologies advance, the security of popular cryptographic protocols becomes more threatened by the capabilities of Cryptographically Relevant Quantum Computers (CRQCs). In this scenario, Post-Quantum Cryptography (PQC) has become a potential solution to prolong the life of existing Public Key Infrastructure (PKI) systems. However, PQC protocols depend on high-quality randomness for key generation and encapsulation procedures, with the quality of the entropy source potentially having a profound impact on the security of the overall system. In this work, we demonstrate a proof-of-concept enabling the incorporation of Quantum Random Number Generation (QRNG) devices within communication networks using PQC-based Transport Layer Security (TLS).Using open-source cryptographic libraries and commercial QRNG hardware, we demonstrate their use as entropy sources via an Entropy-as-a-Service (EaaS) model. We highlight two particular use cases: a fully virtualized private PKI network and a connection to an external PQC-enabled server. Experimental results show that EaaS QRNG enables real-time entropy monitoring and quality assessment in cryptographic management systems, with negligible impact on TLS handshake time.

Figures

Figures reproduced from arXiv: 2507.00658 by the authors.

**Figure 2.** Grafana dashboard with QRNG metrics. Quantum min [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 4.** Bandwidth, in kilobytes, used to establish a TLS [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 13 canonical work pages

[1]

Cybersecurity in an era with quantum computers: will we be ready?

M. Mosca, “Cybersecurity in an era with quantum computers: will we be ready?” Cryptology ePrint Archive, Paper 2015/1075, 2015. [Online]. Available: https://eprint.iacr.org/2015/1075

work page 2015
[2]

Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,

P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997. [Online]. Available: https://doi.org/10.1137/S0097539795293172

doi:10.1137/s0097539795293172 1997
[3]

Benchmarking Attacks on Learning with Errors,

E. Wenger, E. Saxena, M. Malhou, E. Thieu, and K. Lauter, “Benchmarking Attacks on Learning with Errors,” Cryptology ePrint Archive, Paper 2024/1229, 2024. [Online]. Available: https://eprint.iacr. org/2024/1229

work page 2024
[4]

QRNG Open API,

Q. O. A. consortium lead by Palo Alto Networks, “QRNG Open API,” GitHub, 2025. [Online]. Available: https://github.com/ PaloAltoNetworks/QRNG-OPENAPI/

work page 2025
[5]

Entropy as a service (EaaS),

NIST, “Entropy as a service (EaaS),” Web, 2024. [Online]. Available: https://csrc.nist.gov/projects/entropy-as-a-service

work page 2024
[6]

Towards the Quantum-Safe Web: Benchmarking Post-Quantum TLS,

R. Rios, J. A. Montenegro, A. Mu ˜noz, and D. Ferraris, “Towards the Quantum-Safe Web: Benchmarking Post-Quantum TLS,”IEEE Network, pp. 1–1, 2025

work page 2025
[7]

Benchmarking Post-quantum Cryptography in TLS,

C. Paquin, D. Stebila, and G. Tamvada, “Benchmarking Post-quantum Cryptography in TLS,” in Post-Quantum Cryptography, J. Ding and J.-P. Tillich, Eds. Cham: Springer International Publishing, 2020, pp. 72–91

work page 2020
[8]

KEMTLS vs. Post-quantum TLS: Performance on Embedded Systems,

R. Gonzalez and T. Wiggers, “KEMTLS vs. Post-quantum TLS: Performance on Embedded Systems,” in Security, Privacy, and Applied Cryptography Engineering , L. Batina, S. Picek, and M. Mondal, Eds. Cham: Springer Nature Switzerland, 2022, pp. 99–117. [Online]. Available: https://kemtls.org/publication/kemtls-embedded/

work page 2022

Show all 14 references

[9]

Evaluating integration methods of a quantum random number generator in OpenSSL for TLS,

J. Blanco-Romero, V . Lorenzo, F. Almenares, D. D ´ıaz-S´anchez, C. G. Rubio, C. Campo, and A. Mar ´ın, “Evaluating integration methods of a quantum random number generator in OpenSSL for TLS,” Computer Networks , vol. 255, p. 110877, 2024. [Online]. Available: https://www.sci...

2024
[10]

Post-Quantum TLS Without Handshake Signatures,

P. Schwabe, D. Stebila, and T. Wiggers, “Post-Quantum TLS Without Handshake Signatures,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security , ser. CCS ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 1461–1480. [Online...

2020
[11]

OpenSSL Library,

O. S. F. Inc, “OpenSSL Library,” Web. [Online]. Available: https://www.openssl.org/
[12]

libOQS - OpenQuantumSafe library,

OpenQuantumSafe, “libOQS - OpenQuantumSafe library,” GitHub. [Online]. Available: https://github.com/open-quantum-safe/liboqs
[13]

Post-quantum key exchange for the Internet and the Open Quantum Safe project,

D. Stebila and M. Mosca, “Post-quantum key exchange for the Internet and the Open Quantum Safe project,” in Selected Areas in Cryptography (SAC) 2016 , ser. Lecture Notes in Computer Science, R. Avanzi and H. Heys, Eds., vol. 10532. Springer, 2017, pp. 1–24. [Online]. Availabl...

2016
[14]

Entropy as a Service: Evaluation of Randomness Distribution via Quantum Entropy Sources,

D. Leise, T. Siegele, B. Klopsch, and F. Wiemer, “Entropy as a Service: Evaluation of Randomness Distribution via Quantum Entropy Sources,” Quantum Reports , vol. 8, no. 2, p. 21, 2024. [Online]. Available: https://www.mdpi.com/2410-387X/8/2/21

2024

Pith tools

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

[1] [1]

Cybersecurity in an era with quantum computers: will we be ready?

M. Mosca, “Cybersecurity in an era with quantum computers: will we be ready?” Cryptology ePrint Archive, Paper 2015/1075, 2015. [Online]. Available: https://eprint.iacr.org/2015/1075

work page 2015

[2] [2]

Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,

P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997. [Online]. Available: https://doi.org/10.1137/S0097539795293172

doi:10.1137/s0097539795293172 1997

[3] [3]

Benchmarking Attacks on Learning with Errors,

E. Wenger, E. Saxena, M. Malhou, E. Thieu, and K. Lauter, “Benchmarking Attacks on Learning with Errors,” Cryptology ePrint Archive, Paper 2024/1229, 2024. [Online]. Available: https://eprint.iacr. org/2024/1229

work page 2024

[4] [4]

QRNG Open API,

Q. O. A. consortium lead by Palo Alto Networks, “QRNG Open API,” GitHub, 2025. [Online]. Available: https://github.com/ PaloAltoNetworks/QRNG-OPENAPI/

work page 2025

[5] [5]

Entropy as a service (EaaS),

NIST, “Entropy as a service (EaaS),” Web, 2024. [Online]. Available: https://csrc.nist.gov/projects/entropy-as-a-service

work page 2024

[6] [6]

Towards the Quantum-Safe Web: Benchmarking Post-Quantum TLS,

R. Rios, J. A. Montenegro, A. Mu ˜noz, and D. Ferraris, “Towards the Quantum-Safe Web: Benchmarking Post-Quantum TLS,”IEEE Network, pp. 1–1, 2025

work page 2025

[7] [7]

Benchmarking Post-quantum Cryptography in TLS,

C. Paquin, D. Stebila, and G. Tamvada, “Benchmarking Post-quantum Cryptography in TLS,” in Post-Quantum Cryptography, J. Ding and J.-P. Tillich, Eds. Cham: Springer International Publishing, 2020, pp. 72–91

work page 2020

[8] [8]

KEMTLS vs. Post-quantum TLS: Performance on Embedded Systems,

R. Gonzalez and T. Wiggers, “KEMTLS vs. Post-quantum TLS: Performance on Embedded Systems,” in Security, Privacy, and Applied Cryptography Engineering , L. Batina, S. Picek, and M. Mondal, Eds. Cham: Springer Nature Switzerland, 2022, pp. 99–117. [Online]. Available: https://kemtls.org/publication/kemtls-embedded/

work page 2022