Pith. sign in

REVIEW 4 major objections 4 minor 13 references

Securing Open RAN: A Survey of Cryptographic Challenges and Emerging Solutions for 5G

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

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

Pith's one-line read 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…

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

arxiv 2506.09418 v1 pith:PQFHXZ37 submitted 2025-06-11 cs.CR cs.NI

Ryan Barker , Fatemeh Afghah This is my paper
classification cs.CRcs.NI
keywords OpenRANO-RANsecurity5GSNOW-VZUC-256AES-256bidding-downattackside-channel
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 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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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

Reading between the lines

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

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

4 major / 4 minor

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.

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 (4)
  1. [Sections I and V] 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.
  2. [Sections III and V] 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.
  3. [Section IV, Wei et al. [13]] 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.
  4. [Conclusions and overall methodology] 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.
minor comments (4)
  1. [References] 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.
  2. [Figure 1] 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.
  3. [Throughout] 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.
  4. [Section IV] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular reasoning found: this is a literature survey that synthesizes external results and does not fit or derive any quantity from its own conclusions.

full rationale

This manuscript is a survey, not a derivation. It reports attacks, cipher benchmarks, and interface-security findings from thirteen external sources and does not define any quantity in terms of the conclusion it draws. No parameter is fitted and then relabeled as a prediction; no formal claim is reduced by construction to its own assumptions; and the authors do not rely on self-citations as load-bearing evidence. The main weakness is evidentiary overreach: the survey asserts that SNOW-V, ZUC-256, and AES-256 'offer solutions' for O-RAN, and recommends slice-aware cipher selection and hardware offloading, but the cited sources cited for interface overhead actually attribute the latency to applying IPsec/TLS to every control-plane message and to inconsistent encryption deployment, not to the symmetric cipher primitive. That is a correctness or support gap, not circularity. Similarly, the statement that these ciphers meet '5G's 256-bit security requirements' may misstate 3GPP TS 33.501, which defines 128-bit NEA/NIA algorithms, but an inaccurate characterization of an external standard is not a circular step. Because the paper's claims are all imported from, and traceable to, independent external studies rather than to its own outputs or self-citations, the circularity score is 0.

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

This is a survey with no new derivations or experiments, so there are no fitted parameters or invented entities. The load-bearing assumptions are the representativeness of the 13-source sample, the accuracy of the cited experimental findings, and the transferability of those findings to O-RAN systems.

assumptions (3)
  • domain assumption The 13 cited references are representative of the O-RAN security literature.
    The survey selects exactly 13 sources without a systematic search or inclusion criteria, so its conclusions about 'emerging solutions' depend on this sample's representativeness.
  • domain assumption The reported performance and security findings from the cited papers generalize to real O-RAN deployments.
    The survey uses benchmarks from a RISC-V platform (reference [13]) and testbed studies to reach conclusions about O-RAN interfaces, assuming transferability across different hardware and configurations.
  • domain assumption The cited papers accurately report their experimental results.
    The survey does not independently verify side-channel traces, latency overheads, or throughput numbers, so it accepts these findings at face value.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Securing Open RAN: A Survey of Cryptographic Challenges and Emerging Solutions for 5G." pith.science (2026). https://pith.science/paper/PQFHXZ37

@misc{pith2026250609418,
  author       = {Pith},
  title        = {Pith review of: Securing Open RAN: A Survey of Cryptographic Challenges and Emerging Solutions for 5G},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PQFHXZ37}},
  note         = {Machine review of arXiv:2506.09418}
}
read the original abstract

The advent of Open Radio Access Networks (O-RAN) introduces modularity and flexibility into 5G deployments but also surfaces novel security challenges across disaggregated interfaces. This literature review synthesizes recent research across thirteen academic and industry sources, examining vulnerabilities such as cipher bidding-down attacks, partial encryption exposure on control/user planes, and performance trade-offs in securing O-RAN interfaces like E2 and O1. The paper surveys key cryptographic tools -- SNOW-V, AES-256, and ZUC-256 -- evaluating their throughput, side-channel resilience, and adaptability to heterogeneous slices (eMBB, URLLC, mMTC). Emphasis is placed on emerging testbeds and AI-driven controllers that facilitate dynamic orchestration, anomaly detection, and secure configuration. We conclude by outlining future research directions, including hardware offloading, cross-layer cipher adaptation, and alignment with 3GPP TS 33.501 and O-RAN Alliance security mandates, all of which point toward the need for integrated, zero-trust architectures in 6G.

Figures

Figures reproduced from arXiv: 2506.09418 by the authors.

Figure 1
Figure 1. Architectural evolution from monolithic RAN to Open RAN with 5G Standalone core, Service Management and Orchestration office, and disaggregated [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

13 extracted references · 11 canonical work pages

  1. [8]

    The cost of securing o-ran,

    J. Groen, B. Kim, and K. Chowdhury, “The cost of securing o-ran,” in ICC 2023 - IEEE International Conference on Communications , 2023, pp. 5444–5449

    work page 2023

  2. [9]

    Securing O-RAN Open Interfaces

    J. Groen, S. D’Oro, U. Demir, L. Bonati, D. Villa, M. Polese, T. Melodia, and K. Chowdhury, “Securing o-ran open interfaces,” 2024. [Online]. Available: https://arxiv.org/abs/2404.15076

    work page Pith review arXiv 2024

  3. [13]

    Software implementation and comparison of zuc-256, snow-v, and aes-256 on risc-v platform,

    M. Wei, G. Yang, and F. Kong, “Software implementation and comparison of zuc-256, snow-v, and aes-256 on risc-v platform,” in2021 IEEE International Conference on Information Communication and Software Engineering (ICICSE) , 2021, pp. 56–60. Fig. 1. Architectural evolution from monolithic RAN to Open RAN with 5G Standalone core, Service Management and Orc...

    work page 2021

  4. [1]

    Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges,

    M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges,” IEEE Communications Surveys & Tutorials , vol. 25, no. 2, pp. 1376–1411, 2023

    work page 2023

  5. [2]

    Open ai cellular (oaic): An open source 5g o-ran testbed for design and testing of ai-based ran management algorithms,

    P. S. Upadhyaya, N. Tripathi, J. Gaeddert, and J. H. Reed, “Open ai cellular (oaic): An open source 5g o-ran testbed for design and testing of ai-based ran management algorithms,” IEEE Network , vol. 37, no. 5, pp. 7–15, 2023

    work page 2023

  6. [3]

    X5g: An open, programmable, multi-vendor, end-to-end, private 5g o-ran testbed with nvidia arc and openairinterface,

    D. Villa, I. Khan, F. Kaltenberger, N. Hedberg, R. S. da Silva, S. Maxenti, L. Bonati, A. Kelkar, C. Dick, E. Baena, J. M. Jornet, T. Melodia, M. Polese, and D. Koutsonikolas, “X5g: An open, programmable, multi-vendor, end-to-end, private 5g o-ran testbed with nvidia arc and openairinterface,” 2025. [Online]. Available: https://arxiv.org/abs/2406.15935

    arXiv 2025

  7. [4]

    Orchestran: Network automation through orchestrated intelligence in the open ran,

    S. D’Oro, L. Bonati, M. Polese, and T. Melodia, “Orchestran: Network automation through orchestrated intelligence in the open ran,” in IEEE INFOCOM 2022 - IEEE Conference on Computer Communications , 2022, pp. 270–279

    work page 2022

  8. [5]

    dapps: Enabling real-time ai-based open ran control,

    A. Lacava, L. Bonati, N. Mohamadi, R. Gangula, F. Kaltenberger, P. Johari, S. D’Oro, F. Cuomo, M. Polese, and T. Melodia, “dapps: Enabling real-time ai-based open ran control,” 2025. [Online]. Available: https://arxiv.org/abs/2501.16502

    arXiv 2025

Show all 13 references
  1. [6]

    Never let me down again: Bidding-down attacks and mitigations in 5g and 4g,

    B. Karakoc, N. F ¨urste, D. Rupprecht, and K. Kohls, “Never let me down again: Bidding-down attacks and mitigations in 5g and 4g,” in Proceedings of the 16th ACM Conference on Security and Privacy in Wireless and Mobile Networks , ser. WiSec ’23. New York, NY , USA: Associatio...

    2023

  2. [7]

    5g messaging: System insecurity and defenses,

    J. Zhao, Q. Li, Z. Yuan, Z. Zhang, and S. Lu, “5g messaging: System insecurity and defenses,” in 2022 IEEE Conference on Communications and Network Security (CNS) , 2022, pp. 37–45

    2022

  3. [10]

    Snow-sca: Ml-assisted side-channel attack on snow-v,

    H. Saurabh, A. Golder, S. S. Titti, S. Kundu, C. Li, A. Karmakar, and D. Das, “Snow-sca: Ml-assisted side-channel attack on snow-v,” 2024. [Online]. Available: https://arxiv.org/abs/2403.08267

    2024 arXiv

  4. [11]

    Melting snow-v: improved lightweight architectures,

    A. Caforio, F. Balli, and S. Banik, “Melting snow-v: improved lightweight architectures,” Journal of Cryptographic Engineering , vol. 12, pp. 1–21, 04 2022

    2022

  5. [12]

    A new snow stream cipher called snow-v,

    P. Ekdahl, T. Johansson, A. Maximov, and J. Yang, “A new snow stream cipher called snow-v,” IACR Transactions on Symmetric Cryptology , vol. 2019, no. 3, p. 1–42, Sep. 2019. [Online]. Available: https://tosc.iacr.org/index.php/ToSC/article/view/8356

    2019

Pith tools

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