Pith. sign in

REVIEW 3 major objections 6 minor 27 references

Analysis of Post-Quantum Cryptography in User Equipment in 5G and Beyond

T0 review · 3 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 An emulated 5G testbed shows ML-KEM with ML-DSA is the fastest standardized post-quantum handshake for UE-to-UE links.

desk verdict Useful UE-to-UE PQC performance data, but the absolute latency conclusions overreach a single-core emulation and the scalability section has a factual slip that needs fixing. read the letter →

arxiv 2507.17074 v1 pith:OFQFE7YM submitted 2025-07-22 cs.CR cs.NIcs.PF

Sanzida Hoque , Abdullah Aydeger , Engin Zeydan , Madhusanka Liyanage This is my paper · ORCID
classification cs.CRcs.NIcs.PF
keywords post-quantumcryptography5GnetworksUE-to-UEcommunicationTLS1.3ML-KEMML-DSASPHINCS+handshakelatency
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 sets out to measure what the standardized post-quantum algorithms actually cost in a 5G user-equipment-to-user-equipment connection, rather than on isolated processors. It builds a complete emulated 5G network with two UEs, runs TLS 1.3 handshakes between them with post-quantum key encapsulation and signatures, and compares handshake latency, CPU use, bandwidth, and retransmissions across dozens of KEM-signature pairs. Its central empirical finding is that ML-KEM paired with ML-DSA is the fastest practical combination, with full handshakes around 23 ms at the lowest parameter levels, while HQC and SPHINCS+ combinations reach 140 ms or more. A sympathetic reader would take away a concrete ordering for 5G design: use lattice-based schemes for latency-critical sessions and reserve the slower, more conservative schemes for non-real-time security-heavy workloads.

What carries the argument

The load-bearing object is a staged emulation in which five virtual machines separate the 5G control plane, user plane, radio access node, and two user equipments, with the UE security layer running TLS 1.3 whose handshake can be switched among post-quantum KEMs (ML-KEM, HQC) and signatures (ML-DSA, Falcon, SPHINCS+). The comparison is carried by the TLS handshake itself as a benchmark: every combination negotiates the same protocol steps, so differences in latency, CPU, bandwidth, and retransmissions isolate the cryptographic overhead. A parallel client loader and packet capture add the dimensions of load and congestion to the measurements.

What would settle it

Run the same TLS 1.3 post-quantum handshake matrix on physical 5G user equipment attached to a real base station and core, or on a cellular development board, and compare handshake latency and retransmission rates with the emulated numbers; if ML-KEM+ML-DSA no longer clearly beats HQC+ML-DSA, or all algorithms sit within measurement noise, the emulated ordering is a testbed artifact.

Watch

Extended reading notes

Core claim

The central claim is that in a UE-to-UE TLS 1.3 session carried over an emulated 5G network, the choice of post-quantum algorithm visibly controls end-to-end performance, and the practical winner is the lattice pair ML-KEM with ML-DSA. In the data, the fastest full handshakes are 23 ms for mlkem512_mldsa44 and X25519_mldsa44, with CPU usage around 0.2% and near-zero retransmissions. SPHINCS+ combinations sit at the opposite extreme: hqc256_sphincssha2256f reaches 140 ms handshake latency, 10.6% peak CPU, and about 374 KB/s bandwidth, which the authors take as ruling such pairs out for latency-sensitive 5G services while keeping them appropriate for archival-strength use. Falcon sits in between, with handshake latencies mostly in the 31-91 ms range depending on the KEM. A scalability run with 10 and 20 simultaneous clients shows SPHINCS+ latency degrading from about 211 ms to 621 ms while ML-KEM with ML-DSA stays below 4% CPU.

Load-bearing premise

The ranking stands on the premise that a five-virtual-machine emulation on a single-core 1.7 GHz host behaves like real 5G UE-to-UE communication; if virtual-machine scheduling and the absence of true radio loss dominate the measurements, the absolute numbers and suitability verdicts do not transfer to physical devices.

Editorial extensions

If this is right

  • 5G protocol stacks can default to ML-KEM with ML-DSA for UE-to-UE sessions that must meet low-latency targets, since that combination handshakes in about 23 ms with near-zero retransmissions in the emulated network.
  • SPHINCS+ and HQC should be positioned for non-interactive or archival workloads rather than the latency-critical handshake path, given their 100+ ms handshakes and higher CPU and bandwidth use.
  • Scalability results show that signature choice dominates load behavior: SPHINCS+ latency grows from roughly 211 ms to 621 ms when concurrent clients rise from 10 to 20, so a single fixed configuration will not serve all load regimes.
  • The near-zero retransmission rates of the best pairs indicate that post-quantum cryptography itself need not aggravate radio-link congestion, clearing one obstacle to deployment in 5G access networks.

Reading between the lines

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

  • An extension the authors do not spell out is that the relative ordering, not the absolute milliseconds, is probably the transferable result, since a single-core virtualized host adds scheduling noise that would be absent on dedicated radio hardware.
  • A direct follow-up would be to run the same TLS 1.3 handshake matrix on physical UEs with real wireless loss and constrained device CPUs, checking whether the ML-KEM/ML-DSA lead survives device-level thermal and memory limits.
  • Because the bandwidth differences track public-key and signature sizes, a hybrid or compressed handshake that keeps the larger SPHINCS+/HQC objects out of the critical path could recover much of the measured gap.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper reports an empirical evaluation of NIST-selected post-quantum cryptographic algorithms (ML-KEM, HQC, ML-DSA, FALCON, SPHINCS+) integrated into TLS 1.3 in an emulated 5G UE-to-UE communication scenario. The authors use Open5GS and UERANSIM on five virtual machines, with BoringSSL and liboqs for PQC, and measure handshake latency, CPU/memory usage, bandwidth, and retransmission rates for various KEM-signature combinations. They also perform a scalability test with 10 and 20 concurrent clients. The central claim is that ML-KEM with ML-DSA gives the best latency/CPU trade-off, whereas SPHINCS+ and HQC combinations have high overhead and are 'unsuitable for security-critical but time-sensitive 5G scenarios' (Abstract).

Significance. If the reported measurements are reliable, the paper provides a useful empirical ordering of PQC algorithm combinations in a 5G-like UE-to-UE setting, complementing earlier benchmarks on servers and embedded platforms. The paper makes its experimental scripts publicly available on GitHub, which supports reproducibility. The qualitative result that lattice-based ML-KEM/ML-DSA outperforms hash-based SPHINCS+ in this TLS handshake setting is consistent with the broader PQC benchmarking literature. However, the absolute and comparative conclusions are weakened by the single-core virtualized emulation environment, the absence of a classical TLS baseline, and an internal inconsistency in the scalability results. As such, the paper's contribution is a directional, scenario-specific performance report rather than a definitive statement about real-world 5G deployment.

major comments (3)
  1. [Section IV.A and IV.C] The absolute 'unsuitable' verdict for SPHINCS+ and HQC is not supported by the measurement setup. The latencies in Tables I–III are measured on a single-core 1700 MHz host running five VMs (CP, UP, gNB, UE1, UE2) concurrently, with no dedicated-core or hardware validation and no classical TLS baseline. When the paper states (Section IV.C) that the minimum SPHINCS+ latency of 56 ms exceeds the <20 ms requirement for advanced 5G applications, this comparison implicitly assumes that the measured handshake latency reflects only cryptographic and protocol overhead. But the measurement includes VM scheduling, Open5GS/UERANSIM processing, and shared-core contention, which are not present in a physical UE. To make the absolute claim load-bearing, the authors should either measure a classical TLS baseline (e.g., X25519 with ECDSA) and subtract it, or run the crypto-only portion on a dedicated core; otherwise the 'unsuitable' conclusion should be restricted to a relative ordering.
  2. [Section IV.C.1 and Table V] The scalability analysis contains an internal inconsistency that undermines the stated conclusion. The text says 'The most substantial increase in latency is observed in mlkem512_sphincssha2128f', but Table V shows hqc128_sphincssha2128f increasing from 297.1 ms to 882.55 ms (an increase of 585.45 ms), whereas mlkem512_sphincssha2128f increases by only 409.9 ms (from 210.9 to 620.8 ms). Furthermore, in the same table the hqc128_mldsa44 row at 20 clients lists 'Avg Handshake Latency (ms)' as 369.55, which the text instead reports as the bandwidth (KB/s) value; this indicates a column swap between latency and bandwidth for that row. These errors must be corrected and the scalability discussion re-evaluated, because the current narrative about which scheme scales worst is contradicted by the authors' own table.
  3. [Section IV.B and Tables I–III] The CPU metric and the statistical basis for the rankings are not adequately supported. 'Max CPU Usage (%)' is defined as the peak during the TLS data transmission phase, yet the discussion attributes the CPU values to cryptographic handshake operations; if the peak occurs during data transmission, handshake crypto is not actually sampled. In addition, CPU is collected with 'ps aux', whose sampling interval is not reported and which will alias bursty crypto operations. The paper also provides no variance or confidence intervals, despite reporting averages over 50 iterations; differences of 1–2 ms (e.g., X25519_falcon512 at 35 ms vs. secp384r1_falcon512 at 34 ms) are presented as meaningful without statistical testing. At minimum, the authors should report standard deviations, the sampling rate for CPU, and a clear statement of which phase (handshake or data transfer) the CPU measurement covers.
minor comments (6)
  1. [Abstract and Section I] The abstract states that 'SPHINCS+ and HQC combinations incur higher computational and transmission overheads', but HQC is a KEM while SPHINCS+ is a signature scheme; the wording should clarify that these are combinations involving HQC or SPHINCS+.
  2. [Section III.A] The system architecture states the host has a single-core Intel64 processor at 1700 MHz and 13,880 MB of memory; it would be clearer to state whether this is a physical core, a virtual CPU, and the hypervisor details, since the single-core contention is central to interpreting all latency results.
  3. [Section IV.B] The retransmission rate formula uses '×' as a multiplication sign; the intended meaning is clear, but the equation should be typeset properly.
  4. [Section IV.C.1] The claim that mlkem512_sphincssha2128f 'maintains relatively stable bandwidth usage' from 918.666 KB/s to 919.1485 KB/s under a doubling of client count is counterintuitive and likely indicates a measurement artifact; please explain whether total aggregate bandwidth or per-client bandwidth is reported.
  5. [References] The setup description cites the authors' prior work [21] for Open5GS and UERANSIM; it would be more useful to cite the Open5GS and UERANSIM project documentation or the papers that introduced them, so readers can reproduce the exact versions and configuration.
  6. [Overall] The paper would benefit from a limitations paragraph explicitly acknowledging that the emulation does not include radio access delay, real UE CPU/memory constraints, or wireless packet loss, and that the conclusions are therefore limited to the emulated environment.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the PQC ranking is direct empirical measurement; only minor, non-load-bearing self-citations remain.

full rationale

This is an empirical measurement study rather than a derivation chain. The central claim — that ML-KEM combined with ML-DSA gives the lowest TLS handshake latency (~23 ms for mldsa44) and CPU use, while SPHINCS+ and HQC combinations cost more — is read directly from measured metrics: handshake timestamps logged by an experiment script (Section IV.A), CPU sampled via ps aux, and bandwidth/retransmissions captured with TShark (Section IV.B). No parameter is fitted and no quantity is predicted from another; Tables I–III report raw averages over 50 iterations, and the concluding ranking is a comparison of those numbers. The heatmap formula x_norm = (x − min(X))/(max(X) − min(X)) is only a visualization normalization and does not feed any claim back. The 'unsuitable' verdict compares measured SPHINCS+ latency (minimum 56 ms) with a <20 ms threshold cited to [25]; that threshold is a standard URLLC/5G figure external to the present measurements, so the comparison is not constructed from the conclusion. The paper does cite prior work by overlapping authors ([9], [21], and [25] with co-author Liyanage), but none is load-bearing: [21] only attests the Open5GS/UERANSIM toolchain that Section IV.A describes independently, and the new measurements are reproducible from the public GitHub repository [22]. The scalability text's claim that mlkem512_sphincssha2128f shows the largest latency increase, while Table V shows hqc128_sphincssha2128f grew by 585.45 ms versus 409.9 ms, is an internal accuracy error rather than circularity. The skeptic's point that single-core VM contention inflates absolute latencies is an external-validity risk, not a circularity risk.

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

The paper is an experimental evaluation; it introduces no fitted constants or new theoretical entities. The central claim depends on the validity of the emulation stack and the representativeness of the VM environment, plus the correctness of the cryptographic libraries.

assumptions (3)
  • domain assumption Open5GS and UERANSIM faithfully emulate 5G core and access network behavior.
    Section IV.A describes the emulation stack; all latency and retransmission measurements are produced in this emulated environment, so the conclusion inherits this assumption.
  • domain assumption The single-core VM setup is representative of UE computational constraints.
    Section IV.A: host has a single-core Intel64 1700 MHz CPU; the VMs share this. The paper uses this to draw conclusions about suitability for 5G UEs.
  • domain assumption BoringSSL with liboqs integration is a correct and performance-representative implementation of TLS 1.3 with PQC.
    The security layer uses these libraries (Section III.A); implementation-specific overhead is attributed to the algorithms themselves.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Analysis of Post-Quantum Cryptography in User Equipment in 5G and Beyond." pith.science (2026). https://pith.science/paper/OFQFE7YM

@misc{pith2026250717074,
  author       = {Pith},
  title        = {Pith review of: Analysis of Post-Quantum Cryptography in User Equipment in 5G and Beyond},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OFQFE7YM}},
  note         = {Machine review of arXiv:2507.17074}
}
read the original abstract

The advent of quantum computing threatens the security of classical public-key cryptographic systems, prompting the transition to post-quantum cryptography (PQC). While PQC has been analyzed in theory, its performance in practical wireless communication environments remains underexplored. This paper presents a detailed implementation and performance evaluation of NIST-selected PQC algorithms in user equipment (UE) to UE communications over 5G networks. Using a full 5G emulation stack (Open5GS and UERANSIM) and PQC-enabled TLS 1.3 via BoringSSL and liboqs, we examine key encapsulation mechanisms and digital signature schemes across realistic network conditions. We evaluate performance based on handshake latency, CPU and memory usage, bandwidth, and retransmission rates, under varying cryptographic configurations and client loads. Our findings show that ML-KEM with ML-DSA offers the best efficiency for latency-sensitive applications, while SPHINCS+ and HQC combinations incur higher computational and transmission overheads, making them unsuitable for security-critical but time-sensitive 5G scenarios.

Figures

Figures reproduced from arXiv: 2507.17074 by the authors.

Figure 1
Figure 1. System Architecture A. System Architecture The system architecture for post-quantum secure UE-to-UE communication has been designed to simulate a comprehensive 5G network environment. As shown in [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Sequence Diagram of TLS Handshake Process [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 5
Figure 5. Heatmap of Normalized Performance Metrics of Sphinc [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Heatmap of Normalized Performance Metrics of [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 7
Figure 7. Figure 7: Heatmap of Normalized Performance Metrics of [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 24 canonical work pages

  1. [1]

    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 review, vol. 41, no. 2, pp. 303–332, 1999

    1999

  2. [2]

    Post-quantum cryptography,

    D. J. Bernstein and T. Lange, “Post-quantum cryptography,” Nature, vol. 549, no. 7671, pp. 188–194, 2017

    work page 2017

  3. [3]

    Crystals-kyber: a cca-secure module-lattice-based kem,

    J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V . Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler, and D. Stehlé, “Crystals-kyber: a cca-secure module-lattice-based kem,” in 2018 IEEE European Symposium on Se- curity and Privacy (EuroS&P) . IEEE, 2018, pp. 353–367

    work page 2018

  4. [4]

    nist pqc finalist announcement

    NIST. "nist pqc finalist announcement". [Online]. Available: https: //csrc.nist.gov/projects/post-quantum-cryptography

    work page

  5. [5]

    A security architecture for 5g networks,

    G. Arfaoui, P. Bisson, R. Blom, R. Borgaonkar, H. Englund, E. Félix, F. Klaedtke, P. K. Nakarmi, M. Näslund, P. O’Hanlon et al., “A security architecture for 5g networks,” IEEE access , vol. 6, pp. 22 466–22 479, 2018

    work page 2018

  6. [6]

    Sphincs+ c: compress- ing sphincs+ with (almost) no cost,

    A. Hülsing, M. Kudinov, E. Ronen, and E. Yogev, “Sphincs+ c: compress- ing sphincs+ with (almost) no cost,” in 2023 IEEE Symposium on Security and Privacy (SP) . IEEE, 2023, pp. 1435–1453

    work page 2023

  7. [7]

    Improving software quality in cryptography standardization projects,

    M. J. Kannwischer, P. Schwabe, D. Stebila, and T. Wiggers, “Improving software quality in cryptography standardization projects,” in 2022 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) . IEEE, 2022, pp. 19–30

    work page 2022

  8. [8]

    High-performance ideal lattice-based cryptography on 8-bit avr microcontrollers,

    Z. Liu, T. Pöppelmann, T. Oder, H. Seo, S. S. Roy, T. Güneysu, J. Großschädl, H. Kim, and I. Verbauwhede, “High-performance ideal lattice-based cryptography on 8-bit avr microcontrollers,” ACM Transac- tions on Embedded Computing Systems (TECS) , vol. 16, no. 4, pp. 1–24, 2017

    work page 2017

Show all 27 references
  1. [9]

    Exploring post quantum cryp- tography with quantum key distribution for sustainable mobile network architecture design,

    S. Hoque, A. Aydeger, and E. Zeydan, “Exploring post quantum cryp- tography with quantum key distribution for sustainable mobile network architecture design,” in Proceedings of the 4th Workshop on Performance and Energy Efficiency in Concurrent and Distributed Systems , 2024, pp. 9–16

    2024

  2. [10]

    A survey on post-quantum cryptography for 5g/6g communications,

    R. Zhou, H. Guo, F. E. Teo, and S. Bakiras, “A survey on post-quantum cryptography for 5g/6g communications,” in 2023 IEEE International Conference on Service Operations and Logistics, and Informatics (SOLI) . IEEE, 2023, pp. 1–6

    2023

  3. [11]

    Mobile energy requirements of the upcoming nist post-quantum cryptography standards,

    M.-J. O. Saarinen, “Mobile energy requirements of the upcoming nist post-quantum cryptography standards,” in 2020 8th IEEE International Conference on Mobile Cloud Computing, Services, and Engineering (Mo- bileCloud). IEEE, 2020, pp. 23–30

    2020

  4. [12]

    5g-aka-hpqc: Hybrid post-quantum cryp- tography protocol for quantum-resilient 5g primary authentication with forward secrecy,

    Y . Ko, I. Pawana, and I. You, “5g-aka-hpqc: Hybrid post-quantum cryp- tography protocol for quantum-resilient 5g primary authentication with forward secrecy,” arXiv preprint arXiv:2502.02851 , 2025

    2025 arXiv

  5. [13]

    Implementing of 5g authentication and key agreement protocol: Practical security measures,

    R. H. Joudah and M. E. Manaa, “Implementing of 5g authentication and key agreement protocol: Practical security measures,” in 2024 21st International Multi-Conference on Systems, Signals & Devices (SSD) . IEEE, 2024, pp. 735–744

    2024

  6. [14]

    Integrating post-quantum tls into the control plane of 5g networks,

    Y . Hanna, D. Pineda, M. Veksler, M. Paudel, K. Akkaya, M. Anastasova, and R. Azarderakhsh, “Integrating post-quantum tls into the control plane of 5g networks,” in 2024 IEEE International Performance, Computing, and Communications Conference (IPCCC) . IEEE, 2024, pp. 1–8

    2024

  7. [15]

    An applied analysis of securing 5g/6g core networks with post-quantum key encapsulation methods,

    P. Scalise, R. Garcia, M. Boeding, M. Hempel, and H. Sharif, “An applied analysis of securing 5g/6g core networks with post-quantum key encapsulation methods,” Electronics, vol. 13, no. 21, p. 4258, 2024

    2024

  8. [16]

    Performance analysis and industry deployment of post-quantum cryptography algorithms,

    E. D. Demir, B. Bilgin, and M. C. Onbasli, “Performance analysis and industry deployment of post-quantum cryptography algorithms,” arXiv preprint arXiv:2503.12952, 2025

    2025 arXiv

  9. [17]

    sk telecom and thales collaborate on post-quantum cryptogra- phy to enhance users’ protection on 5g network

    T. Group. "sk telecom and thales collaborate on post-quantum cryptogra- phy to enhance users’ protection on 5g network". [Online]. Available: https://www.thalesgroup.com/en/worldwide/digital-identity-and-security/ press_release/sk-telecom-and-thales-collaborate-post

  10. [18]

    apple’s imessage is getting post-quantum en- cryption

    Wired. "apple’s imessage is getting post-quantum en- cryption". [Online]. Available: https://www.wired.com/story/ apple-pq3-post-quantum-encryption

  11. [19]

    Path to 5g: A control plane perspective,

    E. Guttman and I. Ali, “Path to 5g: A control plane perspective,” Journal of ICT Standardization , vol. 6, no. 1-2, pp. 87–100, 2018

    2018

  12. [20]

    Design and imple- mentation of a generic 5g user plane function development framework,

    C.-Y . Hsieh, Y .-W. Chang, C. Chen, and J.-C. Chen, “Design and imple- mentation of a generic 5g user plane function development framework,” in Proceedings of the 27th Annual International Conference on Mobile Computing and Networking , 2021, pp. 846–848

    2021

  13. [21]

    Post-quantum secure ue-to-ue communications,

    S. Hoque, A. Aydeger, and E. Zeydan, “Post-quantum secure ue-to-ue communications,” in 2024 15th International Conference on Network of the Future (NoF) . IEEE, 2024, pp. 28–30

    2024

  14. [22]

    Post quantum secured ue to ue communication in 5g,

    S. Hoque, “Post quantum secured ue to ue communication in 5g,” https: //github.com/SanzidaH/Post-Quantum-Secured-Communication-in-5G, 2025

    2025

  15. [23]

    Tange, GNU parallel 2018

    O. Tange, GNU parallel 2018 . Lulu. com, 2018

    2018

  16. [24]

    Using tshark to watch and inspect network traffic,

    M. Tsoukalos, “Using tshark to watch and inspect network traffic,” Linux Journal, vol. 2015, no. 254, p. 1, 2015

    2015

  17. [25]

    A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,

    Y . Siriwardhana, P. Porambage, M. Liyanage, and M. Ylianttila, “A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,” IEEE Communications Surveys & Tutorials, vol. 23, no. 2, pp. 1160–1192, 2021

    2021

  18. [26]

    Sphincs: practical stateless hash-based signatures,

    D. J. Bernstein, D. Hopwood, A. Hülsing, T. Lange, R. Niederha- gen, L. Papachristodoulou, M. Schneider, P. Schwabe, and Z. Wilcox- O’Hearn, “Sphincs: practical stateless hash-based signatures,” in Annual international conference on the theory and applications of cryptographic...

    2015

  19. [27]

    Benchmarking post-quantum cryptography in tls,

    C. Paquin, D. Stebila, and G. Tamvada, “Benchmarking post-quantum cryptography in tls,” in Post-Quantum Cryptography: 11th International Conference, PQCrypto 2020, Paris, France, April 15–17, 2020, Proceed- ings 11. Springer, 2020, pp. 72–91

    2020

Pith tools

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