{"id":"60344139-7230-4dcf-abb9-1ec0f11dedc6","arxiv_id":"2506.09418","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":2.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey of cryptographic challenges in Open RAN for 5G, covering bidding-down attacks, interface encryption gaps, and 256-bit ciphers like SNOW-V, ZUC-256, and AES-256.","lead":"This paper surveys recent research on security problems in Open RAN, the modular architecture for 5G networks, focusing on encryption gaps and cryptographic solutions. It is a concise primer for engineers and policy makers who want to understand the security trade-offs of open telecom hardware.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Solution recommendations overreach the cited evidence: the survey never shows that cipher substitution or slice-aware cipher choice reduces the O-RAN latency overhead it attributes to IPsec/TLS, so the central claim that SNOW-V/ZUC-256/AES-256 'offer solutions' is not established.","rationale":"The paper is a readable secondary synthesis, and I have no objection to its summaries of the individual cited results; the primary papers do support the existence of bidding-down attacks, partial-encryption gaps, and side-channel leakage in SNOW-V implementations. The weakness is in the synthesis step: Section V turns cipher microbenchmarks and interface-protocol overhead reports into a unified roadmap without showing that the independent variables align. This is a correctness risk, not merely a style complaint, because the recommended 'solution' (implanting SNOW-V/ZUC-256 and slice-selecting ciphers) may not address the measured bottleneck. The reader's weakest_assumption (source representativeness) is real but not the most load-bearing concern; even with a perfect search, the inference from Wei et al. [13] to O-RAN deployments would still need an explicit bridging argument, and the paper currently lacks one. The '256-bit security requirement' framing also appears inconsistent with 3GPP TS 33.501's 128-bit NEA/NIA algorithms, which strengthens the need for correction. Agreement with the reader is partial: we agree the survey is conditional, but I would locate the main vulnerability in the unsupported cipher-to-interface inference rather than in source selection alone. The verdict should remain UNCHANGED because the flaw is fixable by reframing the evidence and adding an analysis of protocol-level overhead; it does not require discarding the survey's useful catalogue of attack and cipher literature.","tokens_in":4988,"tokens_out":5112,"duration_ms":57434,"concrete_test":"Read Groen et al. [8] and 'Securing O-RAN Open Interfaces' [9] and tabulate where measured O1/E2 latency and overhead originate: cipher core vs IPsec/TLS handshake vs per-record processing vs deployment gaps. If the dominant portion is not symmetric-cipher execution, the survey's slice-aware cipher-selection recommendation has no empirical support. In the same check, list the NEA/NIA algorithms named in 3GPP TS 33.501; if all are 128-bit, correct the '256-bit security requirement' premise in Section IV before any acceptance decision.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that SNOW-V/ZUC-256/AES-256 are emerging solutions for O-RAN and that hardware acceleration plus slice-aware cipher selection is the path forward. The load-bearing inference is that interface encryption latency is governed by cipher choice. But Sections III and IV cite Groen et al. [8] and 'Securing O-RAN Open Interfaces' [9] for exactly the opposite: overhead is from applying IPsec or TLS to every control-plane message, and exposure is from inconsistently deployed encryption. Neither paper is used to show that swapping in a faster stream cipher reduces E2/O1 latency; the bottleneck cited is protocol-level and deployment-level, not the symmetric primitive. Wei et al. [13] compares raw cipher throughput on RISC-V, but the survey does not connect that microbenchmark to actual O-RAN traffic, so recommendations like 'URLLC slices prefer SNOW-V' are unsupported. There is also a factual framing error: Section IV presents these as meeting '5G's 256-bit security requirements,' but 3GPP TS 33.501 defines 128-bit NEA/NIA algorithms; 256-bit ciphers are not a current 5G requirement, and O-RAN transport security is IPsec/TLS. This does not invalidate the cited primary attacks, but it breaks the bridge from 'cipher X is fast' to 'cipher X secures O-RAN.'","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This manuscript is a literature review of cryptographic challenges and emerging solutions for securing Open RAN (O-RAN). It draws on thirteen academic and industry sources to discuss O-RAN's disaggregated architecture, attacks such as cipher bidding-down and partial encryption exposure, side-channel threats to stream ciphers, and three 256-bit ciphers (SNOW-V, AES-256, ZUC-256). The paper then recommends hardware-accelerated encryption, slice-aware cipher selection, and AI-driven monitoring as the path forward for secure O-RAN, and closes with future directions toward zero-trust architectures in 6G.","tokens_in":5242,"tokens_out":3625,"duration_ms":40215,"significance":"If its central claim were established, this paper would serve as a compact entry point for researchers and practitioners seeking an overview of cryptographic options for O-RAN. The manuscript is internally consistent, avoids self-citation and circular reasoning, and accurately reports the main thrust of the cited primary sources at a high level; the discussions of bidding-down attacks, inconsistent interface encryption, and side-channel results on SNOW-V are useful signposts to the underlying literature. However, the paper's significance is limited by two issues: the evidence assembled does not actually connect cipher-level throughput to the interface-level latency problem that motivates the recommendations, and the paper frames 256-bit ciphers as meeting a 5G security requirement that current 3GPP specifications do not impose. These issues bear directly on the paper's central claim that SNOW-V, ZUC-256, and AES-256 'offer solutions' to O-RAN security, and they require substantial revision before the survey can be relied upon.","major_comments":[{"comment":"The manuscript repeatedly states that SNOW-V, ZUC-256, and AES-256 are needed to meet '5G's 256-bit security requirements' (Section I, end of second paragraph) and that 3GPP TS 33.501 underscores 'end-to-end 256-bit encryption' (Section V, paragraph 5). This is factually incorrect with respect to the cited standard: 3GPP TS 33.501 defines 128-bit confidentiality and integrity algorithms (NEA/NIA families), and 256-bit ciphers such as SNOW-V and ZUC-256 are research proposals or regional options, not current 5G requirements. Because this framing motivates the entire 'emerging solutions' narrative, it must be corrected and replaced with an accurate statement of what the standard actually mandates for O-RAN transport and user-plane protection.","section":"Sections I and V"},{"comment":"The paper's central recommendation—slice-aware selection among SNOW-V, ZUC-256, and AES-256—is not supported by the evidence it cites. Section III reports, via Groen et al. [8] and the open-interface analysis [9], that the dominant latency and overhead costs come from applying IPsec or TLS to every control-plane message and from inconsistently deployed encryption across vendors. Those findings point to protocol-level and deployment-level bottlenecks, not to the choice of the underlying symmetric cipher. The paper never shows that substituting SNOW-V or ZUC-256 for AES-256 would reduce E2 or O1 interface latency, which is the load-bearing inference behind the proposed 'URLLC slices prefer SNOW-V' recommendation. To make the claim defensible, the authors need to either supply evidence that cipher choice affects the measured E2/O1 overhead or explicitly scope the recommendation as applying only to the cipher primitive in isolation.","section":"Sections III and V"},{"comment":"The RISC-V benchmark of Wei et al. [13] is used to conclude that ZUC-256 and SNOW-V 'may outperform AES-256 in software-only RISC-V environments' and, later, to recommend SNOW-V for URLLC slices. However, the cited benchmark reports raw cipher throughput in a microbenchmark setting; the survey does not connect this to realistic O-RAN traffic, which involves small control-plane messages, per-packet overhead, handshake costs, and strict latency budgets. A faster keystream generation rate does not automatically translate into lower end-to-end latency on an O-RAN interface. The authors should either add the missing traffic-model analysis or temper the slice-selection recommendation to acknowledge that the interface-level benefit is not yet demonstrated.","section":"Section IV, Wei et al. [13]"},{"comment":"The Conclusion asserts a 'growing consensus around the need for hardware-accelerated, slice-aware, 256-bit encryption.' This is a strong claim about the state of the field, but the survey provides no documented search strategy, inclusion criteria, or coverage analysis; it is based on a convenience set of thirteen sources. As written, the evidence supports at most a statement that the cited papers take these directions, not that a broader consensus exists. The authors should either qualify the claim to reflect the limited source base or describe the systematic methodology that would justify a consensus claim.","section":"Conclusions and overall methodology"}],"minor_comments":[{"comment":"Reference [9] is an arXiv preprint and has not yet appeared in a peer-reviewed venue; the manuscript should state its status and, if possible, cite the published version.","section":"References"},{"comment":"Figure 1 is described as 'located at the end of this document,' but it appears after the references without a page number or inline placement; it would be clearer to place it within Section II where it is first referenced.","section":"Figure 1"},{"comment":"There are minor typographical inconsistencies, such as 'SNOW-V ,' with a space before the comma in the Index Terms and Section IV, and the occasional use of 'S NOW-V' instead of 'SNOW-V'; these should be cleaned up.","section":"Throughout"},{"comment":"The phrase 'adopted or proposed for 5G contexts' is ambiguous: SNOW-V and ZUC-256 are proposed for 5G, while AES-256 is a general-purpose cipher already widely deployed. The authors should distinguish 'standardized 5G algorithm' from 'candidate proposed for 5G' throughout the section.","section":"Section IV"}],"recommendation":"major_revision","confidential_remarks":"The paper is a very short survey (roughly four pages) covering a narrow set of thirteen sources. The lack of a documented search protocol and the small source base may be a scope concern for a journal-level survey, and the factual issue about 3GPP TS 33.501's 256-bit requirement should be fixed before acceptance. I see no integrity concerns: the paper does not rely on self-citation, and its strengths are in accurate high-level reporting of the cited attacks and cipher results. The main risk is that the recommendations overreach the evidence, which is fixable with revised claims and additional context."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing: the stress-test note is right. This is a readable, well-organized survey of O-RAN cryptographic issues, and the attack summaries (bidding-down, partial encryption, SNOW-V side-channel) faithfully track the cited papers. But the main thesis — that SNOW-V/ZUC-256/AES-256 plus hardware acceleration and slice-aware cipher selection is the path to securing O-RAN — is not supported by the evidence cited. Groen et al. [8] and the O-RAN open-interfaces paper [9] attribute overhead and exposure to applying IPsec/TLS to every E2/O1 control-plane message and to inconsistent deployment. The survey never shows that swapping the symmetric primitive reduces that overhead, and the RISC-V microbenchmark in [13] is not connected to actual O-RAN traffic. The claim that these ciphers meet \"5G's 256-bit security requirements\" is also wrong: 3GPP TS 33.501 specifies 128-bit NEA/NIA algorithms, and the paper even miscites [1] (Polese et al.) as TS 33.501. So the recommendations overreach the evidence.\n\nWhat the paper does well: it gives a newcomer a compact map of O-RAN architecture, interfaces, and the main recent attack papers. The source selection, though small, is relevant, and the side-channel work on SNOW-V is worth knowing about.\n\nThe soft spots are in proportion. This is a narrative synthesis of 13 papers with no search strategy, no inclusion criteria, and no comparison against existing comprehensive surveys — including Polese et al. [1], which already covers much of this ground. The \"growing consensus\" in the conclusion is asserted, not demonstrated. These aren't minor quibbles; they hit the paper's stated contribution, which is guidance on emerging solutions.\n\nBottom line: this is a reasonable term-paper-level survey. A newcomer could read it for orientation, but it doesn't add enough over the prior surveys to justify a full referee cycle. Desk reject with an invitation to resubmit after major revision (add methodology, fix the 3GPP framing, temper the recommendations) would be appropriate.","headline":"A readable but shallow O-RAN crypto survey whose headline recommendation overreaches the evidence it cites; fine for a newcomer's orientation, not for a serious venue.","tokens_in":5755,"tokens_out":4368,"would_cite":false,"duration_ms":39133,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This survey of thirteen sources argues that Open RAN's modular interfaces create exploitable gaps—cipher bidding-down and partial encryption—that 256-bit ciphers such as SNOW-V, ZUC-256, and AES-256 only close when paired with hardware…","keywords":["Open RAN","O-RAN security","5G","SNOW-V","ZUC-256","AES-256","bidding-down attack","side-channel attack"],"falsifier":"Instrument a production multi-vendor O-RAN deployment and monitor E2 and O1 during attach and handover: if every control-plane message is end-to-end encrypted and no man-in-the-middle can force fallback to NEA0, the survey's central threat model is not representative. A second check is to run SNOW-V on O-DU-grade hardware and see whether power traces leak key material in fewer than 50 traces; if leakage requires orders of magnitude more traces, the side-channel concern is overstated.","tokens_in":4779,"feed_emoji":"🔒","tokens_out":5705,"duration_ms":56219,"temperature":0.7,"pith_summary":"This review tries to establish that Open RAN's architectural openness—disaggregated, multi-vendor, programmable—creates security problems that classic 5G ciphering does not automatically solve: attackers can force downgrades to null encryption during attach or handover, and real deployments leave key interfaces like E2 only partially encrypted. It then argues that the 256-bit ciphers proposed for 5G (SNOW-V, ZUC-256, AES-256) each bring a different balance of throughput, hardware support, and side-channel exposure, so the actual fix is a layered one. If the survey is right, securing O-RAN means enforcing cipher-selection policies, offloading encryption to FPGA/SoC hardware, choosing ciphers per network slice, and using AI-driven controllers to detect anomalies in negotiation and signaling. The stakes are concrete: without these measures, multi-vendor openness hands an attacker visibility into control-plane signaling and user traffic.","feed_headline":"Cipher downgrade attacks slip through Open RAN's open interfaces","feed_subtitle":"Survey of 13 studies: SNOW-V, ZUC-256, and AES-256 pay off only with hardware offload and slice-aware policy.","key_machinery":"The load-bearing objects are the O-RAN control interface pair E2 and O1—the standardized links between the near-real-time RIC, O-DU/O-CU, and SMO—and the three 256-bit ciphers (SNOW-V, a stream cipher built from an LFSR plus AES-like rounds; ZUC-256, a compact stream cipher; and AES-256 in GCM mode). The argument runs through the interaction of these: the interfaces create the attack surface (bidding-down to NEA0, partial encryption), and the ciphers' measured throughput and side-channel resistance determine whether that surface can be closed within 5G's latency budgets.","core_discovery":"The paper's central claim is that the same openness that makes O-RAN flexible—standardized, multi-vendor interfaces like E2 and O1, plus programmable near-real-time controllers—also exposes 5G to a distinct set of cryptographic failures: attackers can bid down negotiated ciphers to NEA0 null encryption, and encryption is inconsistently applied across vendor links, leaving control and user planes partially exposed. Against these gaps the paper surveys three 256-bit primitives—SNOW-V, ZUC-256, and AES-256—and concludes on the basis of the cited studies that no single cipher is sufficient: SNOW-V offers speed but suffers side-channel leakage within tens of traces, AES-256 is broadly supported but slower in software-only RISC-V environments, and ZUC-256 is competitive in software yet less parallel. The synthesis points to hardware offloading, dynamic slice-aware cipher selection, and AI-driven monitoring as the combined path.","pith_inferences":["A natural extension the survey leaves implicit is measuring how widely transport encryption is actually disabled or misconfigured in fielded O-RAN products; that number would size the real-world exposure.","The side-channel results suggest that hardware-accelerated O-RAN units should also enforce physically isolated key storage, a requirement the paper names but does not develop.","A standardized benchmark on actual O-DU/O-CU hardware—measuring cipher throughput and side-channel resistance together—would test the RISC-V software results the survey leans on.","The slice-aware cipher selection idea points toward per-flow key lifecycle management in 6G zero-trust architectures, where the policy knob is not just which cipher but how keys are scoped and rotated."],"forward_implications":["Operators will need to enforce cipher-selection policies that reject NEA0 during attach and handover, or bidding-down attacks will continue to expose user-plane traffic.","Because full TLS/IPsec on every control-plane message carries measurable latency, O-RAN deployments will need selective or hardware-offloaded encryption on E2 and O1 to meet URLLC budgets.","SNOW-V's known side-channel leakage implies that cipher choice alone is not enough; constant-time logic, masking, and isolated key storage must be built into O-DU/O-CU hardware.","Slice-aware cipher selection—SNOW-V for tight-latency flows, AES-256-GCM for bulk eMBB data—emerges from the benchmarks as a way to balance security and performance."],"supporting_citations":[{"why":"Supplies the reference architecture for O-RAN interfaces, RIC, SMO, and the security challenges that frame the entire survey.","marker":"[1]"},{"why":"Establishes the bidding-down attack on 5G/4G cipher negotiation that the survey treats as a primary O-RAN vulnerability.","marker":"[6]"},{"why":"Quantifies the latency and processing overhead of applying IPsec or TLS to every control-plane message, driving the performance discussion.","marker":"[8]"},{"why":"Documents inconsistent encryption enforcement across vendor deployments, showing that E2 links can be partially or fully exposed.","marker":"[9]"},{"why":"Reports an ML-assisted side-channel attack that leaks SNOW-V key material in fewer than 50 traces, grounding the side-channel concern.","marker":"[10]"},{"why":"Provides lightweight FPGA implementations of SNOW-V, supporting the hardware acceleration direction.","marker":"[11]"},{"why":"Introduces SNOW-V, the 256-bit stream cipher the survey treats as the high-speed, low-overhead option for 5G interfaces.","marker":"[12]"},{"why":"Gives the RISC-V software comparison of ZUC-256, SNOW-V, and AES-256 that underpins the throughput and latency trade-offs.","marker":"[13]"}],"fun_headline_variants":["Cipher downgrade attacks exploit Open RAN's open interfaces","No single 256-bit cipher can secure Open RAN's interfaces","Hardware offload and slice-aware ciphers are O-RAN's real fix","Open RAN's openness invites cipher downgrade attacks","O-RAN's E2 and O1 interfaces leave crypto gaps for attackers"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole synthesis rests on the assumption that the thirteen sources it selected—chosen without a documented search strategy—are a fair sample of O-RAN security research and that their attack and benchmark results hold in real multi-vendor deployments.","fun_headline_variants_meta":{"raw":{"variants":["Cipher downgrade attacks exploit Open RAN's open interfaces","No single 256-bit cipher can secure Open RAN's interfaces","Hardware offload and slice-aware ciphers are O-RAN's real fix","Open RAN's openness invites cipher downgrade attacks","O-RAN's E2 and O1 interfaces leave crypto gaps for attackers"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000829,"raw_usage":{"total_tokens":3614,"prompt_tokens":930,"completion_tokens":2684,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":546,"completion_tokens_details":{"reasoning_tokens":2591}},"tokens_in":546,"tokens_out":2684,"duration_ms":18080,"temperature":1.0,"reasoning_tokens":2591,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T04:47:57.229277+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument a production multi-vendor O-RAN deployment and monitor E2 and O1 during attach and handover: if every control-plane message is end-to-end encrypted and no man-in-the-middle can force fallback to NEA0, the survey's central threat model is not representative. A second check is to run SNOW-V on O-DU-grade hardware and see whether power traces leak key material in fewer than 50 traces; if leakage requires orders of magnitude more traces, the side-channel concern is overstated.","supporting_citations":[{"cited_title":"Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges,","cited_arxiv_id":null,"evidence_quote":"Supplies the reference architecture for O-RAN interfaces, RIC, SMO, and the security challenges that frame the entire survey."},{"cited_title":"Never let me down again: Bidding-down attacks and mitigations in 5g and 4g,","cited_arxiv_id":null,"evidence_quote":"Establishes the bidding-down attack on 5G/4G cipher negotiation that the survey treats as a primary O-RAN vulnerability."},{"cited_title":"The cost of securing o-ran,","cited_arxiv_id":null,"evidence_quote":"Quantifies the latency and processing overhead of applying IPsec or TLS to every control-plane message, driving the performance discussion."},{"cited_title":"Securing O-RAN Open Interfaces","cited_arxiv_id":"2404.15076","evidence_quote":"Documents inconsistent encryption enforcement across vendor deployments, showing that E2 links can be partially or fully exposed."},{"cited_title":"SNOW-SCA: ML-assisted Side-Channel Attack on SNOW-V","cited_arxiv_id":"2403.08267","evidence_quote":"Reports an ML-assisted side-channel attack that leaks SNOW-V key material in fewer than 50 traces, grounding the side-channel concern."},{"cited_title":"Melting snow-v: improved lightweight architectures,","cited_arxiv_id":null,"evidence_quote":"Provides lightweight FPGA implementations of SNOW-V, supporting the hardware acceleration direction."},{"cited_title":"A new snow stream cipher called snow-v,","cited_arxiv_id":null,"evidence_quote":"Introduces SNOW-V, the 256-bit stream cipher the survey treats as the high-speed, low-overhead option for 5G interfaces."},{"cited_title":"Software implementation and comparison of zuc-256, snow-v, and aes-256 on risc-v platform,","cited_arxiv_id":null,"evidence_quote":"Gives the RISC-V software comparison of ZUC-256, SNOW-V, and AES-256 that underpins the throughput and latency trade-offs."}],"review_version":1}