Path ORAM:An Extremely Simple Oblivious RAM Protocol

Path ORAM:
An Extremely Simple Oblivious RAM Protocol

Emil Stefanov, Marten van Dijk, Elaine Shi, T-H. Hubert Chan, Christopher Fletcher,
Ling Ren, Xiangyao Yu, Srinivas Devadas

UC Berkeley          UConn          UMD          University of Hong Kong          MIT CSAIL
Our algorithm first appeared on February 23, 2012 on

We present Path ORAM, an extremely simple Oblivious RAM protocol with a small amount of client storage. Partly due to its simplicity, Path ORAM is the most practical ORAM scheme known to date with small client storage. We formally prove that Path ORAM has a bandwidth cost for blocks of size bits. For such block sizes, Path ORAM is asymptotically better than the best known ORAM schemes with small client storage. Due to its practicality, Path ORAM has been adopted in the design of secure processors since its proposal.

1 Introduction

It is well-known that data encryption alone is often not enough to protect users’ privacy in outsourced storage applications. The sequence of storage locations accessed by the client (i.e., access pattern) can leak a significant amount of sensitive information about the unencrypted data through statistical inference. For example, Islam et. al. demonstrated that by observing accesses to an encrypted email repository, an adversary can infer as much as 80% of the search queries [22].

Oblivious RAM (ORAM) algorithms, first proposed by Goldreich and Ostrovsky [14], allow a client to conceal its access pattern to the remote storage by continuously shuffling and re-encrypting data as they are accessed. An adversary can observe the physical storage locations accessed, but the ORAM algorithm ensures that the adversary has negligible probability of learning anything about the true (logical) access pattern. Since its proposal, the research community has strived to find an ORAM scheme that is not only theoretically interesting, but also practical [18, 27, 23, 16, 7, 4, 38, 36, 15, 13, 26, 28, 37, 17, 35, 31, 34, 24, 39].

In this paper, we propose a novel ORAM algorithm called Path ORAM111Our construction is called Path ORAM because data on the server is always accessed in the form of tree paths.. This is to date the most practical ORAM construction under small client storage. We prove theoretical bounds on its performance and also present matching experimental results.

Path ORAM makes the following contributions:

ORAM Scheme Client Storage Read & Write Bandwidth
(# blocks of size ) (# blocks of size )
Kushilevitz et al. [23] ()
Gentry et al. [12] ()
Chung et al. [5] ()
(concurrent work)
Recursive Path ORAM
for small blocks,
Recursive Path ORAM
for moderately sized blocks,
(we use a block size of during recursion)
Table 1: Comparison to other ORAM schemes. is the total number of blocks and is the block size (in bits). The failure probability is set to in this table, i.e., negligible in . This table assumes that the stashes are stored on the client side.

Simplicity and practical efficiency

In comparison to other ORAM algorithms, our construction is arguably much simpler. Although we have no formal way of measuring its simplicity, the core of the Path ORAM algorithm can be described in just 16 lines of pseudocode (see Figure 1) and our construction does not require performing sophisticated deamortized oblivious sorting and oblivious cuckoo hash table construction like many existing ORAM algorithms [14, 18, 27, 23, 16, 7, 4, 38, 36, 15, 13, 26, 28, 37, 17]. Instead, each ORAM access can be expressed as simply fetching and storing a single path in a tree stored remotely on the server. Path ORAM’s simplicity makes it more practical than any existing ORAM construction with small (i.e., constant or poly-logarithmic) local storage.

Asymptotic efficiency

We prove that for a reasonably large block size bits where is the total number of blocks (e.g., 4KB blocks), recursive Path ORAM achieves an asymptotic bandwidth cost of blocks, and consumes blocks of client-side storage222 Throughout this paper, when we write the notation , we mean that for any function , it holds that . Unless otherwise stated, all logarithms are assumed to be in base 2.. In other words, to access a single logical block, the client needs to access physical blocks to hide its access patterns from the storage server. The above result achieves a failure probability of , negligible in .

As pointed out later in Section 1.1, our result outperforms the best known ORAM for small client storage [23], both in terms of asymptotics and practicality, for reasonably large block sizes, i.e., block sizes typically encountered in practical applications.

Practical and theoretic impact of Path ORAM

Since we first proposed Path ORAM [33] in February 2012, it has made both a practical and a theoretic impact in the community.

On the practical side, Path ORAM is the most suitable known algorithm for hardware ORAM implementations due to its conceptual simplicity, small client storage, and practical efficiency. Ren et al. built a simulator for an ORAM-enabled secure processor based on the Path ORAM algorithm [30] and the Ascend processor architecture [10, 11] uses Path ORAM as a primitive. Maas et al. [25] implemented Path ORAM on a secure processor using FPGAs and the Convey platform.

On the theoretic side, subsequent to the proposal of Path ORAM, several theoretic works adopted the same idea of path eviction in their ORAM constructions — notably the works by Gentry et al. [12] and Chung et al. [6, 5]. These two works also try to improve ORAM bounds based on the binary tree construction by Shi et al. [31]; however, as pointed out in Section 1.1 our bound is asymptotically better than those by Gentry et al. [12] and Chung et al. [6, 5]. Gentry’s Path ORAM variant construction has also been applied to secure multiparty computation [12].

Novel proof techniques

Although our construction is simple, the proof for upper bounding the client storage is quite intricate and interesting. Our proof relies on an abstract infinite ORAM construction used only for analyzing the stash usage of a non-recursive Path ORAM. For a non-recursive Path ORAM, we show that during a particular operation, the probability that the stash stores more than blocks is at most . For certain choices of parameters (including ) and data blocks, our recursive Path ORAM construction has at most levels, the stash at the client storage has a capacity of blocks, the server storage is blocks, and the bandwidth is blocks per load/store operation. For load/store operations, a simple union bound can show that this recursive Path ORAM fails during one of the load/store operations (due to exceeding stash capacity) with probability at most . Choosing can make the failure probability negligible. We shall refine the parameters and do a more careful analysis to achieve blocks of client storage in the recursive construction. Our empirical results in Section 7 indicate that the constants in practice are even lower than our theoretic bounds.

1.1 Related Work

Oblivious RAM was first investigated by Goldreich and Ostrovsky [26, 13, 14] in the context of protecting software from piracy, and efficient simulation of programs on oblivious RAMs. Since then, there has been much subsequent work [14, 18, 27, 23, 16, 7, 4, 38, 36, 15, 13, 26, 28, 12, 6] devoted to improving ORAM constructions. Path ORAM is based upon the binary-tree ORAM framework proposed by Shi et al. [31].

Near optimality of Path ORAM

Under small (i.e., constant or poly-logarithmic) client storage, the best known ORAM was proposed by Kushilevitz et al., and has blocks bandwidth cost [23].

Path ORAM achieves an asymptotic improvement under reasonable assumptions about the block size: when the block size is at least bits, and using a smaller block size of for the position map levels, Path ORAM has bandwidth cost of . Such a block size bits is what one typically encounters in most practical applications (e.g., 4KB blocks in file systems). Goldreich and Ostrovsky show that under client storage, any ORAM algorithm must have bandwidth cost (regardless of the block size). Since then, a long-standing open question is whether it is possible to have an ORAM construction that has or client-side storage and blocks bandwidth cost [14, 15, 23]. Our bound partially addresses this open question for reasonably large block sizes.

Comparison with Gentry et al. and Chung et al.

Gentry et al. [12] improve on the binary tree ORAM scheme proposed by Shi et al. [31]. To achieve failure probability, their scheme achieves blocks bandwidth cost, for block size bits. Assuming that , their bandwidth cost is blocks. In comparison, recursive Path ORAM achieves blocks bandwidth cost when . Note that typically since . Therefore, recursive Path ORAM is much more efficient than the scheme by Gentry et al.. Table 1 presents this comparison, assuming a failure probability of , i.e., negligible in . Since , the failure probability can also equivalently be written as . We choose to use to simplify the notation in the asymptotic bounds.

Chung and Pass [6] proved a similar (in fact slightly worse) bound as Gentry et al. [12]. As mentioned earlier, our bound is asymptotically better than Gentry et al. [12] or Chung and Pass [6].

In recent concurrent and independent work, Chung et al. proposed another statistically secure binary-tree ORAM algorithm [5] based on Path ORAM. Their theoretical bandwidth bound is a factor worse than ours for blocks of size . Their simulation results suggest an empirical bucket size of  [1] — which means that their practical bandwidth cost is a constant factor worse than Path ORAM, since they require operating on paths in expectation for each data access, while Path ORAM requires reading and writing only path.

Statistical security

We note that Path ORAM is also statistically secure (not counting the encryption). Statistically secure ORAMs have been studied in several prior works [8, 2]. All known binary-tree based ORAM schemes and variants are also statistically secure [31, 6, 12] (assuming each bucket is a trivial ORAM).

2 Problem Definition

We consider a client that wishes to store data at a remote untrusted server while preserving its privacy. While traditional encryption schemes can provide data confidentiality, they do not hide the data access pattern which can reveal very sensitive information to the untrusted server. In other words, the blocks accessed on the server and the order in which they were accessed is revealed. We assume that the server is untrusted, and the client is trusted, including the client’s processor, memory, and disk.

The goal of ORAM is to completely hide the data access pattern (which blocks were read/written) from the server. From the server’s perspective, the data access patterns from two sequences of read/write operations with the same length must be indistinguishable.


We assume that the client fetches/stores data on the server in atomic units, referred to as blocks, of size bits each. For example, a typical value for for cloud storage is KB while for secure processors smaller blocks ( B to  KB) are preferable. Throughout the paper, let be the working set, i.e., the number of distinct data blocks that are stored in ORAM.


We aim to provide an extremely simple ORAM construction in contrast with previous work. Our scheme consists of only 16 lines of pseudo-code as shown in Figure 1.

Security definitions

We adopt the standard security definition for ORAMs from [35]. Intuitively, the security definition requires that the server learns nothing about the access pattern. In other words, no information should be leaked about: 1) which data is being accessed; 2) how old it is (when it was last accessed); 3) whether the same data is being accessed (linkability); 4) access pattern (sequential, random, etc); or 5) whether the access is a read or a write.

Definition 1 (Security definition).


denote a data request sequence of length , where each denotes a or a operation. Specifically, denotes the identifier of the block being read or written, and denotes the data being written. In our notation, index corresponds to the most recent load/store and index corresponds to the oldest load/store operation.

Let denote the (possibly randomized) sequence of accesses to the remote storage given the sequence of data requests . An ORAM construction is said to be secure if (1) for any two data request sequences and of the same length, their access patterns and are computationally indistinguishable by anyone but the client, and (2) the ORAM construction is correct in the sense that it returns on input data that is consistent with with probability , i.e., the ORAM may fail with probability .

Like all other related work, our ORAM constructions do not consider information leakage through the timing channel, such as when or how frequently the client makes data requests. Achieving integrity against a potentially malicious server is discussed in Section 6.4. We do not focus on integrity in our main presentation.

3 The Path ORAM Protocol

We first describe the Path ORAM protocol with linear amount of client storage, and then later in Section 4 we explain how the client storage can be reduced to (poly-)logarithmic via recursion.

3.1 Overview

We now give an informal overview of the Path ORAM protocol. The client stores a small amount of local data in a stash. The server-side storage is treated as a binary tree where each node is a bucket that can hold up to a fixed number of blocks.

Main invariant

We maintain the invariant that at any time, each block is mapped to a uniformly random leaf bucket in the tree, and unstashed blocks are always placed in some bucket along the path to the mapped leaf.

Whenever a block is read from the server, the entire path to the mapped leaf is read into the stash, the requested block is remapped to another leaf, and then the path that was just read is written back to the server. When the path is written back to the server, additional blocks in the stash may be evicted into the path as long as the invariant is preserved and there is remaining space in the buckets.

3.2 Server Storage

Data on the server is stored in a tree consisting of buckets as nodes. The tree does not have to necessarily be a binary tree, but we use a binary tree in our description for simplicity.

Binary tree

The server stores a binary tree data structure of height and leaves. In our theoretic bounds, we need , but in our experiments, we observe that is sufficient. The tree can easily be laid out as a flat array when stored on disk. The levels of the tree are numbered to where level denotes the root of the tree and level denotes the leaves.


Each node in the tree is called a bucket. Each bucket can contain up to real blocks. If a bucket has less than real blocks, it is padded with dummy blocks to always be of size . It suffices to choose the bucket size to be a small constant such as (see Section 7.1).


Let denote the -th leaf node in the tree. Any leaf node defines a unique path from leaf to the root of the tree. We use to denote set of buckets along the path from leaf to the root. Additionally, denotes the bucket in at level in the tree.

Server storage size

Since there are about buckets in the tree, the total server storage used is about blocks.

3.3 Client Storage and Bandwidth

The storage on the client consists of data structures, a stash and a position map:


During the course of the algorithm, a small number of blocks might overflow from the tree buckets on the server. The client locally stores these overflowing blocks in a local data structure called the stash. In Section 5, we prove that the stash has a worst-case size of blocks with high probability. In fact, in Section 7.2, we show that the stash is usually empty after each ORAM read/write operation completes.

Position map

The client stores a position map, such that means that block is currently mapped to the -th leaf node — this means that block resides in some bucket in path , or in the stash. The position map changes over time as blocks are accessed and remapped.


For each load or store operation, the client reads a path of blocks from the server and then writes them back, resulting in a total of blocks bandwidth used per access. Since is a constant, the bandwidth usage is blocks.

Client storage size

For now, we assume that the position map and the stash are both stored on the client side. The position map is of size bits, which is of size blocks when the block size . In Section 5, we prove that the stash for the basic non-recursive Path ORAM is at most blocks to obtain negligible failure probability. Later in in Section 4, we explain how the recursive construction can also achieve client storage of blocks as shown in Table 1.

Total # blocks outsourced to server
Height of binary tree
Block size (in bits)
Capacity of each bucket (in blocks)
path from leaf node to the root
the bucket at level along the path
client’s local stash
client’s local position map
block is currently associated with leaf node , i.e., block resides somewhere along or in the stash.
Table 2: Notations

3.4 Path ORAM Initialization

The client stash is initially empty. The server buckets are intialized to contain random encryptions of the dummy block (i.e., initially no block is stored on the server). The client’s position map is filled with independent random numbers between and .

3.5 Path ORAM Reads and Writes

  \@minipagerestore : 1: 2: 3:for  do 4:      5:end for 6: Read block from 7:if  then 8:      9:end if 10:for  do 11:      12:      Select blocks from . 13:      14:      15:end for 16:return   

Figure 1: Protocol for data access. Read or write a data block identified by . If , the input parameter , and the operation reads block from the ORAM. If , the operation writes the specified to the block identified by and returns the block’s old data.

In our construction, reading and writing a block to ORAM is done via a single protocol called described in Figure 1. Specifically, to read block , the client performs and to write to block , the client performs . The protocol can be summarized in 4 simple steps:

  1. Remap block (Lines 1 to 2): Randomly remap the position of block to a new random position. Let denote the block’s old position.

  2. Read path (Lines 3 to 5): Read the path containing block .

  3. Update block (Lines 6 to 9): If the access is a write, update the data stored for block .

  4. Write path (Lines 10 to 15): Write the path back and possibly include some additional blocks from the stash if they can be placed into the path. Buckets are greedily filled with blocks in the stash in the order of leaf to root, ensuring that blocks get pushed as deep down into the tree as possible. A block can be placed in the bucket at level only if the path to the leaf of block intersects the path accessed at level . In other words, if .

Note that when the client performs on a block for the first time, it will not find it in the tree or stash, and should assume that the block has a default value of zero.


We now explain the and the subroutine. For , the client reads all blocks (including any dummy blocks) from the bucket stored on the server. Blocks are decrypted as they are read.

For , the client writes the blocks into the specified on the server. When writing, the client pads with dummy blocks to make it of size — note that this is important for security. All blocks (including dummy blocks) are re-encrypted, using a randomized encryption scheme, as they are written.


Client’s computation is per data access. In practice, the majority of this time is spent decrypting and encrypting blocks per data access. We treat the server as a network storage device, so it only needs to do the computation necessary to retrieve and store blocks per data access.

3.6 Security Analysis

To prove the security of Path-ORAM, let be a data request sequence of size . By the definition of Path-ORAM, the server sees which is a sequence

where is the position of address indicated by the position map for the -th load/store operation, together with a sequence of encrypted paths , , each encrypted using randomized encryption. The sequence of encrypted paths is computationally indistinguishable from a random sequence of bit strings by the definition of randomized encryption (note that ciphertexts that correspond to the same plaintext use different randomness and are therefore indistinguishable from one another). The order of accesses from to 1 follows the notation from Definition 1.

Notice that once is revealed to the server, it is remapped to a completely new random label, hence, is statistically independent of for with . Since the positions of different addresses do not affect one another in Path ORAM, is statistically independent of for with . This shows that is statistically independent of for , therefore, (by using Bayes rule) . This proves that is computationally indistinguishable from a random sequence of bit strings.

Now the security follows from Theorem 1 in Section 5: For a stash size Path ORAM fails (in that it exceeds the stash size) with at most negligible probability.

4 Recursion and Parameterization

4.1 Recursion Technique

In our non-recursive scheme described in the previous section, the client must store a relatively large position map. We can leverage the same recursion idea as described in the ORAM constructions of Stefanov et al. [35] and Shi et al. [31]. to reduce the client-side storage. The idea is simple: instead of storing the position map on the client side, we store the position map on the server side in a smaller ORAM, and recurse.

More concretely, consider a recursive Path ORAM made up of a series of ORAMs called where contains the data blocks, the position map of is stored in , and the client stores the position map for . To access a block in , the client looks up its position in , which triggers a recursive call to look up the position of the position in , and so on until finally a position of is looked up in the client storage. For a more detailed description of the recursion technique, we refer the readers to [35, 31].

4.2 Parameterization

We can choose the block size for the recursive ORAMs to parametrize the recursion.

Uniform Block Size

Suppose each block has size bits, where . This is a reasonable assumption that has been made by Stefanov et al. [35, 34] and Shi et al. [31]. For example, a standard 4KB block consists of bits and this assumption holds for all . In this case, the number of level of recursions is . Hence, the bandwidth overhead is blocks.

  • Separate Local Storage for Stashes from Different Levels of Recursion. From Theorem 1 in Section 5, in order to make the failure probability for each stash to be , the capacity of each stash can be set to blocks. Hence, storing stashes from all levels needs blocks of storage.

  • Common Local Storage for Stashes from All Levels of Recursion. A common local storage can be used to store stash blocks from all levels of recursion. From Theorem 1, it follows that the number of blocks in each stash is dominated by some geometric random variable. Hence, it suffices to analyze the sum of independent geometric random variables. From the analysis in Section 4.3 (with the detailed proof given in Section 5.7), it follows that the capacity of the common storage can be set to to achieve failure probability .

Non-uniform Block Size

Suppose that the regular block size is bits. This is the block size for the original ORAM (). Suppose for the position map ORAMs ( for ), we use a small block size of bits for some constant .

The client storage is small blocks and regular blocks. Hence, the total client storage is regular blocks. Each operation involves communication of small blocks and regular blocks. Hence, the bandwidth cost (with respect to a regular block) is .

As can be seen, using non-uniform block sizes leads to a much more efficient parametrization of recursive Path ORAM in terms of bandwidth. However, using uniform block sizes reduces the number of recursion levels, leading to a smaller round-trip response time.

4.3 Shared Stash

In Section 5.7, we show that the client storage for our Recursive Path ORAM construction (with non-uniform block sizes) can be reduced from to by having a single stash shared among all levels of the recursion. This is possible while still maintaining a negligible probability of stash overflow.

5 Bounds on Stash Usage

In this section we will analyze the stash usage for a non-recursive Path-ORAM, where each bucket in the Path-ORAM binary tree stores a constant number of blocks. In particular, we analyze the probability that, after a sequence of load/store operations, the number of blocks in the the stash exceeds , and show that this probability decreases exponentially in .

By we denote a non-recursive Path-ORAM with levels in which each bucket stores real/dummy blocks; the root is at level and the leaves are at level .

We define a sequence of load/store operations s as a triple that contains (1) the sequence of block addresses of blocks that are loaded/stored, (2) the sequence of labels as seen by the server (line 1 in Figure 1), and (3) the sequence of remapped leaf labels (line 2 in Figure 1). The tuple corresponds to the most recent load/store operation, corresponds to the next most recent load/store operation, and so on. A path from the root to some is known as an eviction path, and a path from the root to some is known as an assigned path. The number of load/store operations is denoted by . The working set corresponding to a is defined as the number of distinct block addresses in a. We write .

By we denote the distribution of real blocks in after a sequence s of load/store operations starting with an empty ORAM; the sequence s completely defines all the randomness needed to determine, for each block address , its leaf label and which bucket/stash stores the block that corresponds to . In particular the number of real blocks stored in the buckets/stash can be reconstructed.

We assume an infinite stash and in our analysis we investigate the usage of the stash defined as the number of real blocks that are stored in the stash after a sequence s of load/store operations. In practice the stash is limited to some size and Path-ORAM fails after a sequence s of load/store operations if the stash needs more space: this happens if and only if the usage of the infinite stash is at least .

Theorem 1 (Main).

Let a be any sequence of block addresses with a working set of size at most . For a bucket size , tree height and stash size , the probability of a Path ORAM failure after a sequence of load/store operations corresponding to a, is at most

where the probability is over the randomness that determines x and y in .

As a corollary, for load/store operations on data blocks, Path ORAM with client storage blocks, server storage blocks and bandwidth blocks per load/store operation, fails during one of the load/store operations with probability . So, if we assume the number of load/stores is equal to , then, for a stash of size , the probability of Path ORAM failure during one of the load/store operations is negligible in .

Proof outline. The proof of the main theorem consists of several steps: First, we introduce a second ORAM, called -ORAM, together with an algorithm that post-processes the stash and buckets of -ORAM in such a way that if -ORAM gets accessed by a sequence s of load/store operations, then the process leads to a distribution of real blocks over buckets that is exactly the same as the distribution as in Path ORAM after being accessed by s.

Second, we characterize the distributions of real blocks over buckets in a -ORAM for which post-processing leads to a stash usage . We show that the stash usage after post-processing is if and only if there exists a subtree for which its “usage” in -ORAM is more than its “capacity”. This means that we can use the union bound to upper bound as a sum of probabilities over subtrees.

Third, we analyze the usage of subtrees . We show how a mixture of a binomial and a geometric probability distribution expresses the probability of the number of real blocks that do not get evicted from after a sequence s of load/store operations. By using measure concentration techniques we prove the main theorem.

5.1 -Oram

We define -ORAM, denoted by , as an ORAM that exhibits the same tree structure as Path-ORAM with levels but where each bucket has an infinite size. The -ORAM is used only as a tool for usage analysis, and does not need to respect any security notions.

In order to use to analyze the stash usage of , we define a post-processing greedy algorithm that takes as input the state of after a sequence s of load/store operations and attempts to reassign blocks such that each bucket stores at most blocks, putting excess blocks in the (initially empty) stash if necessary. We use to denote the stash usage after the greedy algorithm is applied. The algorithm repeats the following steps until there is no bucket that stores more than blocks, where the stash is initially empty.

  1. Select a block in a bucket that stores more than blocks. Suppose the bucket is at level , and is the path from the bucket to the root.

  2. Find the highest level such that the bucket at level on the path stores less than blocks. If such a bucket exists, then use it to store the block. If it does not exist, then put the block in the stash.

Lemma 1.

The stash usage in a post-processed -ORAM is exactly the same as the stash usage in Path-ORAM:


We first notice that the order in which the greedy strategy processes blocks from the stash does not affect the number of real blocks in each bucket that are stored in server storage after post-processing.

Suppose the greedy strategy first processes a block with label stored in a bucket at level and suppose it finds empty space in server storage at level ; the greedy strategy up to block has used up all the empty space in server storage allocated to the buckets along the path to the leaf with label at levels . Suppose next a stash block with label stored in a bucket at level finds empty space in server storage at level ; the greedy strategy up to block , which includes the post-processing of , has used up all the empty space in server storage allocated to the buckets along the path to the leaf with label at levels . If we swap the post-processing of and , then is able to find empty space in the bucket at level , but may find empty space at a higher level since has not yet been processed. In this case, and paths and intersect at least up to and including level . This means that is stored at level and will use the empty space in server storage at level . This means that the number of blocks that are stored in the different buckets after post-processing and is the same if is processed before or after .

Now, we are able to show, by using induction in , that for each bucket in a post-processed -ORAM after a sequence s of load/store operations, the number of real blocks stored in that are in server storage is equal to the number of blocks stored in the equivalent bucket in Path-ORAM after applying the same sequence s of load/store operations: The statement clearly holds for when both ORAMs are empty. Suppose it holds for . Consider the next load/store operation to some leaf . After reading the path to leaf into the cache, Path-ORAM moves blocks from its cache/stash into the path from root to leaf according to algorithm . Therefore, post-processing after the first operations followed by the greedy approach of Path ORAM that processes the -th operation is equivalent to post-processing after operations where some blocks may be post-processed twice. Since the order in which blocks are post-processed does not matter, we may group together the multiple times a block is being post-processed and this is equivalent to post-processing exactly once as in . The number of real blocks in the stash is the same and this proves the lemma. ∎

5.2 Usage/Capacity Bounds

To investigate when a not processed can lead to a stash usage of after post-processing, we start by analyzing bucket usage over subtrees. When we talk about a subtree of the binary tree, we always implicitly assume that it contains the root of the ORAM tree; in particular, if a node is contained in , then so are all its ancestors. We define to be the total number of nodes in . For -ORAM we define the usage of after a sequence s of load/store operations as the actual number of real blocks that are stored in the buckets of .

The following lemma characterizes the stash usage:

Lemma 2.

The stash usage in post-processed -ORAM is if and only if there exists a subtree in such that


If part: Suppose is a subtree such that . Observe that the greedy algorithm can assign the blocks in a bucket only to an ancestor bucket. Since can store at most blocks, more than blocks must be assigned to the stash by the greedy algorithm .

Only if part: Suppose that . Define to be the maximal subtree that contains all buckets with exactly blocks after post-processing by the greedy algorithm . Suppose is a bucket not in . By the maximality of , there is an ancestor (not necessarily proper ancestor) bucket of that contains less than blocks after post-processing, which implies that no block from can go to the stash. Hence, all blocks that are in the stash must have originated from a bucket in . Therefore, it follows that

Lemma 3 (Worst-case Address Pattern).

Out of all address sequences on a working set of size , the probability is maximized by a sequence in which each block address appears exactly once, i.e., and there are no duplicate block addresses. As a consequence, for such an address pattern, the labels in and are all statistically independent of one another.


Suppose that there exists an address in a that has been loaded/stored twice in -ORAM. Then, there exist indices and , , with . Without the -th load/store, the working set remains the same and it is more likely for older blocks corresponding to , to not have been evicted from (since there is one less load/store that could have evicted an older block to a higher level outside ; also notice that buckets in -ORAM are infinitely sized, so, removing the -th load/store does not generate extra space that can be used for storage of older blocks that otherwise would not have found space). So, the probability is maximized when is a sequence of block addresses without duplicates. ∎

Bounding Usage for Each Subtree. In view of Lemma 3, we fix a sequence a of distinct block addresses. The randomness comes from the independent choices of labels and .

As a corollary to Lemmas 1 and 2, we obtain

where ranges over all subtrees containing the root, and the inequality follows from the union bound.

Since the number of ordered binary trees of size is equal to the Catalan number , which is ,

We next give a uniform upper bound for

in terms of , and .

5.3 Usage of Subtree via Eviction Game

In view of Lemma 3, we assume that the request sequence is of length , and consists of distinct block addresses. Recall that the labels in and are independent, where each label corresponds to a leaf bucket. The indices are given in reversed order, i.e, is the first access and is the last access.

At every time step , a block is requested. The block resides in a random path with some label previously chosen (however the random choice has never been revealed). This path is now visited. Henceforth, this path is called the eviction path .

Then, the block is logically assigned to a freshly chosen random path with label , referred to as the assigned path .

Recall that given subtree , we want to probabilistically bound the quantity , which is the number of blocks that, at the end of an access sequence , survive in the subtree , i.e., have not been evicted out of the subtree .

Definition 2 (Exit node).

For a given path leading to some leaf node, suppose that some node is the first node of the path that is not part of , then we refer to node as the exit node, denoted . If the whole path is contained in , then the exit node is null.

To bound the number of surviving blocks in at the end of an access sequence of , we focus on an individual block that is requested at step in this sequence. Suppose this block resides in path , and is assigned to some path at the end of the request. Observe that this block will be evicted from tree at the end of the sequence iff the following holds: there exists a later step (recalling that smaller indices mean later) such that both exit nodes and are equal and not null. Otherwise the block will survive in tree at the end of the sequence — and will contribute to the count of the total surviving blocks.

We next define some notations relating to the subtree .

Let be the set of nodes in that are also leaves of the ORAM binary tree; we denote . We augment the tree by adding nodes to form in the following way. If a node in has any child node that is not in , then node will be added to . The added nodes in are referred to as exit nodes, denoted by ; the leaves of are denoted by . Observe that if contains nodes and , then .

We summarize the notations we use in Table 3.

Variable Meaning
a subtree rooted at the root of the binary tree
augmented tree by including every child (if any) of every node in
nodes of a subtree that are leaves to the ORAM binary tree
set of exit nodes of a subtree
set of all leaves of
capacity of each bucket
Table 3: Notations for the analysis.
Figure 2: A subtree containing some leaves of the original ORAM binary tree, augmented with the exit nodes

Eviction Game. Consider the following eviction game, which is essentially playing the ORAM access sequence reversed in time. Initially, all nodes in are marked closed; all nodes in will remain closed, and only nodes in may be marked open later.

For , do the following:

  1. Pick a random eviction path starting from the root, denoted . The path will intersect exactly one node in . If is an exit node in , mark node as open (if that exit node is already marked open, then it will continue to be open).

  2. For a block requested in time step , pick a random assignment path starting from the root. The path will intersect exactly one node in . If this node is closed, then the block survives; otherwise, the block is evicted from .

For , a block from step survives because its corresponding assignment path intersects a node in , or an exit node that is closed. We define to be the indicator variable that equals 1 iff the path intersects a node in (and block survives), to be the indicator variable that equals 1 iff the path intersects a node in and block survives. Define and ; observe that the number of blocks that survive is .

5.4 Negative Association

Independence is often required to show measure concentration. However, the random variables and are not independent. Fortunately, and are negatively associated. For simplicity, we show a special case in the following lemma, which will be useful in the later measure concentration argument.

Lemma 4.

For and defined above, and all , .


Observe that there exists some , such that for all , . For each , define . Observe that the ’s are random variables, and they are non-increasing in and determined by the choice of eviction paths.

For each , , and hence and are negatively associated. Conditioning on , observe that the ’s are determined by the choice of independent assignment paths in different rounds, and hence are independent over different ’s. Hence, it follows from [9, Proposition 7(1)] that conditioning on , and are negatively associated.

In particular, for non-negative , we have , where the last equality follows because is independent of . Taking expectation over gives . ∎

5.5 Stochastic Dominance

Because of negative association, we consider two games to analyze the random variables and separately. The first game is a balls-and-bins game which produces a random variable that has the same distribution as . The second game is a modified eviction game with countably infinite number of rounds, which produces a random variable that stochastically dominates , in the sense that and can be coupled such that .

  1. Balls-and-Bins Game: For simplicity, we assume . In this game, blocks are thrown independently and uniformly at random into buckets corresponding to the leaves of the ORAM binary tree. The blocks that fall in the leaves in survive. Observe that the number of surviving blocks has the same distribution as .

  2. Infinite Eviction Game: This is the same as before, except for the following differences.

    1. Every node in is initially closed, but all of them could be open later. In particular, if some eviction path intersects a leaf node , node will become open.

    2. There could be countably infinite number of rounds, until eventually all nodes in are open, and no more blocks can survive after that.

    Let be the total number of surviving blocks in the infinite eviction game. Observe that a block with assigned path intersecting a node in will not be counted towards , but might be counted towards if the node is closed. Hence, there is a natural coupling such that the number of surviving blocks in the first rounds in the infinite game is at least in the finite eviction game. Hence, the random variable stochastically dominates . Hence, we have for all non-negative , .

5.6 Measure Concentration for the Number of Surviving Blocks in Subtree

We shall find parameters and such that, with high probability, is at most . For simplicity, we assume is a power of two.

Lemma 5.

Suppose that the address sequence is of length , where . Moreover, suppose that is a subtree of the binary ORAM tree containing the root having nodes. Then, for , for any , .


Because of negative association between and , and stochastic dominance by and , we analyze and .

Observe that if has nodes, among which are in , then has leaves in .

Balls-and-Bins Game. Recall that is the indicator variable for whether the assigned path intersects a bucket in . Then, . Recall that and there are leaf buckets in the binary ORAM tree. Observe that for real , , and hence by independence, .

Infinite Eviction Game. For each , suppose is at depth (the root is at depth 0), and let its weight be . Observe that the sum of weights of nodes in is 1.

Define to be the number of surviving blocks such that there are exactly open nodes at the moment when the corresponding assigned paths are chosen. Since contains nodes, we consider from 1 to . (Observe that for in the first round of the infinite eviction game, the first eviction path closes one of the nodes in , and hence, the number of remaining open nodes for the first block is .) Let be the number of rounds in which, at the moment when the assigned path is chosen, there are exactly open nodes. Let be the weight of the th open node. Define . Observe that conditioning on , follows the geometric distribution with parameter ; moreover, conditioning on and , is the sum of independent Bernoulli random variables, each with expectation .

Define . We shall analyze the moment generating function for appropriate values of . The strategy is that we first derive an upper bound for , where , that depends only on (and in particular independent of or ). This allows us to conclude that .

For simplicity, in the below argument, we assume that we have conditioned on and we write , and .

Recall that is a sum of independent Bernoulli random variables, where has a geometric distribution. Therefore, we have the following.


From (1) to (2), we consider the moment generating function of a sum of independent Bernoulli random variables, each having expectation : . In (3), for the series to converge, we observe that , which is smaller than 1 when . In (5), we use for all real .

Hence, we have shown that for , (since conditioning on , is independent of past history), which we show from above is at most . Taking expectation over gives .

Observe that the inequality holds independent of the value of . Therefore, the same argument can be used to prove that, for any , we have .

Hence, a simple induction argument on can show that .

Combining Together. Let be the capacity for each bucket in the binary ORAM tree, and be the number blocks overflowing from the binary tree that need to be stored in the stash.

We next perform a standard moment generating function argument. For , , which by Markov’s Inequality, is at most , which, by negative associativity and stochastic dominance, is at most