{ "schema": "auturnal.deep-research-review.v2", "slug": "oram-access-leakage", "title": "Hiding the Address: Oblivious RAM, Leakage, and the Cost of Access Privacy", "category": "Security & Cryptography", "dek": "A leakage-first analysis of path traffic, trusted state, and the boundaries of oblivious storage.", "abstract": "Oblivious RAM protects a computation's memory-access pattern, but the protection applies to a specified observation interface rather than to every observable aspect of an application. This analytical review examines that boundary through tree-based storage, trusted client state, scheduling, and recovery. Selected original records for Path ORAM, Ring ORAM, Circuit ORAM, lower-bound studies, and the ObliviStore extended abstract anchor a comparison of what different cost measures establish. We separate transferred bytes from dependent interactions and distinguish an address-privacy claim from integrity, durability, and application-level trace privacy. Two reproducible constructed illustrations quantify full-path traffic with a trusted tree prefix and expose equality leakage from a fixed secret placement. The executable checks compare path accounting with explicit enumeration and verify a small distinguishing example; they do not implement or certify a cryptographic protocol. The proposed evaluation combines paired workload traces with active storage fault injection and requires recursion, background work, and recovery to remain visible in the accounting. The resulting framework makes an ORAM deployment reviewable as a leakage contract with explicit resource and failure assumptions. It does not report new measured performance or independently validate the cited security proofs.", "refs": [ "cs2-11-1", "cs2-11-2", "cs2-11-3", "cs2-11-4", "cs2-11-5", "cs2-11-6" ], "sections": [ [ "1. Access privacy begins with the observer", "Encryption answers a question about values; an outsourced computation also exposes events. An observer may see which storage locations are touched, how often requests arrive, their lengths, and when a client stops. The central claim of this manuscript is that an oblivious memory design must name that observation interface before optimizing its bandwidth. A reduction that hides addresses while leaving a secret-dependent request count visible can be correct as a memory primitive and inadequate as an application defense.\n\nWe study a single logical client accessing an array through an untrusted storage service. The client retains secret state, and the storage observer receives physical operations. Multiple independent clients, durable recovery, and network scheduling enter as explicit extensions. Our constructed analysis concerns path traffic and an equality distinguisher; it is neither a new ORAM construction nor an implementation benchmark. Its purpose is to make two frequently conflated costs visible: moving enough blocks to obscure an address and preventing higher layers from revealing the same secret through control flow. A useful deployment contract states which of these responsibilities belongs to each component.", [] ], [ "2. What the principal sources establish", "Path ORAM gives a particularly transparent tree construction: accesses fetch and rewrite a path, while a trusted position map associates logical blocks with leaves. Its stated logarithmic bandwidth result includes a block-size condition, and recursive position maps matter to the small-client claim. Ring ORAM changes the balance of online work and background operations. Circuit ORAM targets circuit complexity as well as storage access, which is relevant when the client computation itself must be represented securely.\n\nThese are different optimization objectives. A bandwidth advantage reported for one parameterization does not imply lower interactive latency, smaller circuits, or less trusted memory in another. We therefore retain three coordinates throughout the analysis: transferred bytes, dependent communication stages, and locally retained state. The inspected Ring and Circuit records establish their research aims and abstract-level results; their proofs were not independently checked here. The Path PDF was inspected for its algorithm and stated parameter qualifications. We use no published performance number as if it were measured by this manuscript, and no historical best-known claim as a present-day ranking.", [ "cs2-11-1", "cs2-11-2", "cs2-11-3" ] ], [ "3. A security game with a deliberate boundary", "Let two logical access sequences have equal length and obey the same public interface restrictions. The adversary receives the physical trace generated from one sequence, chosen by a hidden fair bit. Address privacy asks that efficient distinguishing advantage be negligible. Equal length is consequential: if the interface permits one application branch to make one access and another to make a thousand, the trace length itself identifies the branch before any address is inspected.\n\nOur equation expresses computational indistinguishability rather than asserting identical distributions in every implementation. Correctness is a separate obligation: each read must return the latest logical value, except for an explicitly bounded failure event if the construction admits one. Integrity and freshness are additional obligations against a malicious server; encrypting and shuffling blocks alone does not establish either. The observer should also be told whether reads and writes, retries, error messages, and termination are visible. An omitted observation is not harmless by default. It is an assumption that must be defended at the system boundary or added to the leakage function.", [ "cs2-11-1" ] ], [ "4. Lower bounds require their parameters", "Komargodski and Lin explicitly analyze the relationship between logical word size, physical cell size, and trusted storage. Their result warns against treating a logarithmic slogan as a universal constant-factor budget. Jacob, Larsen, and Nielsen study oblivious data structures directly, including stacks and queues, so the possibility of specialized structure does not automatically imply constant overhead in their model.\n\nFor an evaluator, the practical consequence is a parameter ledger. An implementation with large physical blocks may move fewer cells while transferring more bytes. A design with a large private cache may legitimately outperform a small-client baseline without contradicting its lower bound. An offline algorithm that knows the complete request sequence solves a different problem from an online service receiving unpredictable operations. We do not reproduce either proof or apply the printed asymptotic formula outside its hypotheses. Instead, every plotted quantity below has a physical unit and a finite definition. This avoids a common analytical mistake: comparing an asymptotic theorem, a simulation throughput number, and a storage invoice as though all three measured the same resource.", [ "cs2-11-4", "cs2-11-5" ] ], [ "5. Tree traffic as an auditable model", "Consider a full binary tree with height L, so a root-to-leaf path contains L plus one buckets. Each bucket holds Z fixed-size slots, and each slot transfers B bytes including whatever metadata the evaluator chooses to include. Reading and rewriting the whole path transfers twice the path capacity. If the top h complete levels remain in trusted memory, only L plus one minus h levels traverse the link. This is a deliberately simple accounting identity, not a complete Path ORAM performance model.\n\nThe model assumes every remaining bucket is transferred in full, dummy slots are indistinguishable from occupied slots at the interface, and encryption does not expand the supplied slot size. It excludes position-map recursion, integrity-tree traffic, initialization, and stash spills. Those exclusions make it a lower accounting layer that can be extended transparently. Adding each excluded cost as a named term is preferable to multiplying by an unexplained overhead factor. The first figure varies the tree height while preserving bucket capacity and slot size; its lines compare two trusted-prefix budgets under identical conventions.", [ "cs2-11-1" ] ], [ "6. Constructed path-budget example", "Set the logical capacity parameter to 2 to the twentieth blocks, use height twenty, five slots per bucket, and slots of 4096 bytes. The complete path read and rewrite moves 860160 bytes, or 840 KiB. Retaining the top four levels reduces link traffic to 696320 bytes, or 680 KiB. These are generated arithmetic results; they do not predict request latency on any device. The difference is 160 KiB per logical operation under this accounting convention.\n\nThe trusted prefix itself contains fifteen buckets and consumes 307200 bytes, or 300 KiB. It therefore purchases a traffic saving by moving persistent responsibility into the client. A client restart must reconstruct or recover that prefix safely, and multiple clients cannot each use inconsistent private versions. If only a fraction of the apparent cache hits is served locally, the figure overstates the saving. If metadata increases each transmitted slot, both lines rise proportionally. The point of the example is a reviewable trade: one can state exactly which bytes disappear from the untrusted link and which state must remain coherent elsewhere.", [] ], [ "7. The equality counterexample", "Suppose a designer encrypts every block and assigns it a secret random physical address once. This hides the address label but preserves equality: two requests to the same logical block revisit the same physical label. Compare a repeated logical access with two distinct logical accesses under a fixed permutation. The observer decides which sequence occurred by comparing the two labels, without decrypting any value. This is a real counterexample to the proposition that randomized placement alone hides access patterns.\n\nOur second figure isolates that mechanism. A reused label produces equality with probability one. Two independent uniform labels from a space of 2 to the k labels collide with probability 2 to the minus k. At k equal to ten, that probability is one over 1024. The independent-label experiment is an idealized comparison, not an ORAM implementation: arbitrary reassignment would still need to preserve data and avoid revealing where it moved. Exhaustive enumeration over a small label space verifies the comparison and its limiting case. The result illustrates why remapping must be part of a correct storage protocol rather than a cosmetic renaming step.", [] ], [ "8. The stash is a correctness obligation", "A tree design may temporarily retain blocks that cannot be placed in the accessed path. Such a stash is trusted state with both a capacity requirement and a failure policy. The Path paper supplies a probabilistic analysis under its stated construction and parameter choices. Our model does not estimate stash occupancy, reproduce its tail bound, or infer that a chosen capacity is safe from a short random trace.\n\nFor a service, even a well-founded per-operation tail statement must be translated into an operational horizon. A union bound can combine event probabilities without assuming independence, but it can be loose, and correlated failures require careful interpretation. A million successful accesses do not certify a tiny failure probability. The evaluator should distinguish data loss, abort, retry, and a spill to untrusted storage; a visible special recovery path may itself disclose workload information. Stash contents also participate in durability and key rotation. Treating them as an implementation detail permits a system to satisfy its advertised byte budget by silently discarding the very state needed for correctness.", [ "cs2-11-1" ] ], [ "9. Recursion and trusted state", "A position map can be larger than the private memory budget. Recursively storing that map in smaller ORAMs trades trusted capacity for additional accesses, and the recursion bottom remains a real piece of trusted state. The Path source explicitly conditions its asymptotic comparison on block sizes and recursion choices. Our complete-path line intentionally leaves this cost separate, so it must not be called the end-to-end bandwidth of recursive Path ORAM.\n\nA useful accounting experiment records each recursion level as a separate stream: map-entry size, entries packed per block, tree height, and bytes exchanged. It then totals the streams without counting the private bottom as remote traffic. This exposes whether a large application block amortizes metadata effectively or merely obscures it in a denominator. It also clarifies an engineering alternative: accepting more local memory may simplify recovery and reduce communication, but it enlarges the trusted-state management problem. The right comparison holds the security interface and available trusted resources fixed, then varies construction choices. Otherwise an apparently faster algorithm may simply have received a more generous private-memory budget.", [ "cs2-11-1" ] ], [ "10. Scheduling and concurrency can reopen leakage", "The ObliviStore extended abstract explicitly identifies timing and out-of-order I/O as security concerns when making storage operations asynchronous. Its contribution therefore concerns scheduling as well as address selection. We inspected the three-page extended abstract, rather than conflating that artifact with the longer IEEE publication, and use it only for this architectural point.\n\nConsider an author-constructed service whose two logical operation classes use identical address-hiding operations but different queue priorities. A passive observer who measures completion intervals can classify requests even when each individual address trace is protected. Similarly, coalescing only repeated reads exposes a workload-dependent number of physical operations. Padding, batching, and background work can reduce such signals, but their schedules must be defined using permitted public information. A queue that stops its cover traffic exactly when a secret task finishes reveals termination. A practical test should therefore compare whole sessions, including idle periods and retries, rather than comparing equal-sized successful requests after the distinguishing events have been filtered out.", [ "cs2-11-6" ] ], [ "11. Integrity, replay, and recovery", "An untrusted server may return old ciphertexts or omit a requested write. Address privacy does not make such behavior impossible. Authenticated state must identify the expected version, and the client must preserve enough trustworthy commitment information to detect rollback after a restart. This is a separate design analysis, not a claim that the source constructions omit protections they actually provide.\n\nAn instructive crash schedule interrupts a logical update after some path buckets have been rewritten but before the position map is durably committed. Recovery must not pair a new mapping with an incompatible old tree. An implementation may use transactional logging, versioned roots, or another proven mechanism, but the resulting trace and metadata traffic belong in its advertised contract. Repeating an operation after an uncertain acknowledgment also raises idempotency questions for the application above the array interface. A bank transfer built on two private array writes is not automatically transactional. Reviewing these boundaries together prevents a successful access-pattern experiment from being used as evidence for unrelated durability or application-consistency claims.", [] ], [ "12. A falsifiable evaluation design", "The proposed evaluation first fixes two explicit adversaries: a passive trace observer and an active storage manipulator. For the passive case, collect addresses, lengths, issue times, completion times, and errors for paired workloads with equal public shape. Preserve entire traces, then preregister classifiers and held-out workloads. A classifier succeeding beyond its stated uncertainty is evidence against the tested leakage contract; failure to distinguish is limited evidence, not a cryptographic proof.\n\nFor the active case, inject stale reads, reordered writes, interrupted eviction, and restart at each documented commit boundary. Check logical array contents against a plain reference model while accounting for allowed aborts. Measure recursive traffic, trusted-memory high-water marks, and background traffic independently. Publish parameter files and model source so that claimed byte savings can be recomputed. Evaluation should include adversarial repetition and hot-set changes, not only uniformly random addresses. A throughput result that excludes recovery or cover traffic should identify that boundary in its caption. The intended output is a collection of falsifiable claims whose failure modes remain visible, rather than one score labelled secure performance.", [] ], [ "13. What the executable checks establish", "The accompanying program uses only standard-library arithmetic and enumeration. It constructs explicit binary-tree paths to check the bucket-count formula over a range of heights and trusted-prefix depths. It also enumerates ordered label pairs and verifies the ideal collision probability independently of the closed form. A separate equality test demonstrates the fixed-placement counterexample. These checks validate the numerical exposition and a small observational argument.\n\nThey do not implement encryption, random remapping, stash eviction, authentication, or recursive position maps. Consequently, passing them does not certify an ORAM, and their case count is not a security level. This narrow scope is useful: a reviewer can inspect every mechanism used to produce the two figures without installing a simulator or trusting a plotting pipeline. A future implementation study could consume the same parameter definitions and compare observed traffic against this baseline, documenting each additional byte category. A discrepancy would then lead to a concrete accounting question instead of being dismissed as a mysterious constant factor.", [] ], [ "14. Design implications and remaining questions", "The defensible deployment decision is a budgeted leakage contract. Specify which observations remain public, how long the service must operate before reinitialization, what state survives crashes, and how integrity is enforced. Then select a construction using compatible measures of bandwidth, interaction, and trusted state. No single figure here chooses between Path, Ring, Circuit, or a distributed design, because their full implementation and adversary assumptions were not normalized experimentally.\n\nThree questions remain especially actionable. How much trusted state minimizes total recovery-adjusted cost for a particular service? Which batching schedules preserve the declared leakage interface under realistic concurrency? Which application operators can avoid secret-dependent access counts without unacceptable padding? Each question admits a concrete experiment or proof obligation and cannot be answered by the word encrypted alone. The manuscript's contribution is this decomposition and two transparent analytical checks. It supports rigorous evaluation of access privacy while keeping the gap between a protected memory abstraction and a private application explicit enough to test.", [] ] ], "section_kinds": [ "author_analysis_or_verification_proposal", "source_based_review", "author_analysis_or_verification_proposal", "source_based_review", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "source_based_review", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal", "author_analysis_or_verification_proposal" ], "equations": [ { "tex": "\\left|\\Pr[A(T(a))=1]-\\Pr[A(T(b))=1]\\right|\\leq\\operatorname{negl}(\\lambda)", "explanation": "Equal-length logical sequences a and b; T is the declared physical trace and A an efficient observer. The security parameter is lambda; unmodeled timing is not covered." }, { "tex": "C_{\\mathrm{path}}=2ZB(L+1-h)", "explanation": "Bytes per full read-and-rewrite of uncached path levels; B bytes per slot, Z slots per bucket, h fully trusted top levels, 0 <= h <= L+1; excludes recursion and integrity traffic." }, { "tex": "M_{\\mathrm{prefix}}=ZB(2^h-1)", "explanation": "Bytes of complete trusted prefix; no compression or metadata outside B." }, { "tex": "\\Pr[U_1=U_2]=2^{-k}", "explanation": "Two independent uniform k-bit labels; this ideal experiment is not an ORAM construction." }, { "tex": "\\Pr[\\bigcup_{i=1}^{q} F_i]\\leq\\sum_{i=1}^{q}\\Pr[F_i]", "explanation": "Union bound for q failure events; needs valid component bounds and does not assume independence." } ], "table": { "headers": [ "Quantity", "Constructed setting", "Value" ], "rows": [ [ "Full path traffic", "L=20, Z=5, B=4096, h=0", "860160 bytes" ], [ "Trusted prefix traffic", "Same, h=4", "696320 bytes" ], [ "Trusted prefix state", "h=4", "307200 bytes" ], [ "Ideal equality", "k=10", "1/1024" ] ] }, "protocol": [ "Declare the complete observer interface, including errors and timing.", "Freeze block sizes, bucket sizes, tree heights, and trusted-memory budgets.", "Run the deterministic model and retain its JSON output.", "Instrument recursion, integrity, dummy, and recovery traffic separately.", "Construct equal-public-shape repeated, hot-set, and changing-hot-set workloads.", "Preregister trace classifiers and use held-out paired workloads.", "Inject stale ciphertexts, reordered writes, and interrupted eviction.", "Restart at each documented durability boundary and compare logical contents with a plain array.", "Report permitted aborts separately from incorrect reads and silent rollback.", "Publish parameters and raw accounting categories without claiming that nondistinguishability tests prove security." ], "limitations": [ "No cryptographic ORAM implementation is supplied.", "The byte model excludes recursion, authentication, initialization, and stash spills.", "Independent labels are an idealized explanatory experiment.", "No source proof was independently verified.", "Ring and Circuit PDFs were unavailable; only their original abstracts and metadata were inspected.", "The cited ObliviStore artifact is a three-page extended abstract." ], "evidence": [ { "source": "cs2-11-1", "result": "Path accesses read and rewrite a tree path; recursion and block size qualify the stated efficiency.", "boundary": "Not an end-to-end cost for our constructed parameters.", "locator": "PDF sections 1, 3 and recursion discussion" }, { "source": "cs2-11-2", "result": "Ring ORAM studies bandwidth and online/background work tradeoffs.", "boundary": "Abstract-level inspection does not verify its proof or contemporary ranking.", "locator": "Original ePrint abstract" }, { "source": "cs2-11-3", "result": "Circuit ORAM targets circuit size and specific tightness regimes.", "boundary": "Does not make all ORAM costs interchangeable.", "locator": "Original ePrint abstract" }, { "source": "cs2-11-4", "result": "Logical/physical word sizes and private memory are explicit lower-bound parameters.", "boundary": "No unrestricted numerical lower bound is inferred.", "locator": "Original ePrint abstract parameter statement" }, { "source": "cs2-11-5", "result": "Oblivious stacks and queues are among studied lower-bound targets.", "boundary": "Scope remains the paper model.", "locator": "arXiv abstract" }, { "source": "cs2-11-6", "result": "Asynchronous I/O requires attention to scheduling leakage.", "boundary": "The extended abstract is not the full IEEE article.", "locator": "Extended abstract section 1.1" } ], "research_questions": [ "Which trusted-prefix budget minimizes recovery-adjusted cost under a fixed leakage contract?", "Which concurrent schedules preserve a declared trace interface?", "How can application operators eliminate secret-dependent access counts economically?" ], "kind": "ai_assisted_research_guide", "author": "Codex (AI)", "original_language": "en", "created_date": "2026-10-25", "published_date": null, "publication_status": "local_draft_pending_owner_upload", "version": 1, "previous_version": null, "analytic": "oram-access-leakage", "peer_reviewed": false, "journal_publication": false, "disclosure": { "authorship": "Written by Codex (AI), with source-based technical synthesis and explicit author-constructed models.", "figures": "Reproducible analytical illustrations, not measured system benchmarks.", "review": "Codex team technical checks; no independent human or journal peer review." }, "review_scope": "Selected original records and explicitly identified sections were inspected; this is not an exhaustive systematic review or independent verification of source proofs.", "revision_note": "Initial local English manuscript." }