Pith. sign in

REVIEW 4 major objections 5 minor 134 references

BOLT is the first known oblivious map to achieve O(1)+O(log2 log2 N) bandwidth overhead with constant rounds, by using on-package HBM as an unobservable cache.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

BOLT is an FPGA-based oblivious map accelerator that uses isolated HBM as an unobservable cache to cut the bandwidth blow-up of key-value lookups to O(1)+O(log log N).

T0 review reviewed 2026-08-05 challenge →

load-bearing objection A genuinely new OMAP design that trades a standard hardware assumption for massive speedups; the proof gaps are real but fixable. the 4 major comments →

arxiv 2509.01742 v2 pith:ZQ2OPZVN submitted 2025-09-01 cs.CR cs.AR

BOLT: Bandwidth-Optimized Lightning-Fast Oblivious Map powered by Secure HBM Accelerators

classification cs.CR cs.AR
keywords oblivious mapORAMaccess pattern leakagehigh-bandwidth memorypower-of-two-choicestrusted execution environmentkey-value storehardware accelerator
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

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 tries to establish that the classic O(log^2 N) bandwidth overhead of oblivious maps is not fundamental. BOLT, a new accelerator-based oblivious map design, claims to reduce that overhead to O(1)+O(log2 log2 N) with a constant number of rounds by treating on-package High-Bandwidth Memory as a large unobservable cache. Data is spread across HBM bins and visible host-memory pages; each access reads two random bins, then remaps the key to two new bins using power-of-two-choices load balancing, which keeps the worst-case bin size small. A self-hosted accelerator controls its own memory and I/O, so the host CPU cannot leak traces indirectly. If the unobservability premise holds, BOLT brings oblivious key-value access to within about 2.5x of non-private speed, a dramatic improvement over the 960x-plus slowdowns of prior designs.

Core claim

The paper's central claim is that oblivious maps do not need worst-case padding and randomized remapping at the O(log^2 N) level if the trusted hardware has a large unobservable memory region rather than a constant-size one. BOLT divides the key-value store into K bins in on-package HBM and M fixed-size encrypted pages in host DRAM. Each key is mapped to two random bins; a request reads both bins (one real, one dummy), executes the get/put, then remaps the key to two fresh random bins. The power-of-two-choices rule places the item in the less loaded bin, and the paper proves (Claims 4.2-4.4) that the maximum bin load is c+O(log2 log2 N), the total HBM load concentrates tightly, and the evict

What carries the argument

The load-bearing object is a flat bin layout over two memory tiers: HBM bins and host-memory pages, coordinated by an HBM-resident position map and an eviction stash. The mechanism that produces the log-log overhead is power-of-two-choices (P2C) load balancing: after each access the data item is placed in the less loaded of two uniformly random bins, which bounds the maximum bin load by c+O(log2 log2 N). That bound directly sets the page size, the stash size, and ultimately the bandwidth per access. The second essential mechanism is the assumption of unobservable HBM: because the position map, stash, counts, and reverse index live inside the sealed package, the algorithm can run data-depende

Load-bearing premise

The whole obliviousness proof presumes that an attacker cannot observe the accelerator's HBM access patterns, because the position map, stash, and load-balancing logic are hidden there; if power, electromagnetic, or controller-level observation of HBM traffic is possible, the simulation argument collapses.

What would settle it

Run a known sequence of key lookups on an isolated HBM accelerator and record physical emanations per access, e.g., EM from the package or HBM power draw; if the observed pattern correlates with which two logical bins are accessed rather than being uniform over all bin pairs, the unobservable-HBM premise is falsified. A cheaper check: instrument the HBM controller to log which banks the position-map and stash reads hit, then test whether a simulator that knows only the dataset size can reproduce that distribution.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • If the claim holds, oblivious key-value access has constant rounds and O(log log N) bandwidth growth, so query latency remains nearly flat as datasets grow to tens of millions of entries.
  • The HBM footprint is modest: for one billion 64-byte-value entries with 32-bit keys, the paper computes roughly 26% of raw data size in HBM when the HBM store is disabled, and less for larger values.
  • Initialization cost drops to near the non-private baseline because the data owner can pre-organize data into bins and BOLT just loads them, giving up to 279x faster init than prior OMAPs.
  • BOLT's measured slowdown over a non-private key-value store stays at 1.8x-2.5x for tested sizes, versus at least 960x for the compared state-of-the-art OMAPs at 1M entries.
  • With larger HBM fractions, query throughput improves further (up to 219K QPS in the prototype), suggesting the design scales with accelerator memory capacity.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If unobservable on-package memory is accepted as a building block, the classical Omega(log N) bandwidth lower bound for ORAM no longer applies to designs with a large private memory tier; the same bin-plus-P2C recipe may extend to other oblivious data structures, such as oblivious sets or sorted maps.
  • The security guarantee is only as strong as the isolation boundary: a physical attack that recovers HBM access patterns (power, EM, or a compromised HBM controller) would void the simulation argument, so the design's practical security depends on hardware hardening the paper explicitly defers to prior TEE work.
  • The paper's stash bound is conservative and the resulting HBM allocation may be pessimistic; a tighter stochastic analysis or adaptive page sizing could reduce HBM requirements further than the reported figures.
  • BOLT's comparison excludes TEE runtime overheads and is run on a 300MHz FPGA, so the absolute speedups would shrink under vendor TEEs; the asymptotic claim, not the clock-rate-dependent latency, is the durable result.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents BOLT, an oblivious map (OMAP) accelerator that uses isolated on-package HBM as an unobservable memory region to hide position-map lookups, HBM bin accesses, and stash operations, while host DRAM is accessed through a bin-based oblivious scheme. The logical algorithm (Algorithm 1) assigns each key to two random bins, accesses both per operation, remaps after every access, and applies power-of-two-choices (P2C) load balancing. The authors claim O(1) rounds and O(1)+O(log_2 log_2 N) bandwidth overhead, enabled by HBM-backed metadata and a self-hosted FPGA architecture. A Xilinx U55C prototype is evaluated against H2O2RAM, EnigMap, and Facebook's OMAP, reporting large speedups in query/init time and low slowdown relative to non-private baselines. The paper includes a formal obliviousness argument (Claim 4.1), analytical bounds on bin load, HBM load, and stash size (Claims 4.2–4.4), and an overhead analysis (Claim 5.1).

Significance. If the security and performance claims hold, this is a significant advance for oblivious data structures: it challenges the conventional O(log^2 N)-style overheads by leveraging a hardware assumption (unobservable HBM) that is plausible for packaged accelerators. The paper's strengths include a clean algorithmic idea, a concrete FPGA prototype, open-source code, large speedups over prior OMAP implementations, and a careful empirical validation of the analytical bounds. The central security guarantee, however, rests entirely on the unobservability of HBM; the paper states this assumption but does not implement or validate the required isolation in the prototype. The stochastic analysis supporting the bounds also contains gaps that need to be repaired before the theoretical claims are fully supported.

major comments (4)
  1. [Claim 4.2 and Appendix C.1] The proof of the P2C bin-load bound is not valid as written. The recurrence beta_{k+1}=2N(beta_k/B)^2 with beta_0=B gives beta_1=2N, which is not <= B, and beta_2 is even larger; the claimed doubly exponential decay beta_k <= B*2^{-(2^k-O(1))} is inconsistent with these values. The conclusion max load = c+O(log log N) is therefore not established by the provided proof. Moreover, Claim 4.2 is a static balls-and-bins statement, whereas Algorithm 1 remaps items after every access and uses a dynamic P2C rule; the paper does not prove that the dynamic process preserves the static bound. Since Claim 5.1's bandwidth bound depends directly on the bin-load bound, this is load-bearing and must be fixed, either with a correct proof or by citing a theorem that covers the dynamic setting.
  2. [Claim 4.3] Claim 4.3 applies Hoeffding's inequality to the sum of HBM bin loads, but bin loads are not independent: they are coupled by the P2C placement and by the fact that items are remapped. The proof simply states 'all bin loads are within l_max' and applies Hoeffding, which is not justified for dependent bounded variables. This bound is used in Claim 5.2 to size HBM usage, so the gap matters for the practical resource calculation. The authors should either prove negative association (or another suitable dependence condition) or replace Hoeffding with a concentration inequality that applies under the actual dependence structure.
  3. [Claim 4.4 and Appendix C.2] The queue model for the stash is an approximation of the actual coupled enqueue/dequeue process. In particular, the enqueue probability 1-alpha^2 is an upper bound for the probability that the P2C final destination is a host bin, but the model treats enqueue and dequeue as if they were driven by independent random choices; in reality, the same pair of bins that triggers a page read also determines which stash labels are evicted. Additionally, the supermartingale argument in Appendix C.2 chooses lambda = 2(1-alpha)Delta/(M(...)) with Delta being the tail threshold, rather than the current state, so the claimed one-step supermartingale condition is not established. The numerical validation is encouraging, but the proof as written does not rigorously support the stash-size bound. Since stash overflow would cause data loss, this needs either a rigorous repair or an explicit statement that th
  4. [Section 3 and Claim 4.1] The obliviousness proof is explicitly conditional on HBM being unobservable: the simulator only simulates off-package accesses, and the threat model rules out power/EM analysis, chip depackaging, and multi-tenancy. This is a reasonable modeling choice, but the paper's abstract and conclusion state 'full data-obliviousness' without that qualifier. The security guarantee collapses if the HBM isolation is imperfect, and the FPGA prototype is evaluated without TEE isolation (Section 6.1), so the isolation mechanism is not implemented or validated. The authors should prominently state that the security claim is conditional on the HBM unobservability assumption and should discuss what concrete hardware mechanisms (e.g., SHEF-style firewalls, HBM controller protection) are needed to instantiate it, or explicitly list this as a limitation.
minor comments (5)
  1. [Section 5.3] In the proof of Claim 5.1, it is stated that for d>=4, log_2 log_2 N / log_2 d 'can be viewed as small as a constant.' This is not asymptotically correct; for fixed d it is O(log log N), which grows with N. The final O(log log N) bound is unaffected, but the sentence is misleading.
  2. [Section 4.3] The phrase 'with probability at least 1 - 1/O(N)' is nonstandard and likely intended to mean 1 - O(1/N) or 1 - 1/N^{Omega(1)}. Please clarify throughout.
  3. [Figure 2] The validation figure and the embedded table are hard to read; the legend labels ('Paramater', 'Bin Ld', 'HBM Ld', 'Stash') should be expanded and the axis scales clarified. Also, the table headers 'c=8' and 'c=16' are not clearly associated with the rows.
  4. [General] There are several typos: 'conclud' (Section 4.3), 'shwon' (Section 5.2), 'lighgweight' (Section 5.2), and a duplicated reference entry for Path ORAM (references [104], [105], [106] are the same work). A final proofreading pass is needed.
  5. [Section 6.3] The EnigMap comparison is performed at N=260K rather than the full 1M dataset, as noted. Since the slowdown metric is the primary comparison, this is acceptable, but the table should make the data-size disparity more visually prominent to avoid overstating the raw speedup.

Circularity Check

0 steps flagged

No circularity: BOLT's bounds come from external theorems and its security proof rests on an explicit, externally-sourced HBM-unobservability modeling assumption.

full rationale

BOLT's central derivation is self-contained. The O(log log N) bin-load bound (Claim 4.2) is a direct application of the external power-of-two-choices theorem [89,103], and the HBM-load and stash bounds (Claims 4.3-4.4) follow from Hoeffding's inequality and drift analysis. The paper does not fit these bounds to data; the validation experiments in Figure 2 compare simulated peaks to the a priori analytic bounds with constants set to 1, so no fitted parameter is being renamed as a prediction. The security argument (Claim 4.1) is a standard simulator proof whose only non-algorithmic input is the threat-model assumption that on-package HBM accesses are unobservable. That assumption is attributed to prior external works (Vaswani et al., Hunt et al., Volos et al.) and is explicitly scoped in Section 3's non-goals, making it a modeling premise rather than a circular reduction. There is no load-bearing self-citation chain: the authors' own prior work is not used to justify the central claim. Concerns about whether HBM is truly unobservable against power/EM or compromised-controller attacks are legitimate security-risk questions, but they are not instances of the paper's derivation reducing to its own inputs.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 0 invented entities

The central claim depends on two classes of assumptions: (1) the physical unobservability of HBM (the entire security argument), and (2) the concentration bounds for random bin loads (the bandwidth argument). The paper provides empirical validation for N=2^20, but the analytical proofs for the stash bound and the bin-load concentration are heuristic or improperly justified.

free parameters (3)
  • c (average records per bin, N/B) = 8 (default)
    Controls the page size and the position map size. The bandwidth blow-up is O(c + log log N); larger c reduces position map size but increases per-access bandwidth.
  • alpha (fraction of bins in HBM) = 0.2 (default; 0.01 and 0.5 in experiments)
    Sets the ratio of HBM bins and affects stash size and HBM usage. Larger alpha requires more HBM but reduces host-page access probability.
  • d (number of hash choices for position map) = 4
    Number of hash functions for power-of-choices in the position map; the paper claims d=4 suffices to keep position-map load bounded.
axioms (5)
  • domain assumption HBM is unobservable to the adversary
    Introduced Section 1, used throughout. The entire security proof treats all HBM traffic as invisible; if false, obliviousness fails.
  • domain assumption Attacker cannot perform chip depackaging
    Threat model Section 3: 'we assume attackers cannot perform hypothetical chip depackaging to compromise silicon interposers within the chip package.'
  • domain assumption Standard TEE building blocks are available and correct
    Section 2.3 and Appendix B; BOLT relies on remote attestation, I/O isolation, memory encryption, and integrity mechanisms rather than implementing them.
  • standard math Power-of-two-choices theorem for balls-and-bins
    Claim 4.2 cites [89,103]; gives max bin load c+O(log log N).
  • domain assumption Data owner is trusted to prepare initial partitioning
    Section 5.3 'Fast data initialization': DO pre-processes data and organizes into bins; if the owner is malicious, the initial layout could leak, but that is outside the threat model.

reviewed 2026-08-05 · how reviews work

0 comments
Cite this review

Pith. "Pith review of BOLT: Bandwidth-Optimized Lightning-Fast Oblivious Map powered by Secure HBM Accelerators." pith.science (2026). https://pith.science/paper/ZQ2OPZVN

@misc{pith2026250901742,
  author       = {Pith},
  title        = {Pith review of: BOLT: Bandwidth-Optimized Lightning-Fast Oblivious Map powered by Secure HBM Accelerators},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZQ2OPZVN}},
  note         = {Machine review of arXiv:2509.01742}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

While Trusted Execution Environments provide a strong foundation for secure cloud computing, they remain vulnerable to access pattern leakages. Oblivious Maps (OMAPs) mitigate this by fully hiding access patterns but suffer from high overhead due to randomized remapping and worst-case padding. We argue these costs are not fundamental. Modern accelerators featuring High-Bandwidth Memory (HBM) offer a new opportunity: Vaswani et al. [OSDI'18] point out that eavesdropping on HBM is difficult -- even for physical attackers -- as its memory channels are sealed together with processor cores inside the same physical package. Later, Hunt et al. [NSDI'20] show that, with proper isolation, HBM can be turned into an unobservable region where both data and memory traces are hidden. This motivates a rethink of OMAP design with HBM-backed solutions to finally overcome their traditional performance limits. Building on these insights, we present BOLT, a Bandwidth Optimized, Lightning-fast OMAP accelerator that, for the first time, achieves O(1) + O(log_2(log_2 (N))) bandwidth overhead. BOLT introduces three key innovations: (i) a new OMAP algorithm that leverages isolated HBM as an unobservable cache to accelerate oblivious access to large host memory; (ii) a self-hosted architecture that offloads execution and memory control from the host to mitigate CPU-side leakage; and (iii) tailored algorithm-architecture co-designs that maximize resource efficiency. We implement a prototype BOLT on a Xilinx U55C FPGA. Evaluations show that BOLT achieves up to 279x and 480x speedups in initialization and query time, respectively, over state-of-the-art OMAPs, including an industry implementation from Facebook.

Figures

Figures reproduced from arXiv: 2509.01742 by Chenghong Wang, Haobin Hiroki Chen, Hongbo Chen, Xiaofeng Wang, Yitong Guo, Yukui Luo.

Figure 1
Figure 1. Figure 1: BOLT overview and deployments level, BOLT is built on top of accelerator TEE architectures. It uses existing TEE features (§2.3) to enforce physical isolation and en￾sure integrity. The BOLT core is a full-fledged OMAP engine that sits behind the TEE gateway to provide efficient oblivious KV ac￾cesses. A typical BOLT lifecycle goes like this: A client first goes through standard TEE setups, such as remotel… view at source ↗
Figure 2
Figure 2. Figure 2: Validation experiments (Exp. vs. Anal.) Our empirical results in [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Architectural overview of BOLT. the design and execution flows of BOLT. For brevity, we focus on OMAP transactions and omit standard TEE features. 1 Initialization. BOLT undergoes a secure boot to initialize its internal states and allocates HBM storage for position map, eviction stash, and HBM bins. The host allocates a physically contiguous, pinned memory region (e.g., Hugepages [120]) so that BOLT can d… view at source ↗
Figure 4
Figure 4. Figure 4: Comparison of different storage design [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 4
Figure 4. Figure 4: c), we partition storage across multiple banks, with each [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Free address ring buffer. Initially, the ring buffer is preloaded with all available HBM addresses for value stores. When space is needed for, e.g., inserting new data or remapping a page-ed value into the HBM—an address is dequeued. For other cases where data is removed—due to deletion or eviction to pages—the freed address is returned to the ring buffer. This design allows for constant-time insertions. N… view at source ↗
Figure 6
Figure 6. Figure 6: Performance under scaling data entries. 8 16 32 64 128256 Value Size (bytes) 10 0 10 1 10 2 10 3 a. Init time (s) 8 16 32 64 128256 Value Size (bytes) 10 0 10 1 10 2 10 3 b. Init slowdown 8 16 32 64 128256 Value Size (bytes) 10 1 10 0 10 1 c. Query time (s) 8 16 32 64 128256 Value Size (bytes) 10 1 10 2 10 3 10 4 d. Query slowdown H2O2RAM Enigmap Facebook BOLT [PITH_FULL_IMAGE:figures/full_fig_p011_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Performance under scaling value sizes. Experiment setup. We adopt the same setup as § 6.3 and consider two scaling scenarios: (i) Entry size scaling. We fix the key and value size, but vary the number of data entries from 100K to 10M; (ii) Value length scaling. We fix the number of data entries at 1M but increase the value size from 8B to 256B, matching the largest block size evaluated by H2O2RAM [130]. We… view at source ↗
Figure 8
Figure 8. Figure 8: Performance breakdown. MAPpos Vhbm Vhost Stash Objects 10 0 10 1 10 2 10 3 10 4 Memory (MB) 624 16 192 128 a. 8B value size MAPpos Vhbm Vhost Stash Objects 624 488 6144 128 b. 256B value size [PITH_FULL_IMAGE:figures/full_fig_p012_8.png] view at source ↗
Figure 11
Figure 11. Figure 11: Post-synthesis netlist schematic of BOLT. HWRoT. A HWRoT is a compact, tamper-resistant hardware mod￾ule embedded in silicon that serves as the foundation for a system’s security functions. It comprises two primary components: (1) Boot ROM. An immutable section of code that executes immediately upon power-up to establish the initial chain of trust. (2) Crypto￾graphic elements. These include unique device … view at source ↗
Figure 10
Figure 10. Figure 10: The testbed and BOLT prototype. B Additional Background B.1 FPGA and its security features FPGA. An FPGA is a hardware device consisting of configurable logic blocks and interconnects, programmable by loading a developer￾created binary file called a bitstream. The bitstream, created by specialized FPGA design software, describes the exact logical opera￾tions and connections required to realize custom micr… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

134 extracted references · 71 canonical work pages · 6 internal anchors

  1. [1]

    Vitis Security Library

    2023. Vitis Security Library. https://www.amd.com/en/products/software/ adaptive-socs-and-fpgas/vitis/vitis-libraries/vitis-security.html. Accessed: 2023-06-10

  2. [2]

    Advanced Micro Devices, Inc. 2023. Alveo U55C Data Center Accelerator Card | AMD. https://www.amd.com/en/products/accelerators/alveo/u55c/a-u55c- p00g-pq-g.html. Accessed: 2023-05-22

  3. [3]

    Shaizeen Aga and Satish Narayanasamy. 2017. Invisimem: Smart memory defenses for memory bus side channel.ACM SIGARCH Computer Architecture News45, 2 (2017), 94–106

  4. [4]

    Amazon Web Services. [n. d.]. Amazon Simple Storage Service (S3). https: //aws.amazon.com/s3/. Accessed: 2025-07-10

  5. [5]

    Amazon Web Services. 2017. Amazon EC2 F1 Instances – Customizable FPGAs for Hardware Acceleration Are Now Generally Available. https: //aws.amazon.com/about-aws/whats-new/2017/04/amazon-ec2-f1-instances- customizable-fpgas-for-hardware-acceleration-are-now-generally-available/ Accessed: 2025-03-16

  6. [6]

    Amazon Web Services. 2024. Amazon EC2 F2 Instances. https://aws.amazon. com/ec2/instance-types/f2/ Accessed: 2025-03-16

  7. [7]

    AMD. [n. d.]. AMD Instinct MI325x Series Accelerators. https://www.amd.com/ en/products/accelerators/instinct/mi300/mi325x.html

  8. [8]

    AMD. 2023. UltraRAM Introduction. https://docs.amd.com/r/en-US/am007- versal-memory/UltraRAM-Introduction. Accessed: April 13, 2025

  9. [9]

    AMD. 2024. AMD Alveo V80 Data Center Accelerator Card. https://www.amd. com/en/products/accelerators/alveo/v80.html. Accessed: 2025-03-25

  10. [10]

    AMD. 2024. AMD EPYC Embedded 9004 and 8004 Series Product Brief. https://www.amd.com/content/dam/amd/en/documents/products/ embedded/epyc/epyc-embedded-9004-and-8004-series-product-brief.pdf Ac- cessed: March 4, 2025

  11. [11]

    2024.Asymmetric Hardware Root of Trust (HWRoT) Authentication Re- quired

    AMD. 2024.Asymmetric Hardware Root of Trust (HWRoT) Authentication Re- quired. https://docs.amd.com/r/en-US/ug1304-versal-acap-ssdg/Asymmetric- Hardware-Root-of-Trust-A-HWRoT-Authentication-Required Accessed: 2024- 06-22

  12. [12]

    Md Armanuzzaman and Ziming Zhao. 2022. Byotee: Towards building your own trusted execution environments using fpga.arXiv preprint arXiv:2203.04214 (2022)

  13. [13]

    2009.Computational complexity: a modern approach

    Sanjeev Arora and Boaz Barak. 2009.Computational complexity: a modern approach. Cambridge University Press

  14. [14]

    Gilad Asharov, Ilan Komargodski, Wei-Kai Lin, Kartik Nayak, Enoch Peserico, and Elaine Shi. 2020. OptORAMa: optimal oblivious RAM. InAdvances in Cryptology–EUROCRYPT 2020: 39th Annual International Conference on the The- ory and Applications of Cryptographic Techniques, Zagreb, Croatia, May 10–14, 2020, Proceedings, Part II 30. Springer, 403–432

  15. [15]

    Gilad Asharov, Ilan Komargodski, and Yehuda Michelson. 2023. Futorama: A concretely efficient hierarchical oblivious ram. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 3313–3327

  16. [16]

    Amro Awad, Yipeng Wang, Deborah Shands, and Yan Solihin. 2017. Obfusmem: A low-overhead access obfuscation for trusted memories. InProceedings of the 44th Annual International Symposium on Computer Architecture. 107–119

  17. [17]

    Dimitrios Balobas and Nikos Konofaos. 2016. Low-power, high-performance 64-bit CMOS priority encoder using static-dynamic parallel architecture. In 2016 5th International conference on modern circuits and systems technologies (MOCAST). IEEE, 1–4

  18. [18]

    Lejla Batina, Shivam Bhasin, Dirmanto Jap, and Stjepan Picek. 2019. CSI NN: Reverse engineering of neural network architectures through electromagnetic side channel. In28th USENIX Security Symposium (USENIX Security 19). 515–532

  19. [19]

    Vincent Bindschaedler, Muhammad Naveed, Xiaorui Pan, XiaoFeng Wang, and Yan Huang. 2015. Practicing oblivious access on cloud storage: the gap, the fallacy, and the new way forward. InProceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. 837–849

  20. [20]

    Laura Blackstone, Seny Kamara, and Tarik Moataz. 2019. Revisiting leakage abuse attacks.Cryptology ePrint Archive(2019)

  21. [21]

    Michaela Blott, Kimon Karras, Ling Liu, Kees Vissers, Jeremia Bär, and Zsolt István. 2013. Achieving 10gbps line-rate key-value stores with{FPGAs}. In5th USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 13)

  22. [22]

    Stéphane Boucheron, Gábor Lugosi, and Olivier Bousquet. 2003. Concentration inequalities. InSummer school on machine learning. Springer, 208–240

  23. [23]

    Xinle Cao, Weiqi Feng, Jian Liu, Jinjin Zhou, Wenjing Fang, Lei Wang, Quanqing Xu, Chuanhui Yang, and Kui Ren. 2024. Towards Practical Oblivious Map. Cryptology ePrint Archive(2024)

  24. [24]

    David Cash, Paul Grubbs, Jason Perry, and Thomas Ristenpart. 2015. Leakage- abuse attacks against searchable encryption. InProceedings of the 22nd ACM CCS ’25, October 13–17, 2025, Taipei, Taiwan. Guo et al. SIGSAC conference on computer and communications security. 668–679

  25. [25]

    Javad Ghareh Chamani, Ioannis Demertzis, Dimitrios Papadopoulos, Charalam- pos Papamanthou, and Rasool Jalili. 2023. GraphOS: Towards Oblivious Graph Processing.Proceedings of the VLDB Endowment16, 13 (2023), 4324–4338

  26. [26]

    Zhao Chang, Dong Xie, Feifei Li, Jeff M Phillips, and Rajeev Balasubramonian

  27. [27]

    Yuezhi Che and Rujia Wang. 2020. Multi-range supported oblivious RAM for efficient block data retrieval. In2020 IEEE International Symposium on High Performance Computer Architecture (HPCA). IEEE, 369–382

  28. [28]

    Kwanghoon Choi, Igjae Kim, Sunho Lee, and Jaehyuk Huh. 2024. ShieldCXL: A Practical Obliviousness Support with Sealed CXL Memory.ACM Transactions on Architecture and Code Optimization(2024)

  29. [29]

    Chitchanok Chuengsatiansup, Daniel Genkin, Yuval Yarom, and Zhiyuan Zhang

  30. [30]

    Memcached Contributors. 2025. Programming Tricks: Reducing Key Size. https://github.com/memcached/memcached/wiki/ProgrammingTricks# reducing-key-size. Accessed: 2025-03-23

  31. [31]

    OpenDSA Project Contributors. 2023. Heap Memory. https://opendsa-server.cs. vt.edu/ODSA/Books/CS2/html/HeapMem.html. Accessed: 2025-04-07

  32. [32]

    Cooper et al

    Brian F. Cooper et al. 2010. Yahoo! Cloud Serving Benchmark (YCSB). https: //github.com/brianfrankcooper/YCSB. Accessed: 2025-03-21

  33. [33]

    Intel Corporation. 2024. Intel Xeon Max Series Processors. https://www.intel. com/content/www/us/en/products/details/processors/xeon/max-series.html Accessed: March 16, 2025

  34. [34]

    Victor Costan and Srinivas Devadas. 2016. Intel SGX explained.Cryptology ePrint Archive(2016)

  35. [35]

    Natacha Crooks, Matthew Burke, Ethan Cecchetti, Sitar Harel, Rachit Agarwal, and Lorenzo Alvisi. 2018. Obladi: Oblivious serializable transactions in the cloud. In13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18). 727–743

  36. [36]

    Fergus Dall, Gabrielle De Micheli, Thomas Eisenbarth, Daniel Genkin, Nadia Heninger, Ahmad Moghimi, and Yuval Yarom. 2018. Cachequote: Efficiently recovering long-term secrets of SGX EPID via cache attacks. (2018)

  37. [37]

    Wafi Danesh, Joshua Banago, and Mostafizur Rahman. 2020. Turning the Table: Using Reverse Engineering Techniques to Detect FPGA Trojans.Journal of Hardware and Systems Security(2020)

  38. [38]

    Emma Dauterman, Vivian Fang, Ioannis Demertzis, Natacha Crooks, and Raluca Ada Popa. 2021. Snoopy: Surpassing the scalability bottleneck of oblivi- ous storage. InProceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. 655–671

  39. [39]

    Aritra Dhar, Clément Thorens, Lara Magdalena Lazier, and Lukas Cavigelli. 2024. Ascend-CC: Confidential Computing on Heterogeneous NPU for Emerging Generative AI Workloads.arXiv preprint arXiv:2407.11888(2024)

  40. [40]

    Sam Dittmer and Rafail Ostrovsky. 2020. Oblivious tight compaction in O (n) time with smaller constant. InInternational Conference on Security and Cryptography for Networks. Springer, 253–274

  41. [41]

    Kha Dinh Duy and Hojoon Lee. 2022. SE-PIM: In-Memory Acceleration of Data-Intensive Confidential Computing.IEEE Transactions on Cloud Computing (2022)

  42. [42]

    Dirk Eddelbuettel. 2022. A brief introduction to redis.arXiv preprint arXiv:2203.06559(2022)

  43. [43]

    Saba Eskandarian and Matei Zaharia. 2019. ObliDB: Oblivious Query Processing for Secure Databases.Proc. VLDB Endow.13, 2 (oct 2019), 169–183. doi:10.14778/ 3364324.3364331

  44. [44]

    Dmitry Evtyushkin, Ryan Riley, Nael CSE Abu-Ghazaleh, ECE, and Dmitry Ponomarev. 2018. Branchscope: A new side-channel attack on directional branch predictor.ACM SIGPLAN Notices53, 2 (2018), 693–707

  45. [45]

    Facebook. 2023. Facebook ORAM Repository. https://github.com/facebook/oram. Accessed: 2025-03-21

  46. [46]

    Chongzhou Fang, Ning Miao, Han Wang, Jiacheng Zhou, Tyler Sheaves, John M Emmert, Avesta Sasan, and Houman Homayoun. 2023. Gotcha! i know what you are doing on the fpga cloud: Fingerprinting co-located cloud fpga accelerators via measuring communication links. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2024–2037

  47. [47]

    Christopher W Fletcher, Ling Ren, Albert Kwon, Marten Van Dijk, Emil Ste- fanov, Dimitrios Serpanos, and Srinivas Devadas. 2015. A low-latency, low-area hardware oblivious RAM controller. In2015 IEEE 23rd Annual International Sym- posium on Field-Programmable Custom Computing Machines. IEEE, 215–222

  48. [48]

    GeeksforGeeks. 2024. How to Store Data on Ethereum Blockchain? https: //www.geeksforgeeks.org/how-to-store-data-on-ethereum-blockchain/ Ac- cessed: 2025-03-24

  49. [49]

    Ilias Giechaskiel, Kasper Bonne Rasmussen, and Jakub Szefer. 2020. C 3 APSULe: Cross-FPGA covert-channel attacks through power supply unit leakage. In2020 IEEE Symposium on Security and Privacy (SP). IEEE, 1728–1741

  50. [50]

    Ilias Giechaskiel, Shanquan Tian, and Jakub Szefer. 2022. Cross-vm covert- and side-channel attacks in cloud fpgas.ACM Transactions on Reconfigurable Technology and Systems16, 1 (2022), 1–29

  51. [51]

    Oded Goldreich. 1987. Towards a theory of software protection and simulation by oblivious RAMs. InProceedings of the nineteenth annual ACM symposium on Theory of computing. 182–194

  52. [52]

    Oded Goldreich and Rafail Ostrovsky. 1996. Software protection and simulation on oblivious RAMs.Journal of the ACM (JACM)43, 3 (1996), 431–473

  53. [53]

    Cheng Gongye, Yukui Luo, Xiaolin Xu, and Yunsi Fei. 2023. Side-Channel- Assisted Reverse-Engineering of Encrypted DNN Hardware Accelerator IP and Attack Surface Exploration. In2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 1–1

  54. [54]

    Ben Gras, KAVEH Razavi, Herbert Bos, and Cristiano Giuffrida. 2018. Tlbleed: When protecting your cpu caches is not enough.Black Hat(2018)

  55. [55]

    Mathieu Gross, Nisha Jacob, Andreas Zankl, and Georg Sigl. 2019. Breaking trustzone memory isolation through malicious hardware on a modern fpga-soc. InProceedings of the 3rd ACM Workshop on Attacks and Solutions in Hardware Security Workshop. 3–12

  56. [56]

    Shay Gueron. 2016. A Memory Encryption Engine Suitable for General Purpose Processors. Cryptology ePrint Archive, Paper 2016/204. https://eprint.iacr.org/ 2016/204

  57. [57]

    Shay Gueron, Adam Langley, and Yehuda Lindell. 2017. AES-GCM-SIV: specifi- cation and analysis.Cryptology ePrint Archive(2017)

  58. [58]

    Chuanxiong Guo, Haitao Wu, Zhong Deng, Gaurav Soni, Jianxi Ye, Jitu Padhye, and Marina Lipshteyn. 2016. RDMA over commodity ethernet at scale. In Proceedings of the 2016 ACM SIGCOMM Conference. 202–215

  59. [59]

    Brett Hemenway Falk, Daniel Noble, and Rafail Ostrovsky. 2021. Alibi: A flaw in cuckoo-hashing based hierarchical ORAM schemes and a solution. In Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 338–369

  60. [60]

    Wassily Hoeffding. 1994. Probability inequalities for sums of bounded random variables.The collected works of Wassily Hoeffding(1994), 409–426

  61. [61]

    Xing Hu, Ling Liang, Shuangchen Li, Lei Deng, Pengfei Zuo, Yu Ji, Xinfeng Xie, Yufei Ding, Chang Liu, Timothy Sherwood, and Yuan Xie. 2020. Deepsniffer: A DNN model extraction framework based on learning architectural hints. In Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems...

  62. [62]

    Shao-Wei Huang and Yen-Jen Chang. 2010. A full parallel priority encoder design used in comparator. In2010 53rd IEEE International Midwest Symposium on Circuits and Systems. IEEE, 877–880

  63. [63]

    Tyler Hunt, Zhipeng Jia, Vance Miller, Ariel Szekely, Yige Hu, Christopher J Rossbach, and Emmett Witchel. 2020. Telekine: Secure computing with cloud {GPUs}. In17th USENIX Symposium on Networked Systems Design and Imple- mentation (NSDI 20). 817–833

  64. [64]

    Tianlin Huo, Xiaoni Meng, Wenhao Wang, Chunliang Hao, Pei Zhao, Jian Zhai, and Mingshu Li. 2020. Bluethunder: A 2-level directional predictor based side- channel attack against sgx.IACR Transactions on Cryptographic Hardware and Embedded Systems(2020), 321–347

  65. [65]

    Apple Inc. 2025. NSUbiquitousKeyValueStore Documentation. https://developer. apple.com/documentation/foundation/nsubiquitouskeyvaluestore. Accessed: 2025-03-23

  66. [66]

    Andrei Ivanov, Benjamin Rothenberger, Arnaud Dethise, Marco Canini, Torsten Hoefler, and Adrian Perrig. 2023. {SAGE}: Software-based Attestation for {GPU} Execution. In2023 USENIX Annual Technical Conference (USENIX ATC 23). 485–499

  67. [67]

    Insu Jang, Adrian Tang, Taehoon Kim, Simha Sethumadhavan, and Jaehyuk Huh. 2019. Heterogeneous isolated execution for commodity gpus. InProceed- ings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems. 455–468

  68. [68]

    Jin Jiang, Dongsheng He, Yu Hu, Dong Liu, Chenfan Xiao, Hongxiao Bi, Yusong Zhang, Chaoqu Jiang, and Zhijun Fu. 2024. CompassDB: Pioneering High- Performance Key-Value Store with Perfect Hash.arXiv preprint arXiv:2406.18099 (2024)

  69. [69]

    Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’neill. 2016. Generic attacks on secure outsourced databases. InProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 1329–1340

  70. [70]

    Paul Kocher, Jann Horn, Anders Fogh, , Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, and Yuval Yarom. 2019. Spectre Attacks: Exploiting Speculative Exe- cution. In40th IEEE Symposium on Security and Privacy (S&P’19)

  71. [71]

    Evgenios M Kornaropoulos, Nathaniel Moyer, Charalampos Papamanthou, and Alexandros Psomas. 2022. Leakage inversion: Towards quantifying privacy in searchable encryption. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security. 1829–1842

  72. [72]

    Dayeol Lee, Dongha Jung, Ian T Fang, Chia-Che Tsai, and Raluca Ada Popa

  73. [73]

    Dong Uk Lee. 2022. HBM DRAM and 3D Stacked Memory Slides. https:// resourcecenter.sscs.ieee.org/education/short-courses/sscstut20210215 Accessed: 2025-04-07. BOLT : Bandwidth-Optimized Lightning-Fast Oblivious Map powered by Secure HBM Accelerators CCS ’25, October 13–17, 2025, Taipei, Taiwan

  74. [74]

    Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, Hyesoon Kim, and Marcus Peinado. 2017. Inferring fine-grained control flow inside{SGX} enclaves with branch shadowing. In26th USENIX Security Symposium (USENIX Security 17). 557–574

  75. [75]

    Johannes Lengler. 2020. Drift analysis.Theory of evolutionary computation: Recent developments in discrete optimization(2020), 89–131

  76. [76]

    Ge Li, Mohit Tiwari, and Michael Orshansky. 2022. Power-based attacks on spatial dnn accelerators.ACM Journal on Emerging Technologies in Computing Systems (JETC)18, 3 (2022), 1–18

  77. [77]

    Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, and Mike Hamburg. 2018. Meltdown: Reading Kernel Memory from User Space. In27th USENIX Security Symposium (USENIX Security 18)

  78. [78]

    Chang Liu, Austin Harris, Martin Maas, Michael Hicks, Mohit Tiwari, and Elaine Shi. 2015. Ghostrider: A hardware-software system for memory trace oblivious computation.ACM SIGPLAN Notices50, 4 (2015), 87–101

  79. [79]

    Fangfei Liu, Yuval Yarom, Qian Ge, Gernot Heiser, and Ruby B Lee. 2015. Last- level cache side-channel attacks are practical. In2015 IEEE symposium on security and privacy. IEEE, 605–622

  80. [80]

    Haojun Liu, Xinbo Luo, Hongrui Liu, and Xubo Xia. 2021. Merkle tree: A fundamental component of blockchains. In2021 International Conference on Electronic Information Engineering and Computer Science (EIECS). IEEE, 556–561

Showing first 80 references.

This paper was first reviewed by deepseek-v4-flash on August 5, 2026.