{"id":"55c2fd0b-a31d-44c1-bb29-992a6e8be12f","arxiv_id":"2507.17074","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"In a virtual 5G setup, ML-KEM with ML-DSA gives the lowest handshake latency and CPU use, while SPHINCS+ and HQC add large overhead.","lead":"This paper measures how post-quantum encryption algorithms perform on simulated 5G phones talking to each other. It finds that lattice-based algorithms are fastest, while hash-based signatures are too slow for real-time traffic.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The single-core emulation confounds algorithm cost with VM scheduling: the absolute 'unsuitability' threshold (~20 ms) is applied to latencies that include shared-CPU contention and no radio access delay, so the central ranking needs a dedicated-core or hardware baseline to stand.","rationale":"The reader's weakest assumption is exactly the load-bearing concern: the emulation environment cannot support the paper's absolute latency-based suitability judgment. The paper's own strongest claim is framed in terms of milliseconds and an application-level latency budget, but the measured latencies are not isolated from the experimental harness. A single 1700 MHz core shared by five VMs means that every TLS handshake competes with emulated network functions for the same CPU, and no classical or no-TLS baseline is reported to separate cryptographic cost from platform overhead. This is not merely a question of whether the numbers generalize; it directly affects whether the 'unsuitable' conclusion is supportable. The relative ordering of algorithms is plausible and consistent with known properties of ML-DSA, HQC, and SPHINCS+, so the paper should not be rejected. However, the absolute threshold argument requires either a dedicated-core replication or a baseline subtraction. The scalability section also contains an internal inconsistency in the reported largest latency increase, but that sub-claim is less central than the main suitability verdict. The proposed check—dedicated cores or physical hardware plus a no-TLS baseline—would settle whether the central ranking and the 20 ms threshold conclusion survive without emulation artifacts. Since this matches the reader's concern and the recommended conditional posture, no verdict adjustment is needed.","tokens_in":13750,"tokens_out":5161,"duration_ms":56434,"concrete_test":"Run the identical UE-to-UE setup with each VM pinned to a dedicated core on a multi-core host (or on physical UEs with a real 5G SA core), and add two baseline conditions: (a) raw TCP handshake without TLS, and (b) classical TLS 1.3 with X25519/ECDSA. If after subtracting baseline (a) from each PQC configuration the ML-DSA value remains below 20 ms and the SPHINCS+ value remains above 20 ms, the ranking and the unsuitability conclusion survive; if the gap collapses or SPHINCS+ crosses below the threshold, the emulation artifact is decisive and the conclusion must be restricted to relative ordering only.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that ML-KEM+ML-DSA achieves ~23 ms handshake latency while SPHINCS+ variants start at 56 ms and are therefore 'unsuitable for security-critical but time-sensitive 5G scenarios' (Abstract). Every number in Tables I–III is produced on a host with a single 1700 MHz Intel64 core running five VMs (CP, UP, gNB, UE1, UE2) concurrently (Section IV.A). Consequently the reported latencies contain VM scheduling delays, Open5GS/UERANSIM processing, and cryptographic work all serialized on one core. The paper never measures a no-PQC or classical-TLS baseline against which this overhead could be subtracted, and the CPU-usage metric ('Max CPU usage (%)') is sampled with ps aux, so bursty crypto operations may be aliased. This matters because the 'unsuitable' verdict is an absolute threshold (advanced 5G services require <20 ms, Section IV.C), not merely a relative ordering. The same contention also contaminates the scalability test: at 20 clients, hqc128_sphincssha2128f reaches 882.55 ms, and the text states the largest latency increase is mlkem512_sphincssha2128f even though Table V shows hqc128_sphincssha2128f gains 585.45 ms vs 409.9 ms. That inconsistency weakens the scalability sub-claim, but the main load-bearing risk remains the lack of any baseline or hardware-validated latency measurement.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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).","tokens_in":14198,"tokens_out":3302,"duration_ms":34090,"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":[{"comment":"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.","section":"Section IV.A and IV.C"},{"comment":"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.","section":"Section IV.C.1 and Table V"},{"comment":"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.","section":"Section IV.B and Tables I–III"}],"minor_comments":[{"comment":"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+.","section":"Abstract and Section I"},{"comment":"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.","section":"Section III.A"},{"comment":"The retransmission rate formula uses '×' as a multiplication sign; the intended meaning is clear, but the equation should be typeset properly.","section":"Section IV.B"},{"comment":"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.","section":"Section IV.C.1"},{"comment":"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.","section":"References"},{"comment":"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.","section":"Overall"}],"recommendation":"major_revision","confidential_remarks":"The paper is a reasonable empirical study for a conference venue, and the open-source artifacts are a plus. However, the single-core emulation without a baseline is a serious limitation for the absolute claims, and the scalability section has concrete internal contradictions. The authors should be able to fix these with additional measurements (classical baseline, error bars) and a corrected table, so major revision rather than rejection seems appropriate. I would also note that the novelty over the authors' prior works [9,21] appears incremental; the editor may want to check the overlap with reference [21] to ensure the present paper adds substantial new results."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper gives you something real: a systematic measurement of NIST PQC KEM+signature combinations in a TLS 1.3 UE-to-UE session over an emulated 5G stack, including a 10/20-client scalability test. The code and data are on GitHub, the setup uses standard pieces (Open5GS, UERANSIM, BoringSSL, liboqs), and the relative ranking—ML-KEM+ML-DSA fast, Falcon middle, SPHINCS+ slow, HQC heavier—is believable and matches algorithmic expectations. No circularity, no parameter fitting; it is what it says, an empirical evaluation of known algorithms.\n\nThe soft spots are real but not fatal. The host is a single 1700 MHz core running five VMs, so every latency number includes VM scheduling and shared-CPU contention. That undermines the absolute \"unsuitable for time-sensitive 5G\" verdict: comparing 56 ms to a 20 ms service requirement is only meaningful if the emulation overhead is quantified. There is no pure classical TLS baseline in the tables—only classical KEMs paired with PQC signatures—so you cannot subtract the emulation cost. The fix is straightforward: add a no-PQC baseline, or re-run on dedicated cores/hardware, and soften the conclusions accordingly. Also, there are no error bars or statistical tests on the 50-iteration averages, so a few milliseconds of difference between adjacent configurations should not be over-read.\n\nThe scalability section contains a concrete internal inconsistency. The text says mlkem512_sphincssha2128f had the largest latency increase (210.9 to 620.8 ms, +409.9), but Table V shows hqc128_sphincssha2128f increased from 297.1 to 882.55 ms (+585.45). One of those statements is wrong, and a careful reader will notice. That needs a correction, not a rework.\n\nWho is this for? Anyone making early deployment choices for PQC in 5G/6G, or benchmarkers wanting a comparison point. It deserves a serious referee, not a desk reject, but it needs revision before the numbers should be used for engineering decisions. I would accept it with major comments.\n\nVerdict: send to review, ask for the baseline, the error bars, and the corrected scalability narrative.","headline":"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.","tokens_in":14589,"tokens_out":2058,"would_cite":true,"duration_ms":22977,"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":"An emulated 5G testbed shows ML-KEM with ML-DSA is the fastest standardized post-quantum handshake for UE-to-UE links.","keywords":["post-quantum cryptography","5G networks","UE-to-UE communication","TLS 1.3","ML-KEM","ML-DSA","SPHINCS+","handshake latency"],"falsifier":"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.","tokens_in":13572,"feed_emoji":"📶","tokens_out":8765,"duration_ms":85177,"temperature":0.7,"pith_summary":"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.","feed_headline":"ML-KEM plus ML-DSA wins 5G UE handshake speed test","feed_subtitle":"In a full emulated 5G network, the lattice pair handshakes in ~23 ms while SPHINCS+/HQC climb past 100 ms.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the UE-to-UE 5G network emulation setup that the experiments run on.","marker":"[21]"},{"why":"Provides the measurement scripts and logs that make the handshake data reproducible.","marker":"[22]"},{"why":"Generates the 10- and 20-client simultaneous connections used in the scalability stress test.","marker":"[23]"},{"why":"Captures the packet traces used to compute retransmission rates and bandwidth.","marker":"[24]"},{"why":"Defines the sub-20 ms and 50 ms latency expectations for advanced 5G applications against which suitability is judged.","marker":"[25]"},{"why":"Sets out the design of the SPHINCS+ family, referenced when the paper assigns it to archival rather than real-time roles.","marker":"[26]"},{"why":"Provides the TLS-level post-quantum benchmarking baseline that the paper extends to a 5G UE-to-UE setting.","marker":"[27]"}],"fun_headline_variants":["ML-KEM/ML-DSA handshake fastest in emulated 5G","5G post-quantum TLS: lattice pair hits 23ms handshake","Quantum-safe 5G: SPHINCS+/HQC too slow for real-time","Emulated 5G: ML-KEM/ML-DSA outperform HQC/SPHINCS","PQC on 5G: ML-KEM/ML-DSA leads latency test"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["ML-KEM/ML-DSA handshake fastest in emulated 5G","5G post-quantum TLS: lattice pair hits 23ms handshake","Quantum-safe 5G: SPHINCS+/HQC too slow for real-time","Emulated 5G: ML-KEM/ML-DSA outperform HQC/SPHINCS","PQC on 5G: ML-KEM/ML-DSA leads latency test"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001075,"raw_usage":{"total_tokens":4523,"prompt_tokens":992,"completion_tokens":3531,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":608,"completion_tokens_details":{"reasoning_tokens":3417}},"tokens_in":608,"tokens_out":3531,"duration_ms":26827,"temperature":1.0,"reasoning_tokens":3417,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T14:56:23.963195+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Using tshark to watch and inspect network traffic,","cited_arxiv_id":null,"evidence_quote":"Captures the packet traces used to compute retransmission rates and bandwidth."},{"cited_title":"Post-quantum secure ue-to-ue communications,","cited_arxiv_id":null,"evidence_quote":"Supplies the UE-to-UE 5G network emulation setup that the experiments run on."},{"cited_title":"Post quantum secured ue to ue communication in 5g,","cited_arxiv_id":null,"evidence_quote":"Provides the measurement scripts and logs that make the handshake data reproducible."},{"cited_title":"Tange, GNU parallel 2018","cited_arxiv_id":null,"evidence_quote":"Generates the 10- and 20-client simultaneous connections used in the scalability stress test."},{"cited_title":"A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,","cited_arxiv_id":null,"evidence_quote":"Defines the sub-20 ms and 50 ms latency expectations for advanced 5G applications against which suitability is judged."},{"cited_title":"Sphincs: practical stateless hash-based signatures,","cited_arxiv_id":null,"evidence_quote":"Sets out the design of the SPHINCS+ family, referenced when the paper assigns it to archival rather than real-time roles."},{"cited_title":"Benchmarking post-quantum cryptography in tls,","cited_arxiv_id":null,"evidence_quote":"Provides the TLS-level post-quantum benchmarking baseline that the paper extends to a 5G UE-to-UE setting."}],"review_version":1}