Oblivious RAM

An oblivious RAM (ORAM) is a client algorithm that serves reads and writes to a virtual array of blocks by issuing reads and writes to a physical array of blocks held by a server, so that the sequence of physical addresses it touches reveals nothing about the virtual operations. It was introduced by Gol87 and Ost90, whose results GO96 unify and extend.

Note: Oblivious RAM schemes can provide statistical or unconditional security against adversaries who only know which array indices are accessed. However, in practice one almost always needs to deploy ORAM together with standard symmetric encryption.

Syntax

Throughout, we use the following notation. All oblivious RAM schemes are defined with respect to a key space , state space , virtual array size and blocks , and physical array size and blocks . We additionally assume and , and write for the block length in bits. Furthermore, we define the sets:

These are the allowed operations for the virtual array () and the physical array (). An -round Oblivious RAM (ORAM) is a tuple of efficient functions such that:

  • , a randomized function outputting a key .
  • for , a randomized function taking a state , a virtual operation and the answers of the earlier rounds, and outputting a new state and a finite sequence of physical operations.
  • , a function outputting a new state and an answer .

The above functions describe the processing of the Oblivious RAM query. They are used in the following way to process a virtual operation , for a physical array . For , run and execute the operations of on in order: a read returns , and a write sets . Let be the values the reads of return. Finally, run and return . The client starts from and for a fixed .

The access pattern of is , where maps each read to and each write to : it records the index and type of every physical operation, not its contents.

Properties

Correctness

Fix and a sequence , processed in order from the initial state under with answers . The correct answer to is when is a write; when is a read , it is the block of the last write among , and if there is none. An ORAM is -correct if for all and ,

over the coins of , and . It is -correct if is negligible for every polynomial . When , we say is perfectly correct.

Security

\begin{algorithm}
\algname{Game}
\caption{$\Game^{\mathrm{oram}}_{\Pi,\calA}(\secpar)$}
\begin{algorithmic}
\State $K \gets \Gen(1^\secpar)$; $\st \gets \bot$; $M_2 \gets (b_0, \ldots, b_0)$
\State $b \getsr \bits$
\State $b' \gets \calA^{\calO_b}(1^\secpar)$
\Return $[b' = b]$
\end{algorithmic}
\end{algorithm}
\begin{algorithm}
\algname{Oracle}
\caption{$\calO_b(o_0, o_1)$}
\begin{algorithmic}
\State process $o_b \in \Ops_1$ under $K$, updating $\st$ and $M_2$
\Comment{the answer $y$ is withheld: it differs between the worlds}
\Return $\mathrm{ap}(o_b)$
\end{algorithmic}
\end{algorithm}

The adversary chooses the two operation sequences adaptively, one pair of operations at a time, and sees the access pattern of each operation of the sequence selects. An ORAM is secure if it is -correct and for all efficient ,

is negligible.

With and , the linear scan, which on every operation reads all cells in a first round and rewrites all of them in a second, is a perfectly correct and perfectly secure two-round ORAM with bandwidth blowup — folklore. A client that keeps all blocks in and issues no physical operations is perfectly secure too — folklore.

Efficiency

For a sequence , let be the physical operations issued in round of .

  • The bandwidth blowup on is , and the amortized bandwidth blowup is its maximum over all sequences of operations with . The worst-case bandwidth blowup is the maximum of over all sequences, all and all coins.
  • The client storage is , the largest state kept between operations, in bits or in blocks of bits; the key length is reported separately. Answers held within one operation are not counted, since the bandwidth bounds them.
  • A client has blocks of memory at every step, within an operation as well as between operations, as a RAM with a constant number of registers does, if each round issues physical operations, uses only through and , uses them only through and , and has blocks throughout; the number of rounds may then grow with .
  • The server storage is bits, and the round complexity is .

Variations

Statistically secure ORAM

An ORAM is statistically secure if it is -correct and is negligible for every adversary , possibly computationally unbounded, that makes polynomially many oracle queries. It is perfectly secure if in addition for every such .

Offline ORAM

An offline ORAM learns the indices and types of the whole operation sequence before processing starts, but each written block only with its operation: and take the current operation together with in place of , with as in the definition of the access pattern. Knowing the written blocks in advance would let the client answer every read from them without touching the server. In the security game the adversary submits one pair of sequences of equal length and receives the access pattern of the whole execution on one of them. BN16’s offline ORAMs also know the written blocks in advance (offline ORAM with fixed instructions) — BN16. The ORAMs defined above, which process each operation before receiving the next, are online — BN16.

\begin{algorithm}
\algname{Game}
\caption{$\Game^{\mathrm{oram\text{-}off}}_{\Pi,\calA}(\secpar)$}
\begin{algorithmic}
\State $K \gets \Gen(1^\secpar)$; $b \getsr \bits$
\State $(\mathbf{o}_0, \mathbf{o}_1, \stA) \gets \calA(1^\secpar)$
\Comment{$\mathbf{o}_0, \mathbf{o}_1 \in \Ops_1^q$ for the same $q$}
\State process $\mathbf{o}_b$ under $K$ from $\st = \bot$ and $M_2 = (b_0, \ldots, b_0)$
\State $\mathit{ap} \gets (\mathrm{ap}(o_1), \ldots, \mathrm{ap}(o_q))$ for the operations of $\mathbf{o}_b$
\State $b' \gets \calA(\stA, \mathit{ap})$
\Return $[b' = b]$
\end{algorithmic}
\end{algorithm}

An offline ORAM is secure if it is -correct and for all efficient ,

is negligible; statistical and perfect security are defined as for online ORAMs. Every online ORAM yields an offline ORAM with the same overhead — folklore.

Offline ORAM with fixed instructions

An offline ORAM with fixed instructions learns the whole operation sequence before processing starts, written blocks included: and take the current operation together with in place of . The virtual array starts with contents that the client sees only through its physical reads: with and , the physical array starts as , and the correct answer to a read with no earlier write to is in place of . Bandwidth blowup and client storage are maximized over as well as over the sequence. From an empty array, the client could answer every read from alone. BN16’s offline programs fix every fetch and store instruction in advance, the value of every store included — BN16.

\begin{algorithm}
\algname{Game}
\caption{$\Game^{\mathrm{oram\text{-}fix}}_{\Pi,\calA}(\secpar)$}
\begin{algorithmic}
\State $K \gets \Gen(1^\secpar)$; $b \getsr \bits$
\State $((D_0, \mathbf{o}_0), (D_1, \mathbf{o}_1), \stA) \gets \calA(1^\secpar)$
\Comment{$D_0, D_1 \in \calB_1^{N_1}$; $\mathbf{o}_0, \mathbf{o}_1 \in \Ops_1^q$ for the same $q$}
\State $M_2 \gets (D_b[1], \ldots, D_b[N_1], b_0, \ldots, b_0)$
\State process $\mathbf{o}_b$ under $K$ from $\st = \bot$ and $M_2$, giving $\Acc_j$ and $\Out$ all of $\mathbf{o}_b$
\State $\mathit{ap} \gets (\mathrm{ap}(o_1), \ldots, \mathrm{ap}(o_q))$ for the operations of $\mathbf{o}_b$
\State $b' \gets \calA(\stA, \mathit{ap})$
\Return $[b' = b]$
\end{algorithmic}
\end{algorithm}

An offline ORAM with fixed instructions is secure if it is -correct for every , with the answers above, and for all efficient ,

is negligible; statistical and perfect security are defined as for online ORAMs.

Sublogarithmic-overhead offline ORAM with fixed instructions

A sublogarithmic-overhead offline ORAM with fixed instructions is a secure offline ORAM with fixed instructions, with any encoding of the data, whose physical cells have the size of its blocks (), with blocks of client memory at every step (Efficiency), block length , and amortized bandwidth blowup over every sequence of operations with . BN16’s client likewise has a constant number of registers — BN16. Bounding only the client storage, the state kept between operations, would admit a client that, every operations, reads all of in one round and in the next writes the answers of the next operations to cells, one per operation, which each of those operations then reads: a fixed access pattern with amortized bandwidth blowup. Small sorting circuits give a sublogarithmic-overhead offline ORAM with fixed instructions (Small sorting circuits ⇒ sublogarithmic-overhead offline ORAM with fixed instructions), and proving that none exists would need a superlinear lower bound on the size of sorting circuits — BN16. The construction relies on the store values being fixed in advance, and BN16 pose its extension to a more expressive offline class as an open question, so it is not known to give an offline ORAM that learns each written block only with its operation — BN16.

Balls-and-bins ORAM

In a balls-and-bins ORAM, , so each physical cell holds one virtual block (a ball) or the empty marker . The client holds balls together with metadata that does not depend on ball contents. A physical read copies the cell’s ball into client memory, and a physical write stores or a ball the client holds. Which physical operations are issued depends only on , the client’s coins, the metadata, and the indices and types of the virtual operations, never on ball contents: the ORAM moves balls and never encodes them — GO96, BN16. A balls-and-bins ORAM does not duplicate balls if it never keeps two copies of a ball, at the server or the client — CDH20.

Sublogarithmic-overhead balls-and-bins ORAM

A sublogarithmic-overhead balls-and-bins ORAM is a statistically secure offline balls-and-bins ORAM with blocks of client memory at every step and amortized bandwidth blowup over sequences of operations. None exists (No reduction from ORAM to sublogarithmic-overhead balls-and-bins ORAM) — GO96.

One-round ORAM

A one-round ORAM is an ORAM with : all physical operations for a virtual operation are chosen before any of them is answered, so no physical address issued while processing depends on a block read while processing .

Sub-square-root one-round balls-and-bins ORAM

A sub-square-root one-round balls-and-bins ORAM is a statistically secure one-round balls-and-bins ORAM that does not duplicate balls, with worst-case bandwidth blowup and client storage of blocks. None exists (No reduction from ORAM to sub-square-root one-round balls-and-bins ORAM) — CDH20.

Polylogarithmic-overhead ORAM

A polylogarithmic-overhead ORAM is a secure ORAM with block length , client storage of blocks and amortized bandwidth blowup over every sequence of operations with , whose key has length a fixed polynomial in , independent of .

Logarithmic-overhead ORAM

A logarithmic-overhead ORAM is a secure ORAM with block length , client storage of blocks and amortized bandwidth blowup over every sequence of operations with , whose key has length a fixed polynomial in , independent of . One exists if a PRF does (PRF ⇒ logarithmic-overhead ORAM (OptORAMa)) — AKL+20.

Sublogarithmic-overhead ORAM

A sublogarithmic-overhead ORAM is a secure online ORAM with blocks of bits and physical cells of any size , whose client memory of bits satisfies for a constant , and whose amortized bandwidth blowup is . None exists (No reduction from ORAM to sublogarithmic-overhead ORAM) — LN18.

ORAM with server computation

In an ORAM with server computation, also contains evaluation requests for in a fixed class of efficiently computable functions , on which the server sets . The adversary is a semi-honest server: in the security game, returns its entire view, every physical operation with its contents together with , in place of . The bandwidth counts the bits the client sends and receives, request descriptions included, and not the server’s work.

Constant-bandwidth ORAM

A constant-bandwidth ORAM is an efficient ORAM with server computation, secure against a semi-honest server, with worst-case bandwidth blowup and client storage of blocks, for some block length . Onion ORAM is one if DCR holds (DCR ⇒ constant-bandwidth ORAM (Onion ORAM)) — DDF+16.

Other results

  • Every statistically secure balls-and-bins ORAM with blocks of client memory at every step, even an offline one, has amortized bandwidth blowup (No reduction from ORAM to sublogarithmic-overhead balls-and-bins ORAM) — GO96. For offline ORAMs with fixed instructions that may encode the data, such a bound would imply superlinear lower bounds on the size of sorting circuits (Small sorting circuits ⇒ sublogarithmic-overhead offline ORAM with fixed instructions) — BN16.

  • Every online ORAM with client memory has amortized bandwidth blowup , even with computational security and an arbitrary encoding of the data (No reduction from ORAM to sublogarithmic-overhead ORAM) — LN18. The bound holds even against a server that does not know which physical operations belong to which virtual operation — HKKS19.

  • Every online ORAM makes amortized memory probes per operation, where is the number of virtual cells, and the virtual and physical cell sizes and the client storage in bits; the bound is tight up to the factor and extends to non-colluding servers. For and , some offline ORAM makes probes per operation on average while every online one makes , the first separation of online and offline ORAM for any parameters — KL21.

  • An online ORAM whose server only stores data and whose reads, but not writes, have overhead follows from small sorting circuits together with locally decodable codes with parameters not known to exist, so a lower bound for online read-only ORAM would need a new circuit lower bound or would rule out such codes. LN18’s bound leaves online read-only ORAM open, while GO96’s balls-and-bins bound extends to offline and read-only ORAM — WW18.

  • Every one-round balls-and-bins ORAM that does not duplicate balls has bandwidth or client memory (No reduction from ORAM to sub-square-root one-round balls-and-bins ORAM) — CDH20.

  • The hierarchical ORAM has polylogarithmic overhead given a PRF (PRF ⇒ polylogarithmic-overhead ORAM (hierarchical ORAM)) — GO96. OptORAMa has amortized bandwidth blowup given a PRF (PRF ⇒ logarithmic-overhead ORAM (OptORAMa)) — AKL+20, improving the of PanORAMa — PPRY18.

  • A coin-flipping RAM simulates any RAM obliviously and online with polylogarithmic slowdown in time and space and no cryptographic assumption; with memory locations it fails with probability at most — Ajt10.

  • There is an ORAM whose access pattern is perfectly hidden, in the information-theoretic sense, without a random oracle, and DMN11 lower-bound the randomness an information-theoretically secure ORAM needs — DMN11.

  • There is a statistically secure ORAM with overhead — CLP14, building on the tree-based ORAM of SCSL11, which has polylogarithmic worst-case cost with constant client storage — SCSL11.

  • Path ORAM is statistically secure, encryption of the blocks aside. With the position map on the client, each access reads and writes one root-to-leaf path of its tree, blocks for buckets of blocks — SDS+13. With blocks of bits for and the position map stored recursively in smaller Path ORAMs, there are two parameter sets, according to where the stashes of the recursive levels are kept, and each fails, by overflowing a stash, with probability — SDS+13:

    Stashes keptBandwidth blowupClient storage (blocks)
    on the client
    on the server
  • For a RAM with words of bits, for a constant , Circuit ORAM gives an ORAM with words of client storage that runs steps in time with negligible statistical failure probability, or with inverse-polynomial failure probability, showing that the Goldreich–Ostrovsky bound is tight for some parameter ranges. For blocks of bits its circuit size is with failure probability — WCS15.

  • There is an oblivious parallel RAM compiler with polylogarithmic slowdown in total and parallel complexity whose memory-access distribution is statistically close to one independent of the data, and from it and IBE a garbled parallel RAM compiler — BCP16.

  • Garbled RAM, which garbles a RAM program, its input and its memory so that the access pattern stays hidden too, exists if IBE does (IBE ⇒ garbled RAM) — GHL+14, and if one-way functions do, using them only as a black box (OWF ⇒ garbled RAM (black-box)) — GLO15.

  • Functions that a RAM computes in sublinear time have secure two-party computation in amortized sublinear time: the parties run generic secure two-party computation on top of an ORAM, each keeping state essentially linear in its own input, and the optimized protocol combines Yao’s garbled circuits with the ORAM of SCSL11 — GKK+12, building on an idea of OS97.

  • Private information storage gives private reads and writes to data held by several non-communicating databases, with information-theoretic privacy: any retrieval-only -database scheme with communication yields a -database read/write scheme with communication , and no sublinear bounds for private information storage were known before — OS97.

  • Floram is a distributed ORAM for two-party secure computation built from the function secret sharing of BGI15; it needs much less secure computation per access, at the cost of local memory operations, and outperforms Circuit ORAM and square-root ORAM for datasets of 32 KiB or more — DS17.

Participates in

Produces Oblivious RAM

Barriers