1 Oblvous Parallel RAM and Applcatons Elette Boyle Technon Israel Ka-Mn Chung Academca Snca August 31, 2015 Rafael Pass Cornell Unversty Abstract We n...

Author:
Merry Brown

0 downloads 12 Views 585KB Size

Kai-Min Chung Academica Sinica [email protected]

Rafael Pass† Cornell University [email protected]

August 31, 2015

Abstract We initiate the study of cryptography for parallel RAM (PRAM) programs. The PRAM model captures modern multi-core architectures and cluster computing models, where several processors execute in parallel and make accesses to shared memory, and provides the “best of both” circuit and RAM models, supporting both cheap random access and parallelism. We propose and attain the notion of Oblivious PRAM. We present a compiler taking any PRAM into one whose distribution of memory accesses is statistically independent of the data (with negligible error), while only incurring a polylogarithmic slowdown (in both total and parallel complexity). We discuss applications of such a compiler, building upon recent advances relying on Oblivious (sequential) RAM (Goldreich Ostrovsky JACM’12). In particular, we demonstrate the construction of a garbled PRAM compiler based on an OPRAM compiler and secure identity-based encryption.

∗

The research of the first author has received funding from the European Union’s Tenth Framework Programme (FP10/ 2010-2016) under grant agreement no. 259426 ERC-CaC, and ISF grant 1709/14. † Pass is supported in part by a Google Faculty Award, Alfred P. Sloan Fellowship, Microsoft New Faculty Fellowship, NSF Award CNS-1217821, NSF CAREER Award CCF-0746990, NSF Award CCF-1214844, AFOSR YIP Award FA9550-10-1-0093, and DARPA and AFRL under contract FA8750-11-2- 0211. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the US Government. † This work was done in part while the authors were visiting the Simons Institute for the Theory of Computing, supported by the Simons Foundation and by the DIMACS/Simons Collaboration in Cryptography through NSF grant #CNS-1523467.

1

Introduction

Completeness results in cryptography provide general transformations from arbitrary functionalities described in a particular computational model, to solutions for executing the functionality securely within a desired adversarial model. Classic results, stemming from [Yao82, GMW87], modeled computation as boolean circuits, and showed how to emulate the circuit securely gate by gate. As the complexity of modern computing tasks scales at tremendous rates, it has become clear that the circuit model is not appropriate: Converting “lightweight,” optimized programs first into a circuit in order to obtain security is not a viable option. Large effort has recently been focused on enabling direct support of functionalities modeled as Turing machines or random-access machines (RAM) (e.g., [OS97, GKK+ 12, LO13a, GKP+ 13, GHRW14, GHL+ 14, GLOS15, CHJV15, BGL+ 15,KLW15]). This approach avoids several sources of expensive overhead in converting modern programs into circuit representations. However, it actually introduces a different dimension of inefficiency. RAM (and single-tape Turing) machines do not support parallelism: thus, even if an insecure program can be heavily parallelized, its secure version will be inherently sequential. Modern computing architectures are better captured by the notion of a Parallel RAM (PRAM). In the PRAM model of computation, several (polynomially many) CPUs are simultaneously running, accessing the same shared “external” memory. Note that PRAM CPUs can model physical processors within a single multicore system, as well as distinct computing entities within a distributed computing environment. We consider an expressive model where the number of active CPUs may vary over time (as long as the pattern of activation is fixed a priori). In this sense, PRAMs capture the “best of both” RAM and the circuit models: A RAM program handles random access but is entirely sequential, circuits handle parallelism with variable number of parallel resources (i.e., the circuit width), but not random access; variable CPU PRAMs capture both random access and variable parallel resources. We thus put forth the challenge of designing cryptographic primitives that directly support PRAM computations, while preserving computational resources (total computational complexity and parallel time) up to poly logarithmic, while using the same number of parallel processors. Oblivious Parallel RAM (OPRAM). A core step toward this goal is to ensure that secret information is not leaked via the memory access patterns of the resulting program execution. A machine is said to be memory oblivious, or simply oblivious, if the sequences of memory accesses made by the machine on two inputs with the same running time are identically (or close to identically) distributed. In the late 1970s, Pippenger and Fischer [PF79] showed that any Turing Machine Π can be compiled into an oblivious one Π0 (where “memory accesses” correspond to the movement of the head on the tape) with only a logarithmic slowdown in running-time. Roughly ten years later, Goldreich and Ostrovsky [Gol87, GO96] proposed the notion of Oblivious RAM (ORAM), and showed a similar transformation result with polylogarithmic slowdown. In recent years, ORAM compilers have become a central tool in developing cryptography for RAM programs, and a great deal of research has gone toward improving both the asymptotic and concrete efficiency of ORAM compilers (e.g., [Ajt10, DMN11, GMOT11, KLO12, CP13, CLP14, GGH+ 13, SvDS+ 13, CLP14, WHC+ 14, RFK+ 14, WCS14]). However, for all such compilers, the resulting program is inherently sequential. In this work, we propose the notion of Oblivious Parallel RAM (OPRAM). We present the first OPRAM compiler, converting any PRAM into an oblivious PRAM, while only inducing a

1

polylogarithmic slowdown to both the total and parallel complexities of the program. Theorem 1.1 (OPRAM – Informally stated). There exists an OPRAM compiler with O(log(m) log3 (n)) worst-case overhead in total and parallel computation, and f (n) memory overhead for any f ∈ ω(1), where n is the memory size and m is an upper-bound on the number of CPUs in the PRAM. We emphasize that applying even the most highly optimized ORAM compiler to an m-processor PRAM program inherently inflicts Ω(m log(n)) overhead in the parallel runtime, in comparison to our O(log(m)polylog(n)). When restricted to single-CPU programs, our construction incurs slightly greater logarithmic overhead than the best optimized ORAM compilers (achieving O(log n) overhead for optimal block sizes); we leave as an interesting open question how to optimize parameters. (As we will elaborate on shortly, some very interesting results towards addressing this has been obtained in the follow-up work of [CLT15].)

1.1

Applications of OPRAM

ORAM lies at the base of a wide range of applications. In many cases, we can directly replace the underlying ORAM with an OPRAM to enable parallelism within the corresponding secure application. For others, simply replacing ORAM with OPRAM does not suffice; nevertheless, in this paper, we demontrate one application (garbling of PRAM programs) where they can be overcome; follow-up works show further applications (secure computation and obfuscation). Direct Applications of OPRAM

We briefly describe some direct applications of OPRAM.

Improved/Parallelized Outsourced Data. Standard ORAM has been shown to yield effective, practical solutions for securely outsourcing data storage to an untrusted server (e.g., the ObliviStore system of [SS13]). Efficient OPRAM compilers will enable these systems to support secure efficient parallel accesses to outsourced data. For example, OPRAM procedures securely aggregate parallel data requests and resolve conflicts client-side, minimizing expensive client-server communications (as was explored in [WST12], at a smaller scale). As network latency is a major bottleneck in ORAM implementations, such parallelization may yield significant improvements in efficiency. Multi-Client Outsourced Data. In a similar vein, use of OPRAM further enables secure access and manipulation of outsourced shared data by multiple (mutually trusting) clients. Here, each client can simply act as an independent CPU, and will execute the OPRAM-compiled program corresponding to the parallel concatenation of their independent tasks. Secure Multi-Processor Architecture. Much recent work has gone toward implementing secure hardware architectures by using ORAM to prevent information leakage via access patterns of the secure processor to the potentially insecure memory (e.g., the Ascend project of [FDD12]). Relying instead on OPRAM opens the door to achieving secure hardware in the multi-processor setting. Garbled PRAM (GPRAM) Garbled circuits [Yao82] allow a user to convert a circuit C and input x into garbled versions C˜ and x ˜, in such a way that C˜ can be evaluated on x ˜ to reveal the output C(x), but without revealing further information on C or x. Garbling schemes have found countless applications in cryptography, ranging from delegation of computation to secure multiparty protocols (see below). It was recently shown (using ORAM) how to directly garble RAM 2

programs [GHL+ 14, GLOS15], where the cost of evaluating a garbled program P˜ scales with its RAM (and not circuit) complexity. In this paper, we show how to employ any OPRAM compiler to attain a garbled PRAM (GPRAM), where the time to generate and evaluate the garbled PRAM program P˜ scales with the parallel time complexity of P . Our construction is based on one of the construction of [GHL+ 14] and extends it using some of the techniques developed for our OPRAM. Plugging in our (unconditional) OPRAM construction, we obtain: Theorem 1.2 (Garbled PRAM – Informally stated). Assuming identity-based encryption, there exists a secure garbled PRAM scheme with total and parallel overhead poly(κ) · polylog(n), where κ is the security parameter of the IBE and n is the size of the garbled data. Secure Two-Party and Multi-Party Computation of PRAMs. Secure multi-party computation (MPC) enables mutually distrusting parties to jointly evaluate functions on their secret inputs, without revealing information on the inputs beyond the desired function output. ORAM has become a central tool in achieving efficient MPC protocols for securely evaluating RAM programs. By instead relying on OPRAM, these protocols can leverage parallelizability of the evaluated programs. Our garbled PRAM construction mentioned above yields constant-round secure protocols where the time to execute the protocol scales with the parallel time of the program being evaluated. In a companion paper [BCP15], we further demonstrates how to use OPRAM to obtain efficient protocols for securely evaluating PRAMs in the multi-party setting; see [BCP15] for further details. Obfuscation for PRAMs. In a follow-up work, Chung et al [CCC+ 15] rely on our specific OPRAM construction (and show that it satisfies an additional “puncturability” property) to achieve obfuscation for PRAMs.

1.2

Technical Overview

Begin by considering the simplest idea toward memory obliviousness: Suppose data is stored in random(-looking) shuffled order, and for each data query i, the lookup is performed to its permuted location, σ(i). One can see this provides some level of hiding, but clearly does not suffice for general programs. The problem with the simple solution is in correlated lookups over time—as soon as item i is queried again, this collision will be directly revealed. Indeed, hiding correlated lookups while maintaining efficiency is perhaps the core challenge in building oblivious RAMs. In order to bypass this problem, ORAM compilers heavily depend on the ability of the CPU to move data around, and to update its secret state after each memory access. However, in the parallel setting, we find ourselves back at square one. Suppose in some time step, a group of processors all wish to access data item i. Having all processors attempt to perform the lookup directly within a standard ORAM construction corresponds to running the ORAM several times without moving data or updating state. This immediately breaks security in all existing ORAM compiler constructions. On the other hand, we cannot afford for the CPUs to “take turns,” accessing and updating the data sequentially. In this overview, we discuss our techniques for overcoming this and further challenges. We describe our solution somewhat abstractly, building on a sequential ORAM compiler with a treebased structure as introduced by Shi et al. [SCSL11]. In our formal construction and analysis, we 3

rely on the specific tree-based ORAM compiler of Chung and Pass [CP13] that enjoys a particularly clean description and analysis. Tree-Based ORAM Compilers. We begin by roughly describing the structure of tree-based ORAMs, originating in the work of [SCSL11]. At a high level, data is stored in the structure of a binary tree, where each node of the tree corresponds to a fixed-size bucket that may hold a collection of data items. Each memory cell addr in the original database is associated with a random path (equivalently, leaf) within a binary tree, as specified by a position map pathaddr = P os(addr). The schemes maintain three invariants: (1) The content of memory cell addr will be found in one of the buckets along the path pathaddr . (2) Given the view of the adversary (i.e., memory accesses) up to any point in time, the current mapping P os appears uniformly random. And, (3) with overwhelming probability, no node in the binary tree will ever “overflow,” in the sense that its corresponding memory bucket is instructed to store more items than its fixed capacity. These invariants are maintained by the following general steps: 1. Lookup: To access a memory item addr, the CPU accesses all buckets down the path pathaddr , and removes it where found. 2. Data “put-back”: At the conclusion of the access, the memory item addr is assigned a freshly random path P os(addr) ← path0addr , and is returned to the root node of the tree.

3. Data flush: To ensure the root (and any other bucket) does not overflow, data is “flushed” down the tree via some procedure. For example, in [SCSL11], the flush takes place by selecting and emptying two random buckets from each level into their appropriate children; in [CP13], it takes place by choosing an independent path in the tree and pushing data items down this path as far as they will go (see Figure 1 in Section 2.2). Extending to Parallel RAMs. We must address the following problems with attempting to access a tree-based ORAM in parallel. • Parallel memory lookups: As discussed, a core challenge is in hiding correlations in parallel CPU accesses. In tree-based ORAMs, if CPUs access different data items in a time step, they will access different paths in the tree, whereas if they attempt to simultaneously access the same data item, they will each access the same path in the tree, blatantly revealing a collision. To solve this problem, before each lookup we insert a CPU-coordination phase. We observe that in tree-based ORAM schemes, this problem only manifests when CPUs access exactly the same item, otherwise items are associated with independent leaf nodes, and there are no bad correlations. We thus resolve this issue by letting the CPUs check—through an oblivious aggregation operation—whether two (or more) of them wish to access the same data item; if so, a representative is selected (the CPU with the smallest id) to actually perform the memory access, and all the others merely perform “dummy” lookups. Finally, the representative CPU needs to communicate the read value back to all the other CPUs that wanted to access the same data item; this is done using an oblivious multi-cast operation. The challenge is in doing so without introducing too much overhead—namely, allowing only (per-CPU) memory, computation, and parallel time polylogarithmic in both the database size and the number of CPUs—and that itself retains memory obliviousness. • Parallel “put-backs”: After a memory cell is accessed, the (possibly updated) data is assigned a fresh random path and is reinserted to the tree structure. To maintain the required 4

invariants, the item must be inserted somewhere along its new path, without revealing any information about the path. In tree-based ORAMs, this is done by reinserting at the root node of the tree. However, this single node can hold only a small bounded number of elements (corresponding to the fixed bucket size), whereas the number of processors m—each with an item to reinsert—may be significantly larger. To overcome this problem, instead of returning data items to the root, we directly insert them into level log m of the tree, while ensuring that they are placed into the correct bucket along their assigned path. Note that level log m contains m buckets, and since the m items are each assigned to random leaves, each bucket will in expectation be assigned exactly 1 item. The challenge in this step is specifying how the m CPUs can insert elements into the tree while maintaining memory obliviousness. For example, if each CPU simply inserts their own item into its assigned node, we immediately leak information about its destination leaf node. To resolve this issue, we have the CPUs obliviously route items between each other, so that eventually the ith CPU holds the items to be insert to the ith node, and all CPUs finally perform either a real or a dummy write to their corresponding node. • Preventing overflows: To ensure that no new overflows are introduced after inserting m items, we now flush m times instead of once, and all these m flushes are done in parallel: each CPU simply performs an independent flush. These parallel flushes may lead to conflicts in nodes accessed (e.g., each flush operation will likely access the root node). As before, we resolve this issue by having the CPUs elect some representative to perform the appropriate operations for each accessed node; note, however, that this step is required only for correctness, and not for security. Our construction takes a modular approach. We first specify and analyze our compiler within a simplified setting, where oblivious communication between CPUs is “for free.” We then show how to efficiently instantiate the required CPU communication procedures oblivious routing, oblivious aggregation, and oblivious multi-cast, and describe the final compiler making use of these procedures. In this extended abstract, we defer the first step to Appendix 3.1, and focus on the remaining steps.

1.3

Related Work

Restricted cases of parallelism in Oblivious RAM have appeared in a handful of prior works. It was observed by Williams, Sion, and Tomescu [WST12] in their PrivateFS work that existing ORAM compilers can support parallelization across data accesses up to the “size of the top level,”1 (in particular, at most log n), when coordinated through a central trusted entity. We remark that central coordination is not available in the PRAM model. Goodrich and Mitzenmacher [GM11] showed that parallel programs in MapReduce format can be made oblivious by simply replacing the “shuffle” phase (in which data items with a given key are routed to the corresponding CPU) with a fixed-topology sorting network. The goal of improving the parallel overhead of ORAM was studied by Lorch et al. [LPM+ 13], but does not support compilation of PRAMs without first sequentializing. Follow-up work. As mentioned above, our OPRAM compiler has been used in the recent works of Boyle, Chung, and Pass [BCP15] and Chen et al. [CCC+ 15] to obtain secure multi-party computation for PRAM, and indistinguishability obfuscation for PRAM, respectively. A different follow-up 1

E.g., for tree-based ORAMs, the size of the root bucket.

5

work by Nayak et al. [NWI+ 15] provides targeted optimizations and an implementation for secure computation of specific parallel tasks. Very recently, an exciting follow-up work of Chen, Lin, and Tessaro [CLT15] builds upon our techniques to obtain two new construction: an OPRAM compiler whose overhead in expectation matches that of the best current sequential ORAM [SvDS+ 13]; and, a general transformation taking any generic ORAM compiler to an OPRAM compiler with log n overhead in expectation. Their OPRAM constructions, however, only apply to the special case of PRAM with a fixed number of processors being activated at every step (whereas our notion of a PRAM requires handling also a variable number of processors2 ); for the case of variable CPU PRAMs, the results of [CLT15] incurr an additional multlicative overhead of m in terms of computational complexity, and thus the bounds obtained are incomparable.

2

Preliminaries

2.1

Parallel RAM (PRAM) Programs

We consider the most general case of Concurrent Read Concurrent Write (CRCW) PRAMs. An m-processor CRCW parallel random-access machine (PRAM) with memory size n consists of numbered processors CP U1 , . . . , CP Um , each with local memory registers of size log n, which operate synchronously in parallel and can make access to shared “external” memory of size n. A PRAM program Π (given m, n, and some input x stored in shared memory) provides CPUspecific execution instructions, which can access the shared data via commands Access(r, v), where r ∈ [n] is an index to a memory location, and v is a word (of size log n) or ⊥. Each Access(r, v) instruction is executed as: 1. Read from shared memory cell address r; denote value by vold . 2. Write value v 6= ⊥ to address r (if v = ⊥, then take no action). 3. Return vold . In the case that two or more processors simultaneously initiate Access(r, vi ) with the same address r, then all requesting processors receive the previously existing memory value vold , and the memory is rewritten with the value vi corresponding to the lowest-numbered CPU i for which vi 6= ⊥. We more generally support PRAM programs with a dynamic number of processors (i.e., mi processors required for each time step i of the computation), as long as this sequence of processor numbers m1 , m2 , . . . is public information. The complexity of our OPRAM solution will scale with the number of required processors in each round, instead of the maximum number of required processors. The (parallel) time complexity of a PRAM program Π is the maximum number of time steps taken by any processor to evaluate Π, where each Access execution is charged as a single step. The PRAM complexity of a function f is defined as the minimal parallel time complexity of any PRAM program which evaluates f . We remark that the PRAM complexity of any function f is bounded above by its circuit depth complexity. Remark 2.1 (CPU-to-CPU Communication). It will be sometimes convenient notationally to assume that CPUs may communicate directly amongst themselves. When the identities of sending 2

As previously mentioned, dealing with a variable number of processors is needed to capture standard circuit models of computation, where the circuit topology may be of varying width.

6

and receiving CPUs is known a priori (which will always be the case in our constructions), such communication can be emulated in the standard PRAM model with constant overhead by communicating through memory. That is, each action “CPU1 sends message m to CPU2” is implemented in two time steps: First, CPU1 writes m into a special designated memory location addrCP U 1 ; in the following time step, CPU2 performs a read access to addrCP U 1 to learn the value m.

2.2

Tree-Based ORAM

Concretely, our solution relies on the ORAM due to Chung and Pass [CP13], which in turn closely follows the tree-based ORAM construction of Shi et al. [SCSL11]. We now recall the [CP13] construction in greater detail, in order to introduce notation for the remainder of the paper. The [CP13] construction (as with [SCSL11]) proceeds by first presenting an intermediate solution achieving obliviousness, but in which the CPU must maintain a large number of registers ˜ (specifically, providing a means for securely storing n data items requiring CPU state size Θ(n/α), where α > 1 is any constant). Then, this solution is recursively applied logα n times to store the resulting CPU state, until finally reaching a CPU state size polylog(n), while only blowing up the computational overhead by a factor logα n. The overall compiler is fully specified by describing one level of this recursion. Step 1: Basic ORAM with O(n) registers. The compiler ORAM on input n ∈ N and a program Π with memory size n outputs a program Π0 that is identical to Π but each Read(r) or Write(r, val) is replaced by corresponding commands ORead(r), OWrite(r, val) to be specified shortly. Π0 has the same registers as Π and additionally has n/α registers used to store a position map Pos plus a polylogarithmic number of additional work registers used by ORead and OWrite. In its external memory, Π0 will maintain a complete binary tree Γ of depth ` = log(n/α); we index nodes in the tree by a binary string of length at most `, where the root is indexed by the empty string λ, and each node indexed by γ has left and right children indexed γ0 and γ1, respectively. Each memory cell r will be associated with a random leaf pos in the tree, specified by the position map Pos; as we shall see shortly, the memory cell r will be stored at one of the nodes on the path from the root λ to the leaf pos. To ensure that the position map is smaller than the memory size, we assign a block of α consecutive memory cells to the same leaf; thus memory cell r corresponding to block b = br/αc will be associated with leaf pos = Pos(b). Each node in the tree is associated with a bucket which stores (at most) K tuples (b, pos, v), where v is the content of block b and pos is the leaf associated with the block b, and K ∈ ω(log n) ∩ polylog(n) is a parameter that will determine the security of the ORAM (thus each bucket stores K(α + 2) words). We assume that all registers and memory cells are initialized with a special symbol ⊥. The following is a specification of the ORead(r) procedure: Fetch: Let b = br/αc be the block containing memory cell r (in the original database), and let i = r mod α be r’s component within the block b. We first look up the position of the block b using the position map: pos = Pos(b); if Pos(b) =⊥, set pos ← [n/α] to be a uniformly random leaf. Next, traverse the data tree from the root to the leaf pos, making exactly one read and one write operation for the memory bucket associated with each of the nodes along the path. More precisely, we read the content once, and then we either write it back (unchanged), or we 7

Position Map P os 1

2

···

3

···

b = b αr c pos = 011

n α

···

−1

n α

···

position of memory cell r is found here

ORAM Tree Γ flush along random path from λ to pos∗ = 110 λ

1

0

01

00

000

001

010

11

10

100

011

101

110

111

value of memory cell r is found somewhere on path from λ to pos = 011

Figure 1: Illustration of the basic [CP13] ORAM construction. simply “erase it” (writing ⊥) so as to implement the following task: search for a tuple of the form (b, pos, v) for the desired b, pos in any of the nodes during the traversal; if such a tuple is found, remove it from its place in the tree and set v to the found value, and otherwise take v =⊥. Finally, return the ith component of v as the output of the ORead(r) operation. Update Position Map: Pick a uniformly random leak pos0 ← [n/α] and let Pos(b) = pos0 .

Put Back: Add the tuple (b, pos0 , v) to the root λ of the tree. If there is not enough space left in the bucket, abort outputting overflow.

Flush: Pick a uniformly random leaf pos∗ ← [n/α] and traverse the tree from the roof to the leaf pos∗ , making exactly one read and one write operation for every memory cell associated with the nodes along the path so as to implement the following task: “push down” each tuple (b00 , pos00 , v 00 ) read in the nodes traversed so far as possible along the path to pos∗ while ensuring that the tuple is still on the path to its associated leaf pos00 (that is, the tuple ends up in the node γ = longest common prefix of pos00 and pos∗ .) Note that this operation can be performed trivially as long as the CPU has sufficiently many work registers to load two whole buckets into memory; since the bucket size is polylogarithmic, this is possible. If at any point some bucket is about to overflow, abort outputting overflow. OWrite(r, v) proceeds identically in the same steps as ORead(r), except that in the “Put Back” steps, we add the tuple (b, pos0 , v 0 ), where v 0 is the string v but the ith component is set to v (instead of adding the tuple (b, pos0 , v) as in ORead). (Note that, just as ORead, OWrite also outputs the ordinal memory content of the memory cell r; this feature will be useful in the “full-fledged” construction.) The full-fledged construction: ORAM with polylog registers. The full-fledged construction of the CP ORAM proceeds as above, except that instead of storing the position map in registers in the CPU, we now recursively store them in another ORAM (which only needs to operate on n/α 8

memory cells, but still using buckets that store K tuples). Recall that each invocation of ORead and OWrite requires reading one position in the position map and updating its value to a random leaf; that is, we need to perform a single recursive OWrite call (recall that OWrite updates the value in a memory cell, and returns the old value) to emulate the position map. At the base of the recursion, when the position map is of constant size, we use the trivial ORAM construction which simply stores the position map in the CPU registers. Theorem 2.2 ( [CP13]). The compiler ORAM described above is a secure Oblivious RAM compiler with polylog(n) worst-case computation overhead and ω(log n) memory overhead, where n is the database memory size.

2.3

Sorting Networks

Our protocol will employ an n-wire sorting network, which can be used to sort values on n wires via a fixed topology of comparisons. A sorting network consists of a sequence of layers, each layer in turn consisting of one or more comparator gates, which take two wires as input, and swap the values when in unsorted order. Formally, given input values ~x = (x1 , . . . , xn ) (which we assume to be integers wlog), a comparator operation compare(i, j, ~x) for i < j returns ~x0 where ~x = x~0 if xi ≤ xj , and otherwise, swaps these values as x0i = xj and x0j = xi (whereas x0k = xk for all k 6= i, j). Formally, a layer in the sorting network is a set L = {(i1 , j1 ), . . . , (ik , jk )} of pairwise-disjoint pairs of distinct indices of [n]. A d-depth sorting network is a list SN = (L1 , . . . , Ld ) of layers, with the property that for any input vector ~x, the final output will be in sorted order xi ≤ xi+1 ∀i < n. Ajtai, Koml´ os, and Szemer´edi demonstrated a sorting network with depth logarithmic in n. Theorem 2.3 ( [AKS83]). There exists an n-wire sorting network of depth O(log n) and size O(n log n). While the AKS sorting network is asymptotically optimal, in practical scenarios one may wish to use the simpler alternative construction due to Batcher [Bat68] which achieves significantly smaller linear constants.

3

Oblivious PRAM

The definition of an Oblivious PRAM (OPRAM) compiler mirrors that of standard ORAM, with the exception that the compiler takes as input and produces as output a parallel RAM program. Namely, denote the sequence of shared memory cell accesses made during an execution of a PRAM ˜ program Π on input (m, n, x) as Π(m, n, x). And, denote by ActivationPatterns(Π, m, n., x) the (public) CPU activation patterns (i.e., number of active CPUs per timestep) of program Π on input (m, n, x). We present a definition of an OPRAM compiler following Chung and Pass [CP13], which in turn follows Goldreich [Gol87]. Definition 3.1 (Oblivious Parallel RAM). A polynomial-time algorithm O is an Oblivious Parallel RAM (OPRAM) compiler with computational overhead comp(·, ·) and memory overhead mem(·, ·), if O given m, n ∈ N and a deterministic m-processor PRAM program Π with memory size n, outputs an m-processor program Π0 with memory size mem(m, n) · n such that for any input x, the parallel running time of Π0 (m, n, x) is bounded by comp(m, n) · T , where T is the parallel runtime of Π(m, n, x), and there exists a negligible function µ such that the following properties hold: 9

• Correctness: For any m, n ∈ N and any string x ∈ {0, 1}∗ , with probability at least 1 − µ(n), it holds that Π(m, n, x) = Π0 (m, n, x). • Obliviousness: For any two PRAM programs Π1 , Π2 , any m, n ∈ N, and any two inputs x1 , x2 ∈ {0, 1}∗ , if |Π1 (m, n, x1 )| = |Π2 (m, n, x2 )| and ActivationPatterns(Π1 , m, n, x1 )) = ˜ 0 (m, n, x1 ) is µ-close to Π ˜ 0 (m, n, x2 ) in statistical disActivationPatterns(Π2 , m, n, x2 ), then Π 1 2 0 tance, where Πi ← O(m, n, Πi ) for i ∈ {1, 2}. We remark that not all m processors may be active in every time step of a PRAM program Π, and thus its total computation cost may be significantly less than m · T . We wish to consider OPRAM compilers that also preserve the processor activation structure (and thus total computation complexity) of the original program up to polylogarithmic overhead. Of course, we cannot hope to do so if the processor activation patterns themselves reveal information about the secret data. We thus consider PRAMs Π whose activation schedules (m1 , . . . , mT ) are a-priori fixed and public. Definition 3.2 (Activation-Preserving). An OPRAM compiler O with computation overhead comp(·, ·) is said to be activation preserving if given m, n ∈ N and a deterministic PRAM program Π with memory size n and fixed (public) activation schedule (m1 , . . . , mT ) for mi ≤ m, the program Π0 output by O has activation schedule (m1 )ti=1 , (m2 )ti=1 , . . . , (mT )ti=1 , where t = comp(m, n). It will additionally be useful in applications (e.g., our construction of garbled PRAMs in Section 4, and the MPC for PRAMs of [BCP15]) that the resulting oblivious PRAM is collision free. Definition 3.3 (Collision-Free). An OPRAM compiler O is said to be collision free if given m, n ∈ N and a deterministic PRAM program Π with memory size n, the program Π0 output by O has the property that no two processors ever access the same data address in the same timestep. We now present our main result, which we construct and prove in the following subsections. Theorem 3.4 (Main Theorem: OPRAM). There exists an activation-preserving, collision-free OPRAM compiler with O(log(m) log3 (n)) worst-case computational overhead and f (n) memory overhead, for any f ∈ ω(1), where n is the memory size and m is the number of CPUs.

3.1

Rudimentary Solution: Requiring Large Bandwidth

We first provide a solution for a simplified case, where we are not concerned with minimizing communication between CPUs or the size of required CPU local memory. In such setting, communicating and aggregating information between all CPUs is “for free.” Our compiler Heavy-O, on input m, n ∈ N, fixed integer constant α > 1, and m-processor PRAM program Π with memory size n, outputs a program Π0 identical to Π, but with each Access(r, v) operation replaced by the modified procedure Heavy-OPAccess as defined in Figure 2. (Here, “broadcast” means to send the specified message to all other processors). Note that Heavy-OPAccess operates recursively for t = 0, . . . , dlogα ne. This corresponds analogously to the recursion in the [SCSL11, CP13] ORAM, where in each step the size of the required “secure database memory” drops by a constant factor α. We additionally utilize a space optimization due to Gentry et al. [GGH+ 13] that applies to [CP13], where the ORAM tree used for storing data of size n0 has depth log n0 /K (and thus n0 /K leaves instead of n0 ), where K is the bucket size. This enables the overall memory overhead to drop from ω(log n) (i.e., K) to ω(1) with minimal changes to the analysis. 10

Heavy-OPAccess(t, (ri , vi )): The Large Bandwidth Case To be executed by CP U1 , . . . , CP Um w.r.t. (recursive) database size nt := n/(αt ), bucket size K. Input: Each CP Ui holds: recursion level t, instruction pair (ri , vi ) with ri ∈ [nt ], global parameter α. Each CP Ui performs the following steps, in parallel

0. Exit Case: If t ≥ logα n, return 0. This corresponds to requesting the (trivial) position map for a block within a single-leaf tree. 1. Conflict Resolution (a) Broadcast the instruction pair (ri , vi ) to all CPUs. (b) Let bi = bri /αc. Locally aggregate incoming instructions to block bi as v¯i = v¯i [1] · · · v¯i [α], resolving write conflicts (i.e., ∀s ∈ [α], take v¯i [s] ← vj for minimal j such that rj = bi α+s). Denote by rep(bi ) := min{j : brj /αc = bi } the smallest index j of any CPU whose rj is in this block bi . (CPU rep(bi ) will actually access bi , while others perform dummy accesses). 2. Recursive Access to Position Map (Define Lt := 2nt /K, number of leaves in t’th tree). If i = rep(bi ): Sample fresh leaf id `0i ← [Lt ]. Recurse as `i ← Heavy-OPAccess(t + 1, (bi , `0i )) to read the current value `i of Pos(bi ) and rewrite it with `0i . Else: Recursively initiate dummy access x ← Heavy-OPAccess(t+1, (1, ⊥)) at arbitrary address (say 1); ignore the read value x. Sample fresh random leaf id `i ← [Lt ] for a dummy lookup.

3. Look Up Current Memory Values Read the memory contents of all buckets down the path to leaf node `i defined in the previous step, copying all buckets into local memory. If i = rep(bi ): locate and store target block triple (bi , viold , `i ). Update v¯ from Step 1 with existing data: ∀s ∈ [α], replace any non-written cell values v¯i [s] = ∅ with v¯i [s] ← viold [s]. v¯i now stores the entire data block to be rewritten for block bi . 4. Remove Old Data from ORAM Database (a) If i = rep(bi ): Broadcast (bi , `i ) to all CPUs. Otherwise: broadcast (⊥, `i ). (b) Initiate UpdateBuckets nt , (remove-bi , `i ), {(remove-bj , `j )}j∈[m]\{i} , as in Figure 3.

5. Insert New Data into Database in Parallel

(a) If i = rep(bi ): Broadcast (bi , v¯i , `0i ), with updated value v¯i and target leaf `0i . (b) Let lev∗ := blog(min{m, Lt })c be the ORAM tree level with number of buckets equal to number of CPUs (the level where data will be inserted). Locally aggregate all incoming ∗ instructions whose path `0j has lev∗ -bit prefix i: Inserti := {(bj , v¯j , `0j ) : (`0j )(lev ) = i}. (c) Access memory bucket i (at level lev∗ ) and rewrite contents, inserting data items Inserti . If bucket i exceeds its capacity, abort with overflow. 6. Flush the ORAM Database (a) Sample a random leaf node `flush ← [Lt ] along which to flush. Broadcast `flush . i i (b) If i ≤ Lt : Initiate UpdateBuckets nt , (flush, `flush ), {(flush, `flush )}j∈[m]\{i} , in Figure 3. i j Recall that flush means to “push” each encountered triple (b, `, v) down to the lowest point at which his chosen flush path and ` agree. 7. Update CPUs If i = rep(bi ): broadcast the old value viold of block bi to all CPUs. 11access procedure Heavy-OPAccess (where we are Figure 2: Pseudocode for oblivious parallel data temporarily not concerned with per-round bandwidth/memory).

UpdateBuckets nt , (mycommand, mypath), {(commandj , pathj )}j∈[m]\{i} Let path(0) , . . . , path(log Lt ) denote the bit prefixes of length 0 (i.e., ∅) to log(Lt ) of path. For each tree level lev = 0 to log Lt , each CPU i does the following at bucket mypath(lev) : (lev)

1. Define CPUs(mypath(lev) ) := {i} ∪{j : pathj = mypath(lev) } to be the set of CPUs requesting changes to bucket mypath(lev) . Let bucket-rep(mypath(lev) ) denote the minimal index in the set. 2. If i 6= bucket-rep(mypath(lev) ), do nothing. Otherwise:

Case 1: mycommand = remove-bi . Interpret each commandj = remove-bj as a target block id bj to be removed. Access memory bucket mypath(lev) and rewrite contents, removing any block bj for which j ∈ CPUs(mypath(lev) ). Case 2: mycommand = flush. (lev+1) Define Flush ⊂ {L, R} as {v : ∃ pathj s.t. pathj = mypath(lev) ||v}, associating L ≡ 0, R ≡ 1. This determines whether data will be flushed left and/or right from this bucket. Access memory bucket mypath(lev) ; denote its collection of stored data blocks b by ThisBucket. Partition ThisBucket = ThisBucket-L ∪ ThisBucket-R into those blocks whose associated leaves continue to the left or right (i.e., ThisBucket-L := {bj ∈ ThisBucket : (lev+1) `¯j = mypath(lev) ||0}, and similar for 1). • If L ∈ Flush, then set ThisBucket ← ThisBucket \ ThisBucket-L, access memory bucket mypath(lev) ||0, and insert data items ThisBucket-L into it. • If R ∈ Flush, then set ThisBucket ← ThisBucket \ ThisBucket-R, access memory bucket mypath(lev) ||1, and insert data items ThisBucket-R into it. Rewrite the contents of bucket mypath(lev) with updated value of ThisBucket. If any bucket exceeds its capacity, abort with overflow.

Figure 3: Procedure for combining CPUs’ instructions for buckets and implementing them by a single representative CPU. (Used for correctness, not security). See Figure 4 for a sample illustration. Lemma 3.5. For any n, m ∈ N, The compiler Heavy-O is a secure Oblivious PRAM compiler with ˜ parallel time overhead O(log3 n) and memory overhead ω(1), assuming each CPU has Ω(m) local memory. We will address the desired claims of correctness, security, and complexity of the Heavy-O compiler by induction on the number of levels of recursion. Namely, for t∗ ∈ [logα n], denote by ∗ Heavy-Ot∗ the compiler that acts on memory size n/(αt ) by executing Heavy-O only on recursion levels t = t∗ , (t∗ + 1), . . . , dlogα ne. For each such t∗ , we define the following property. Level-t∗ Heavy OPRAM: We say that Heavy-Ot∗ is a valid level-t∗ heavy OPRAM if the partial∗ recursion compiler Heavy-Ot∗ is a secure Oblivious PRAM compiler for memory size n/(αt ) ∗ with parallel time overhead O(log2 n · log(n/αt )) and memory overhead ω(1), assuming each ˜ CPU has Ω(m) local memory. Then Lemma 3.5 follows directly from the following two claims. Claim 3.6. Heavy-Ologα n is valid level-(logα n) heavy OPRAM. 12

CPU1 CPU2

1

CPU3

1

2

1

2

3

3

2

1

Figure 4: UpdateBuckets sample illustration. Here, CPUs 1-3 each wish to modify nodes along their paths as drawn; for each overlapping node, the CPU with lowest id receives and implements the aggregated commands for the node. Proof. Note that Heavy-Ologα n , acting on trivial size-1 memory, corresponds directly to the exit case (Step 0) of Heavy-OPAccess in Figure 2. Namely, correctness, security, and the required efficiency trivially hold, since there is a single data item in a fixed location to access. Claim 3.7. Suppose Heavy-Ot is a valid level-t heavy OPRAM for t > 0. Then Heavy-Ot−1 is a valid level-(t − 1) heavy OPRAM. Proof. We first analyze the correctness, security, and complexity overhead of Heavy-Ot−1 conditioned on never reaching the event overflow (which may occur in Step 5(c), or within the call to UpdateBuckets). Then, we prove that the probability of overflow is negligible in n. Correctness (w/o overflow). Consider the state of the memory (of the CPUs and server) in each step of Heavy-OPAccess, assuming no overflow. In Step 1, each CPU learns the instruction pairs of all other CPUs; thus all CPUs agree on single representative rep(bi ) for each requested block bi , and a correct aggregation of all instructions to be performed on this block. Step 2 is a recursive execution of Heavy-OPAccess. By the inductive hypothesis, this access successfully returns the correct value `i of Pos(bi ) for each bi queried, and rewrites it with the freshly sampled value `0i when specified (i.e., for each rep(bi ) access; the dummy accesses are read-only). We are thus guaranteed that each rep(bi ) will find the desired block bi in Step 3 when accessing the memory buckets in the path down the tree to leaf `i (as we assume no overflow was encountered), and so will learn the current stored data value vold . In Step 4, each CPU learns the target block bi and associated leaf `i of every representative CPU rep(bi ). By construction, each requested block bi appears in some bucket B in the tree along his path, and there there will necessarily be some CPU assigned as bucket-rep(B) in UpdateBuckets, who will then successfully remove the block bi from B. At this point, none of the requested blocks bi appear in the tree. In Step 5, the CPUs insert each block bi (with updated data value vi ) into the ORAM data tree at level min{logα n/αt , blog2 (m)c} along the path to its (new) leaf `0i . 13

Finally, the flushing procedure in Step 6 maintains the necessary property that each block bi appears along the path to Pos(bi ), and in Step 7 all CPUs learn the collection of all queried values vold (in particular, including the value they initially requested). Thus, assuming no overflow, correctness holds. Obliviousness (w/o overflow). Consider the access patterns to server-side memory in each step of Heavy-OPAccess, assuming no overflow. Step 1 is performed locally without communication to the server. Step 2 is a recursive execution of Heavy-OPAccess, which thus yields access patterns independent of the vector of queried data locations (up to statistical distance negligible in n), by the induction hypothesis. In Step 3, each CPU accesses the buckets along a single path down the tree, where representative CPUs rep(bi ) access along the path given by Pos(bi ) (for distinct bi ), and non-representative CPUs each access down an independent, random path. Since the adversarial view so far has been independent of the values of Pos(bi ), conditioned on this view all CPU’s paths are independent and random. In Step 4, all data access patterns are publicly determinable based on the accesses in the previous step (that is, the complication in Step 4 is to ensure correctness without access collisions, but is not needed for security). In Step 5, each CPU i accesses his corresponding bucket i in the tree. In the flushing procedure of Step 6, each CPU selects an independent, random path down the tree, and the communication patterns to the server reveal no information beyond the identities of these paths. Finally, Step 7 is performed locally without communication to the server. Thus, assuming no overflow, obliviousness holds. Protocol Complexity (w/o overflow). First note that the server-side memory storage requirement is simply that of the [CP13] ORAM construction, together with the log(2nt /K) tree-depth memory optimization of [GHL+ 14]; namely, f (n) memory overhead suffices for any f ∈ ω(1). Consider the local memory required per CPU. Each CPU must be able to store: O(log n)-size requests from each CPU (due to the broadcasts in Steps 1(a), 4(a), 5(a), and 7); and the data contents of at most 3 memory buckets (due to the flushing procedure in UpdateBuckets). Overall, ˜ ˜ notation hides log n factors). this yields a per-CPU local memory requirement of Ω(m) (where Ω Consider the parallel complexity of the OPRAM-compiled program Π0 ← Heavy-O(m, n, Π). For each parallel memory access in the underlying program Π, the processors perform: Conflict resolution (1 local communication round), Read/writing the position map (which has parallel complexity O(log2 n · log(n/αt )) by the inductive hypothesis), Looking up current memory values (sequential steps = depth of level-(t − 1) ORAM tree ∈ O(log(n/αt−1 ))), Removing old data from the ORAM tree (1 local communication round, plus depth of the ORAM tree ∈ O(log(n/αt−1 )) sequential steps), Inserting the new data in parallel (1 local communication round, plus 1 communication round to the server), Flushing the ORAM database (1 local communication round, and 2× the depth of the ORAM tree rounds of communication with the server, since each bucket along a flush path is accessed once to receive new data items and once to flush its own data items down), and Updating CPUs with the read values (1 local communication round). Altogether, this yields parallel complexity overhead O(log2 n · log(n/αt−1 )). It remains to address the probability of encountering overflow. Claim 3.8. There exists a negligible function µ such that for any deterministic m-processor PRAM program Π, any database size n, and any input x, the probability that the Heavy-O-compiled program

14

Π0 (m, n, x) outputs overflow is bounded by µ(n). Proof. We consider separately the probability of overflow in each of the level-t recursive ORAM trees. Since there are dlog ne of them, the claim follows by a straightforward union bound. Taking inspiration from [CP13], we analyze the ORAM-compiled execution via an abstract dart game. The game consists of black and white darts. In each round of the game, m black darts are thrown, followed by m white darts. Each dart independently hits the bullseye with probability p = 1/m. The game continues until exactly K darts have hit the bullseye (recall K ∈ ω(log n) is the bucket size), or after the end of the T th round for some fixed polynomial bound T = T (n), whichever comes first. The game is “won” (which will correspond to overflow in a particular bucket) if K darts hit the bullseye, and all of them are black. Let us analyze the probability of winning in the above dart game. Subclaim 1: With overwhelming probability in n, no more than K/2 darts hit the bullseye in any round. In any single round, associate with each of the 2 · m darts thrown an indicator variable Xi for whether the dart strikes the target. The Xi are independent random variables each equal to 1 with probability p = 1/m. Thus, the probability that more than K/2 of the darts hit the target is bounded (via a Chernoff tail bound3 ) by " 2m # X 2(K/4−1)2 Pr Xi > K/2 ≤ e 2+(K/4−1) ≤ e−Ω(K) ≤ e−ω(log n) . i=1

Since there are at most T = poly(n) distinct rounds of the game, the subclaim follows by a union bound. Subclaim 2: Conditioned on no round having more than K/2 bullseyes, the probability of winning the game is negligible in d. Fix an arbitrary such winning sequence s, which terminates sometime during some round r of the game. By assumption, the final partial round r contains no more than K/2 bullseyes. For the remaining K/2 bullseyes in rounds 1 through r − 1, we are in a situation mirroring that of [CP13]: for each such winning sequence s, there exist 2K/2 − 1 distinct other “losing” sequences s0 that each occur with the same probability, where any non-empty subset of black darts hitting the bullseye are replaced with their corresponding white darts. Further, every two distinct winning sequences s1 , s2 yield disjoint sets of losing sequences, and all such constructed sequences have the property that no round has more than K/2 bullseyes (since this number of total bullseyes per round is preserved). Thus, conditioned on having no round with more than K/2 bullseyes, the probability of winning the game is bounded above by 2−K/2 ∈ e−ω(log n) . We now relate the dart game to the analysis of our OPRAM compiler. We analyze the memory buckets at the nodes in the t-th recursive ORAM tree, via three subcases. Case 1: Nodes in level lev < log m. Since data items are inserted to the tree in parallel directly at level log m, these nodes do not receive data, and thus will not overflow. Case 2: Consider any internal node (i.e., a node that is not a leaf) γ in the tree at level log m ≤ lev < log(Lt ). (Recall Lt := 2nt /K is the number of leaves in the t’th tree when applying the [GHL+ 14] optimization). Note that when m > Lt , this case is vacuous. For purposes of analysis, consider the contents of γ as split into two parts: γL containing the data blocks whose leaf path 3

Explicit Chernoff bound used: for X = X1 + · · · X2m (Xi independent) and mean µ, then for any δ > 0, it holds 2 that Pr[X > (1 + δ)µ] ≤ e−δ µ/(2+δ) .

15

continues to the left from γ (i.e., leaf γ||0||·), and γR containing the data blocks whose leaf path continues right (i.e., γ||1||·). For the bucket of node γ to overflow, there must be K tuples in it. In particular, either γL or γR must have K/2 tuples. For each parallel memory access in Π(m, n, x), in the t-th recursive ORAM tree for which nt ≥ m/K, (at most) m data items are inserted, and then m independent paths in the tree are flushed. By definition, an inserted data item will enter our bucket γL (respectively, γR ) only if its associated leaf has the prefix γ||0 (resp., γ||1); we will assume the worst case in which all such data items arrive directly to the bucket. On the other hand, the bucket γL (resp., γR ) will be completely emptied after any flush whose path contains this same prefix γ||0 (resp., γ||1). Since all leaves for inserted data items and data flushes are chosen randomly and independently, these events correspond directly to the black and white darts in the game above. Namely, the probability that a randomly chosen path will have the specific prefix γ||0 of length lev is 2−lev ≤ 1/m (since we consider lev ≥ log m); this corresponds to the probability of a dart hitting the bullseye. The bucket can only overflow if K/2 “black darts” (inserts) hit the bullseye without any “white dart” (flush) hitting the bullseye in between. By the analysis above, we proved that for any sequence of K/2 bullseye hits, the probability that all K/2 of them are black is bounded above by 2−K/4 , which is negligible in n. However, since there is a fixed polynomial number T = poly(n) of parallel memory accesses in the execution of Π(m, n, x) (corresponding to the number of “rounds” in the dart game), and in particular, T (2m) ∈ poly(n) total darts thrown, the probability that the sequence of bullseyes contains K/2 sequential blacks anywhere in the sequence is bounded via a direct union bound by (T 2m)2−K/4 ∈ e−ω(log n) , as desired. Case 3: Consider any leaf node γ. This analysis follows the same argument as in [CP13] (with slightly tweaked parameters from the [GHL+ 14] tree-depth optimization). For there to be an overflow in γ at time t, there must be K + 1 out of nt /α elements in the position map that map to the leaf γ. Since all positions are sampled uniformly and independently among the Lt := 2nt /K different leaves, the expected number of elements mapping to γ is µ = K/2α, and by a standard multiplicative Chernoff bound,4 the probability that K + 1 elements are mapped to γ is upper bounded by µ e1 ≤ (21/3 )−K/2α ∈ 2−ω(log n) . (1 + 1)(1+1)

Thus, the total probability of overflow is negligible in n, and the theorem follows.

3.2 3.2.1

Oblivious Distributed Insertion, Aggregation, and Multi-Cast Oblivious Parallel Insertion (Oblivious Routing)

Recall during the memory “put-back” phase, each CPU must insert its data item into the bucket at level log m of the tree lying along a freshly sampled random path, while hiding the path. We solve this problem by delivering data items to their target locations via a fixed-topology routing network. Namely, the m processors CP U1 , . . . , CP Um will first write the relevant m data items msgi (and their corresponding destination addresses addri ) to memory in fixed order, and 4

We use the following version of the Chernoff bound: Let X1 , . . . , L [0, 1]-valued random variables. n be independent µ P eδ Let X = i Xi and µ = E[X]. For every δ > 0, Pr[X ≥ (1 + δ)µ] ≤ (1+δ)(1+δ) .

16

Parallel Insertion Routing Protocol Route(m, (msgi , addri )) Input: CP Ui holds: message msgi with target destination addri , and global threshold K. Output: CP Ui holds {msgj : addrj = i}. Let lev∗ = log m (assumed ∈ N for simplicity). Each CP Ui performs the following. Initialize Mi,0 ← msgi . For t = 1, . . . , lev∗ :

1. Perform the following symmetric message exchange with CP Ui⊕2t : Mi,t+1 ← {msgj ∈ Mi,t ∪ Mi⊕2t ,t : (addrj )t = (i)t }.

2. If |Mi,t+1 | > K (i.e., memory overflow), then CP Ui aborts. Figure 5: Fixed-topology routing network for delivering m messages originally held by m processors to their corresponding destination addresses within [m]. then rearrange them in log m sequential rounds to the proper locations via the routing network. At the conclusion of the routing procedure, each node j will hold all messages msgi for which addri = j. For simplicity, assume m = 2` for some ` ∈ N. The routing network has depth `; in each level t = 1, . . . , `, each node communicates with the corresponding node whose id agrees in all bit locations except for the tth (corresponding to his tth neighbor in the log m-dimensional boolean hypercube). These nodes exchange messages according to the tth bit of their destination addresses addri . This is formally described in Figure 5. After the tth round, each message msgi is held by a party whose id agrees with the destination address addri in the first t bits. Thus, at the conclusion of ` rounds, all messages are properly delivered. We demonstrate the case m = 8 = 23 below: first, CPUs exchange information along the depicted communication network in 3 sequential rounds (left); then, each CPU i inserts his resulting collection of items directly into node i of level 3 of the data tree (right).

1

CPUs

1

2

3

4

5

6

7

2

3

4

5

6

7

8

8

We show that if the destination addresses addri are uniformly sampled, then with overwhelming probability no node will ever need to hold too many (the threshold K will be set to ω(log n)) messages at any point during the routing network execution: Lemma 3.9 (Routing Network). If L messages begin with target destination addresses addri distributed independently and uniformly over [L] in the L-to-L node routing network in Figure 5, then with probability bounded by 1 − (L log L)2−K , no intermediate node will ever hold greater than K messages at any point during the course of the protocol execution. Proof. Consider an arbitrary node a ∈ {0, 1}` , at some level t of execution of the protocol. There are precisely 2t possible messages mi that could be held by node a at this step, corresponding to those originating in locations b ∈ {0, 1}` whose final ` − t bits agree with those of a. Node a will 17

hold message mb at the conclusion of round t precisely if the first t bits of addrb agree with those of a. For each such message mb , the associated destination address addrb is a random element of [L], which agrees with a on the first t bits with probability 2t . For each b ∈ {0, 1}` agreeing with a on the final ` − t bits, define Xb to be the indicator variable t that is equal to 1 if addrb agrees with a on the first t bits. Then variables P the collection of 2 random {Xb : bi = ai ∀i = t + 1, . . . , `} are independent, and X = Xb has mean µ = 2t · 2−t = 1. Note that X corresponds to the number of messages held by node a at level t. By a Chernoff bound,5 it holds that K−1 e Pr[X ≥ K] = Pr[X ≥ (1 + (K − 1))µ] < < 2−K . KK Then, taking a union bound over the total number of nodes L and levels ` = log L, we have that the probability of any node experiencing an overflow at any round is bounded by (L log L)2−K . 3.2.2

Oblivious Aggregation

To perform the “CPU-coordination” phase, the CPUs efficiently identify a single representative and aggregate relevant CPU instructions; then, at the conclusion, the representative CPU must be able to multi-cast the resulting information to all relevant requesting CPUs. Most importantly, these procedures must be done in an oblivious fashion. In this section, we address oblivious aggregation; we treat the dual multi-cast problem in Section 3.2.3. Formally, we want to achieve the following aggregation goal, with communication patterns independent of the inputs, using only O(log(m)polylog(n)) local memory and communication per CPU, in only O(log(m)) sequential time steps. An illustrative example to keep in mind is where keyi = bi , datai = vi , and Agg is the process that combines instructions to data items within the same data block, resolving conflicts as necessary. Oblivious aggregation: S Input: Each CPU i ∈ [m] holds (keyi , datai ). Let K = {keyi } denote the set of distinct keys. We assume that any (subset of) data associated with the same key can be aggregated by an aggregation function Agg to a short digest of size at most poly(`, log m), where ` = |datai |.

Goal: Each CPU i outputs outi such that the following holds. – For every key ∈ K, there exists unique agent i with keyi = key s.t. outi = (rep, key, aggkey ), where aggkey = Agg({dataj : keyj = key}). – For every remaining agent i, outi = (dummy, ⊥, ⊥).

At a high level, we achieve this via the following steps. (1) First, the CPUs sort their data list with respect to the corresponding key values. This can be achieved via an implementation of a log(m)-depth sorting network, and provides the useful guarantee that all data pertaining to the same key are necessarily held by an block of adjacent CPUs. (2) Second, we pass data among CPUs in a sequence of log(m) steps such that at the conclusion the “left-most” (i.e., lowest indexed) CPU in each key-block will learn the aggregation of all data pertaining to this key. Explicitly, in each step i, each CPU sends all held information to the CPU 2i to the “left” of him, and simultaneously accepts any received information pertaining to his key. (3) Third, each CPU will learn whether he is the “left-most” representative in each key-block, by simply checking whether his left-hand 5

Exact Chernoff bound used: Pr[X > (1 + δ)µ] <

eδ (1+δ)1+δ

18

µ

for any δ > 0.

neighbor holds the same key. From here, the CPUs have succeeded in aggregating information for each key at a single representative CPU; (4) in the fourth step, they now reverse the original sorting procedure to return this aggregated information to one of the CPUs who originally requested it. Lemma 3.10 (Space-Efficient Oblivious Aggregation). Suppose m processors initiate protocol OblivAgg w.r.t. aggregator Agg, on respective inputs {(keyi , datai )}i∈[m] , each of size `. Then at the conclusion of execution, each processor i ∈ [m] outputs a triple (rep0i , key0i , data0i ) such that the following properties hold (where asymptotics are w.r.t. m): 1. The protocol terminates in O(log m) rounds. 2. The local memory and computation required per processor is O(log m + `). S 3. (Correctness). For every key key ∈ {keyi }, there exists a unique processor i with output key0i = key. For each such processor, it further holds that key0i = keyi , rep0i = “rep”, and data0i = Agg({dataj : keyj = keyi }). For every remaining processor, the output tuple is (dummy, ⊥, ⊥).

4. (Obliviousness). The inter-CPU communication patterns are independent of the inputs (keyi , datai ). A full description of our Oblivious Aggregation procedure OblivAgg is given in Figure 6. Proof of Lemma 3.10. Property (1): Steps 1 and 4 of OblivAgg each execute a sorting network, and require communication rounds equal to the depth d ∈ O(log m) of the sorting network implemented. Step 2 takes place in log m sequential steps. Step 3 requires a single round. And Step 5 (output) takes place locally. Thus, the combined round complexity of OblivAgg is O(log m). Property (2): We first address the size the individual items stored, and then ensure the number of stored items is never too large. • Keys (e.g., keyi , tempkeyi ): Each key is bounded in size by the initial input size `.

• Data (e.g., datai , datatempi , aggdatai ): Similarly, by the property of the aggregation function Agg, we are guaranteed that each data item is bounded in size by the original data size, which is in turn bounded by size `. • CPU identifiers (e.g., sourceidi , idtempi ): Each processor can be identified by bit string of length log m. • Representative flag (repi ): The rep/dummy flag can be stored as a single bit.

Each processor begins with input size `. In each round of executing the first sorting network (Step 1 of OblivAgg), a processor must hold two sets of data (sourceid, keytemp, datatemp), corresponding to at most 2(log m + 2`) storage. Note that no more than 2 tuples are required to be held at any time within this step, as the processors exchange tuples but need not maintain both values. In each round of the Aggregation phase (Step 2), processors may need to store two pairs (keytemp, datatemp) in addition to the information held from the conclusion of the previous step (namely, a single value sourceidi ), which totals to log m+2(2`) memory. Note that by the properties of the aggregation scheme Agg, the size of the aggregated data does not grow beyond ` (and recall that parties do not maintain data associated with any different key). In the Representative Identification phase (Step 3), each processor receives one additional key value keyi−1 , which requires memory log m, and is then translated to a single-bit flag repi and then deleted. In the Reverse Sort phase (Step 4), processors within each round must again store two tuples, this time of the form (idtemp, rep, keytemp, datatemp), which corresponds to 2(log m + 1 + ` + `) memory. Thus, the total local memory requirement per processor is bounded by O(log m + `). 19

Oblivious Aggregation Procedure OblivAgg (w.r.t. Agg) Input: Each CPU i ∈ [m] holds a pair (keyi , datai ). Output: Each CPU i ∈ [m] outputs a triple (repi , keyi , aggdatai ) corresponding to either (dummy, ⊥, ⊥) or with aggdatai = Agg({dataj : keyj = keyi }), as further specified in Section 3.2. 1. Sort on keyi . Each CP Ui initializes a triple (sourceidi , keytempi , datatempi ) ← (i, keyi , datai ). For each layer L1 , . . . , Ld in the sorting network:

• Let L` = ((i1 , j1 ), . . . , (im/2 , jm/2 )) be the comparators in the current layer `. • In parallel, for each t ∈ [m/2], the corresponding pair of CPUs (CP Uit , CP Ujt ) perform the following pairwise sort w.r.t. key: If keytempjt < keytempit , then swap (sourceidit , keytempit , datatempit ) ↔ (sourceidjt , keytempjt , datatempjt ).

2. Aggregate to left. For t = 0, 1, . . . , log m:

• (Pass to left). Each CP Ui for i > 2t sends his current pair (keytempi , datatempi ) to CP Ui−2t . • (Aggregate). Each CP Ui for i < m − 2t receiving a pair (keytempj , datatempj ) will aggregate it into own pair if the keys match. That is, if keytempi = keytempj , then set datatempi ← Agg(datatempi , datatempj ). In both cases, the received pair is then erased.

The left-most CP Ui with keytempi = key now has Agg({datatempj : keytempj = key})).

3. Identify representatives. For each value keyj , the left-most CPU i currently holding keytempi = keyj will identify himself as (temporary) representative. • Each CP Ui for i < m: send keytempi to right-hand neighbor, CP Ui+1 . • Each CP Ui for i > 1: If the received value keytempi−1 matches his own keytempi , then set repi ← “dummy” and zero out keytempi ← ⊥, datatempi ← ⊥. Otherwise, set repi ← “rep”. (CP U1 always sets rep1 ← “rep”).

4. Reverse sort (i.e., sort on sourceidi ). Return aggregated data to a requesting CPU. For each layer L1 , . . . , Ld in the sorting network:

• Let L` = ((i1 , j1 ), . . . , (im/2 , jm/2 )) be the comparators in the current layer `. • Each CP Ui initializes idtemp ← sourceidi . In parallel, for each t ∈ [m/2], the corresponding pair of CPUs (CP Uit , CP Ujt ) perform the following pairwise sort w.r.t. sourceid: If idtempjt < idtempit , then swap (idtempit , repit , keytempit , datatempit ) ↔ (idtempjt , repjt , keytempjt , datatempjt ).

At the conclusion, each CP Ui holds a tuple (idtempi , repi , keytempi , datatempi ) with idtempi = i and keytempi = keyi . 5. Output. Each CP Ui outputs the triple (repi , keyi , datatempi ). Figure 6: Space-efficient oblivious data aggregation procedure.

20

Property (3): We now prove that the protocol results in the desired output. Consider the values stored by each processor at the conclusion of each phase of the protocol. After the completion of Step 1, by the correctness of the utilized sorting network, it holds that each CP Ui holds a tuple (sourceidi , keytempi , datatempi ) such that the list (sourceid1 , . . . , sourceidm ) is some permutation of [m], and keytempi ≤ keytempj for every i < j. Note that for each i it always the case that the pair (keytempi , datatempi ) currently held by CP Ui is precisely the original input pair of CP Uj for j = sourceidi . For the Aggregation phase in Step 2, we make the following claim. Claim 3.11. At the conclusion of Aggregate Left (Step 2), the CPU of lowest index i for which keytempi = key holds datatempi = Agg({dataj : keyj = key}) (for each value key). Proof. Fix an arbitrary value key, and let Skey ⊂ [m] denote the subset of processors for which keytempi = key. From the previous sorting step, we are guaranteed that Skey consists of an interval of consecutive processors istart , . . . , istop . Now, consider any j ∈ Skey (whose data CPU istart wishes to learn). For any pair of indices i < j ∈ Skey , denote by ti,j := max{t ∈ [log m] : (j ⊕ istart )t = 1} ∈ {0, 1, . . . , log m − 1} the highest index in which the bit representations of j and istart disagree. We now prove that for each such pair i, j, CP Ui will learn CP Uj ’s data after round ti,j ≤ log m. The claim will follow, by applying this statement to each pair (istart , j) with j ∈ Skey . Induct on ti,j . Base case ti,j = 0: follows immediately from the protocol construction; namely, in the 0-th round, each CPU j sends his data to CPU (j − 1), which in this case is precisely CPU i. Now, suppose the inductive hypothesis holds for all i < j with ti,j = t, and consider a pair i < j with ti,j = t + 1. In round t + 1 of the protocol, processor i receives from processor (i + 2t+1 ) the collection of all information it has aggregated up to round t. By the definition of ti,j , we know that i < (i + 2t+1 ) ≤ j, and that t(i+2t+1 ),j ≤ t. Indeed, we know that i and j differ in bit index (t + 1), and no higher; thus, (i + 2t ) must agree with j in index (t + 1) in addition to all higher indices. But, this means by the inductive hypothesis that CPU (i + 2t ) has learned CPU j’s data in a previous round. Thus, CPU i will learn CPU j’s data in round t + 1, as desired. In Step 3, each processor learns whether his left-hand neighbor holds the same temporary key as he does; that is, he learns whether or not he is the left-most CPU holding tempkeyi (and, in turn, holds the complete aggregation of all data relating to this key). Each processor for whom this is not the case sets his tuple to (dummy, ⊥, ⊥). At this point in the protocol, the processors have successfully reached the state where a single self-identified representative for each queried key holds the desired data aggregation. The final step is to return these information tuples to some CPU who originally requested this key. This is achieved in the final reverse sort (Step 4). Namely, by the correctness of the implemented sorting network, at the conclusion of Step 4 each CP Ui holds a tuple (idtempi , repi , keytempi , datatempi ) such that the ordered list (idtemp1 , . . . , idtempm ) is precisely the ordered list 1, . . . , m. Since the tuples (idtempi , repi , keytempi , datatempi ) are never modified (only swapped between processors), it remains to show that each non-dummy (repi , keytempi , datatempi ) tuple is received by an appropriate requesting CPU. But, that is precisely the information held by idtempi : the identity of the CPU who made the original request with respect to key keytempi . Thus, the reverse sort successfully routes the aggregated tuples back to a CPU making the correct key request.

21

Property (4): Since we utilize a sorting network with fixed topology, and the aggregate-toleft functionality has fixed communication topology, the inter-CPU communication patterns are constant, independent of the initial CPU inputs.

3.2.3

Oblivious Multicasting

Our goal for Oblivious Multicasting is dual to that of the previous section: Namely, a subset of CPUs must deliver information to (unknown) collections of other CPUs who request it. This is abstractly modeled as follows, where keyi denotes which data item is requested by each CPU i. Oblivious Multicasting: S Input: Each CPU i holds (keyi , datai ) with the following promise. Let K = {keyi } denote the set of distinct keys. For every key ∈ K, there exists a unique agent i with keyi = key such that datai 6= ⊥; let datakey denote such datai .

Goal: Each agent i outputs outi = (keyi , datakeyi ).

Figure 7 contains the protocol OblivMCast for achieving oblivious multicasting in a space-efficient fashion. This procedure is roughly the “dual” of the OblivAgg protocol in the previous section. Lemma 3.12 (Space-Efficient Oblivious Multicasting). Suppose m processors initiate protocol OblivMCast on respective inputs {(keyi , datai )}i∈[m] of size ` that satisfies the promise specified above. Then at the conclusion of execution, each processor i ∈ [m] outputs a pair (key0i , data0i ) such that the following properties hold (where asymptotics are w.r.t. m): 1. The protocol terminates in O(log m) rounds. ˜ 2. The local memory and computation required by each processor is O(log m + `). 3. (Correctness). For every i, key0i = keyi , and data0i = datakeyi . 4. (Obliviousness). The inter-CPU communication patterns are independent of the inputs (keyi , datai ). Proof. Identical to the proof of Oblivious Aggregation, Lemma 3.10.

3.3

Putting Things Together

We now combine the so-called “Heavy-OPAccess” structure of our OPRAM formalized in Section 3.1 (Figure 2) within the simplified “free CPU communication” setting, together with the (oblivious) Route, OblivAgg, and OblivMCast procedures constructed in the previous subsections (specified in Figures 5,6,7). For simplicity, we describe the case in which the number of CPUs m is fixed; however, it can be modified in a straightforward fashion to the more general case (as long as the activation schedule of CPUs is a-priori fixed and public). Recall the steps in Heavy-OPAccess where large memory/bandwidth are required. • In Step 1, each CP Ui broadcasts (ri , vi ) to all CPUs. Let bi = bri /αc. This is used to aggregate instructions to each bi and determine its representative CPU rep(bi ). • In Step 4, each CP Ui broadcasts (bi , `i ) or (⊥, `i ). This is used to aggregate instructions to each buckets along path `i about which blocks bi ’s to be removed.

22

Oblivious Multicasting Procedure OblivMCast S Input: Each CPU i holds (keyi , datai ) with the following promise. Let K = {keyi } denote the set of distinct keys. For every key ∈ K, there exists a unique agent i with keyi = key such that datai 6= ⊥; let datakey denote such datai . Output: Each agent i outputs outi = (keyi , datakeyi ). 1. Sort on (keyi , datai ). Each CP Ui initializes (sourceidi , keytempi , datatempi ) ← (i, keyi , datai ). For each layer L1 , . . . , Ld in the sorting network: • Let L` = ((i1 , j1 ), . . . , (im/2 , jm/2 )) be the comparators in the current layer `. • In parallel, for each t ∈ [m/2], the corresponding pair of CPUs (CP Uit , CP Ujt ) perform the following pairwise sort w.r.t. key, additionally pushing payloads datakey to the left: If (i) keytempjt < keytempit , or (ii) keytempjt = keytempit and datatempjt 6= ⊥, then swap (sourceidit , keytempit , datatempit ) ↔ (sourceidjt , keytempjt , datatempjt ).

2. Multicast to right. For t = 0, 1, . . . , log m:

• (Pass to right). Each CP Ui for i ≤ m − 2t sends his current pair (keytempi , datatempi ) to CP Ui+2t . • (Aggregate). Each CP Ui for i > 2t receiving a pair (keytempj , datatempj ) with j = i − 2t update its data as follows. If keytempi = keytempj and datatempj 6= ⊥, then set datatempi ← datatempj .

Every CPU i now holds (keytempi , datatempi ) = (key, datakey ) for some key ∈ K.

3. Reverse sort (i.e., sort on sourceidi ). Return received data to an original requesting CPU. For each layer L1 , . . . , Ld in the sorting network: • Let L` = ((i1 , j1 ), . . . , (im/2 , jm/2 )) be the comparators in the current layer `. • Each CP Ui initializes idtemp ← sourceidi . In parallel, for each t ∈ [m/2], the corresponding pair of CPUs (CP Uit , CP Ujt ) perform the following pairwise sort w.r.t. sourceid: If idtempjt < idtempit , then swap (idtempit , keytempit , datatempit ) ↔ (idtempjt , keytempjt , datatempjt ).

At the conclusion, each CP Ui holds a tuple with (idtempi , keytempi , datatempi ) with idtempi = i, keytempi = keyi , and datatempi = datakeyi . 4. Output. Each CP Ui outputs outputi = (keyi , datakeyi ). Figure 7: Space-efficient oblivious data multicasting procedure.

23

• In Step 5, each (representative) CP Ui broadcasts (bi , v¯i , `0i ). This is used to aggregate blocks to be inserted to each bucket in appropriate level of the tree. • In Step 6, each CP Ui broadcasts `flush . This is used to aggregate information about which i buckets the flush operation should perform. • In Step 7, each (representative) CP Urep(b) broadcasts the old value vold of block b to all CPUs, so that each CPU receives desired information. We will use oblivious aggregation procedure to replace broadcasts in Step 1, 4, and 6; the parallel insertion procedure to replace broadcasts in Step 5, and finally the oblivious multicast procedure to replace broadcasts in Step 7. Let us first consider the aggregation steps. For Step 1, to invoke the oblivious aggregation procedure, we set keyi = bi and datai = (ri mod α, vi ), and define the output of Agg({(ui , vi )}) to be a vector v¯ = v¯[1] · · · v¯[α] of read/write instructions to each memory cell in the block, where conflicts are resolved by writing the value specified by the smallest CPU: i.e., ∀s ∈ [α], take v¯[s] ← vj for minimal j such that uj = s and vj 6= ⊥. By the functionality of OblivAgg, at the conclusion of OblivAgg, each block bi is assigned to a unique representative (not necessarily the smallest CPU), who holds the aggregation of all instructions on this block. Both Step 4 and 6 invoke UpdateBuckets to update buckets along m random paths. In our rudimentary solution, the paths (along with instructions) are broadcast among CPUs, and the buckets are updated level by level. At each level, each update bucket is assigned to a representative CPU with minimal index, who performs aggregated instructions to update the bucket. Here, to avoid broadcasts, we invoke the oblivious aggregation procedure per level as follows. • In Step 4, each CPU i holds a path `i and a block bi (or ⊥) to be removed. Also note that the buckets along the path `i are stored locally by each CPU i, after the read operation in the previous step (Step 3). At each level lev ∈ [log n], we invoke the oblivious aggregation (lev) procedure with keyi = `i (the lev-bits prefix of `i ) and datai = bi if bi is in the bucket of (lev) node `i , and datai = ⊥ otherwise. We simply define Agg({datai }) = {b : ∃datai = b} to be the union of blocks (to be removed from this bucket). Since datai 6= ⊥ only when datai is in the bucket, the output size of Agg is upper bounded by the bucket size K. By the (lev) functionality of OblivAgg, at the conclusion of OblivAgg, each bucket `i is assigned to a unique representative (not necessarily the smallest CPU) with aggregated instruction on the bucket. Then the representative CPUs can update the corresponding buckets accordingly. • In Step 6, each CPU i samples a path `flush to be flushed and the instructions to each bucket i are simply left and right flushes. At each level lev ∈ [log n], we invoke the oblivious aggregation flush (lev)

procedure with keyi = `i and datai = L (resp., R) if the (lev + 1)-st bit of `flush is 0 (resp., i 1). The aggregation function Agg is again the union function. Since there are only two possible instructions, the output has O(1) length. By the functionality of OblivAgg, at the conclusion flush(lev) of OblivAgg, each bucket `i is assigned to a unique representative (not necessarily the flush(lev) smallest CPU) with aggregated instruction on the bucket. To update a bucket `i , the representative CPU loads the bucket and its two children (if needed) into local memory from the server, performs the flush operation(s) locally, and writes the buckets back.

Note that since we update m random paths, we do not need to hide the access pattern, and thus the dummy CPUs do not need to perform dummy operations during UpdateBuckets. A formal description of full-fledged UpdateBuckets can be found in Figure 8. 24

For Step 5, we rely on the parallel insertion procedure of Section 3.2.1, which routes blocks to proper destinations within the relevant level of the server-held data tree in parallel using a simple oblivious routing network. The procedure is invoked with msgi = bi and addri = `0i . Finally, in Step 7, each representative CPU rep(b) holds information of the block b, and each dummy CPU i wants to learn the value of a block bi . To do so, we invoke the oblivious multicast procedure with keyi = bi and datai = viold for representative CPUs and datai = ⊥ for dummy CPUs. By the functionality of OblivMCast, at the conclusion of OblivMCast, each CPU receives the value of the block it originally wished to learn. The Final Compiler. For convenience, we summarize the complete protocol. Our OPRAM compiler O, on input m, nt ∈ N and a m-processor PRAM program Π with memory size nt (which in recursion level t will be nt = n/αt ), will output a program Π0 that is identical to Π, but where each Access(r, v) operation is replaced by a sequence of operations defined by subroutine OPAccess(r, v), which we will construct over the following subsections. The OPAccess procedure begins with m CPUs, each with a requested data cell ri (within some α-block bi ) and some action to be taken (either ⊥ to denote read, or vi to denote rewriting cell ri with value vi ). 1. Conflict Resolution: Run OblivAgg on inputs {(bi , vi )}i∈[m] to select a unique representative rep(bi ) for each queried block bi and aggregate all CPU instructions for this bi (denoted v¯i ). 2. Recursive Access to Position Map: Each representative CPU rep(bi ) samples a fresh random leaf id `0i ← [nt ] in the tree and performs a (recursive) Read/Write access command on the position map database `i ← OPAccess(t + 1, (bi , `0i )) to fetch the current position map value ` for block bi and rewrite it with the newly sampled value `0i . Each dummy CPU performs an arbitrary dummy access (e.g., garbage ← OPAccess(t + 1, (1, ∅))).

3. Look Up Current Memory Values: Each CPU rep(bi ) fetches memory from the database nodes down the path to leaf `i ; when bi is found, it copies its value vi into local memory. Each dummy CPU chooses a random path and make analogous dummy data fetches along it, ignoring all read values. (Recall that simultaneous data reads do not yield conflicts). 4. Remove Old Data: For each level in the tree, • Aggregate instructions across CPUs accessing the same “buckets” of memory (corresponding to nodes of the tree) on the server side. Each representative CPU rep(b) begins with the instruction of “remove block b if it occurs” and dummy CPUs hold the empty instruction. (Aggregation is as before, but at bucket level instead of the block level). • For each bucket to be modified, the CPU with the smallest id from those who wish to modify it executes the aggregated block-removal instructions for the bucket. Note that this aggregation step is purely for correctness and not security. 5. Insert Updated Data into Database in Parallel: Run Route on inputs {(m, (msgi , addri ))}i∈[m] , where for each rep(bi ), msgi = (bi , v¯i , `0i ) (i.e., updated block data) and addri = [`0i ]log m (i.e., level-log m-truncation of the path `0i ), and for each dummy CPU, msgi , addri = ∅.

6. Flush the ORAM Database: In parallel, each CPU initiates an independent flush of the ORAM tree. (Recall that this corresponds to selecting a random path down the tree, and pushing all data blocks in this path as far as they will go). To implement the simultaneous flush commands, as before, commands are aggregated across CPUs for each bucket to be modified, and the CPU with the smallest id performs the corresponding aggregated set of 25

UpdateBuckets (m, (commandi , pathi )) Let path(1) , path(2) , . . . , path(log n) denote the bit prefixes of length 1 to log n of path. For each level lev = 1, . . . , log n of the tree: 1. The CPUs invoke the oblivious aggregation procedure OblivAgg as follows. Case 1: commandi = remove-bi . (lev) (lev) Each CPU i sets keyi = pathi and datai = bi if bi is in the bucket of node `i , and datai = ⊥ otherwise. Use the union function Agg({datai }) = {b : ∃datai = b} as the aggregation function. Case 2: commandi = flush. (lev) Each CPU i sets keyi = pathi and datai = L (resp., R) if the (lev + 1)-st bit of pathi is 0 (resp., 1). Use the union function as the aggregation function. (lev)

At the conclusion of the protocol, each bucket pathi is assigned to a representative CPU (lev) bucket-rep(pathi ) with aggregated commands agg-commandi . 2. Each representative CPU performs the updates: (lev)

If i 6= bucket-rep(pathi

), do nothing. Otherwise:

Case 1: commandi = remove-bi . (lev) by accessing memory bucket Remove all blocks b ∈ agg-commandi in the bucket pathi (lev) pathi and rewriting contents. Case 2: commandi = flush. (lev) (lev) (lev) Access memory buckets pathi , pathi ||0, pathi ||1, perform flush operation locally according to agg-commandi ⊂ {L, R}, and write the contents back. (lev) Specifically, denote the collection of stored data blocks b in pathi by ThisBucket. Partition ThisBucket = ThisBucket-L ∪ ThisBucket-R into those blocks whose associated leaves (lev+1) continue to the left or right (i.e., {bj ∈ ThisBucket : `¯j = mypath(lev) ||0}, and similar for 1). • If L ∈ agg-commandi , then set ThisBucket ← ThisBucket \ ThisBucket-L, and insert (lev) data items ThisBucket-L into bucket pathi ||0. • If R ∈ agg-commandi , then set ThisBucket ← ThisBucket \ ThisBucket-R, and insert (lev) data items ThisBucket-L into bucket pathi ||0. Figure 8: A space-efficient implementation of the UpdateBuckets procedure.

26

commands. (For example, all CPUs will wish to access the root node in their flush; the aggregation of all corresponding commands to the root node data will be executed by the lowest-numbered CPU who wishes to access this bucket, in this case CPU 1). 7. Return Output: Run OblivMCast on inputs {(bi , vi )}i∈[m] (where for dummy CPUs, bi , v¯i := ∅) to communicate the original (pre-updated) value of each data block bi to the subset of CPUs that originally requested it. A few remarks regarding our construction. Remark 3.13 (Truncating OPRAM for Fixed m). In the case that the number of CPUs m is fixed and known a priori, the OPRAM construction can be directly trimmed in two places. Trimming tops of recursive data trees: Note that data items are always inserted into the OPRAM trees at level log m, and flushed down from this level. Thus, the top levels in the ORAM tree are never utilized. In such case, the data buckets in the corresponding tops of the trees, from the root node to level log m for this bound, can simply be removed without affecting the OPRAM. Truncating recursion: In the t-th level of recursion, the corresponding database size shrinks to nt = n/αt . In recursion level logα n/m (i.e., where nt = m), we can then achieve oblivious data accesses via local CPU communication (storing each block i ∈ [nt ] = [m] locally at CPU i, and running OblivAgg, OblivMCast directly) without needing any tree lookups or further recursion. …%

[Truncated%tree%tops]%

Size%n/αi" m"

Size%n/α2%

log%m"

[Truncated%recursion]% Size%n/α% Size%n"

Remark 3.14 (Collision-Freeness). In the compiler above, CPUs only access the same memory address simultaneously in the (read-only) memory lookup in Step 3. However, a simple tweak to the protocol, replacing the direct memory lookups with an appropriate aggregation and multicast step (formally, the procedure UpdateBuckets as described in the appendix), yields collision freeness.

4

Garbled PRAM

As an application of OPRAM, we demonstrate a construction of garbled parallel RAMs. Specifically, we show that the IBE-based garbled RAM of Gentry et al. [GHL+ 14] (which in turn builds upon [LO13b]) can be directly generalized to garble PRAMs in a simple and modular way, given an OPRAM compiler with certain properties, and instead relying on 2-level hierarchical IBE. We then show (in the appendix) how to obtain these required properties generically from any OPRAM, and how to reduce the assumption from 2-HIBE back to IBE with a further modification of the scheme. We remark that constructions of garbled RAM can be obtained directly from one-way functions [GHL+ 14, GLOS15, GLO15], and leave as an interesting open problem how to extend these techniques to the PRAM setting. We start by generalizing the notion of garbled RAM [LO13b,GHL+ 14] to garbled PRAM, where the main difference is that a PRAM program Π consists of m CPUs. We allow each CPU ` to take a short input x` , which can be thought of as the initial CPU state. We model the garbling algorithm and garbled program evaluator also as PRAMs, and aim to preserve the parallel runtime of Π. 27

4.1

Definition of Garbled PRAM

Following [GHL+ 14], we consider a scenario where an initial memory data meminit is garbled once, and then multiple garbled PRAM programs can be executed in a fixed order with the memory changes persisting throughout executions. Our presentation here follows closely to [GHL+ 14]. Definition 4.1 (Garbled PRAM). A garbled PRAM scheme consists of a tuple of procedures (GData, GProg, GInput, GEval) with the following syntax: ˜ ← GData(mem, k): Takes initial memory data mem ∈ {0, 1}n and a key k. Outputs the • mem ˜ garbled data mem. in ˜ k ) ← GProg(Π, k, n, tinit , tcur ): Takes a key k and a description of a RAM program P • (Π, with memory-size n and run-time consisting of tcur parallel CPU timesteps. In the case of garbling multiple programs, we also provide tinit indicating the cumulative timesteps executed ˜ and an input-garbling-key k in . by all previous programs. Outputs a garbled program Π • x ˜ ← GInput(x, k in ): Takes an input vector x = (x1 , . . . , xm ) and input-garbling-key k in and outputs a garbled input vector x ˜ = (˜ x1 , . . . , x ˜m ). ˜ ˜ x ˜ • y = GEvalmem (Π, ˜): Takes a garbled program mem, garbled input vector x ˜ and garbled ˜ and computes the output y = ΠD (x). memory data mem We model these procedures as PRAM programs, and require both GProg and GEval to preserve the parallel runtime of Π. We additionally require GData to be parallelizable across CPUs. On the other hand, the size of the garbled program may be proportional to the total time complexity of Π. Π cur ·polylog(n)· • (Parallel) Efficiency: The parallel runtime of GProg and GEval must be |CCP U |·t poly(κ), where κ is the security parameter. The parallel time of GData must be n/m·polylog(κ), where m is the number of processors of the PRAM program to evaluate GData.

The correctness and security requirements of garbled PRAM are identical to that of garbled ˜ ← GData(mem, k) and for RAM. Consider the following experiment: choose a key k ← {0, 1}κ , mem P ∈ init = ˜ i , k ∈ ) ← GProg(Pi , n, tinit , ti , k), and x i = 1, . . . , s: (Π ˜ ← GInput(x , k i i i j∈[i−1] ti i i ), where ti denotes the parallel runtime of all programs prior to Πi . Let ˜ ˜ 1, x ˜ s, x (y10 , . . . , ys0 ) = (GEval(Π ˜1 ), . . . , GEval(Π ˜s ))mem

denote the output of evaluating the garbled programs sequentially over the garbled memory. We require • Correctness: Pr[yi0 = yi ∀i ∈ [s]] ≥ 1 − µ(κ), where µ(·) is a negligible function. • Security: There exists a universal simulator Sim such that

˜ 1, . . . , Π ˜ s, x ˜ Π (mem, ˜1 , . . . , x ˜s ) ≈ Sim(1κ , {Pi , ti , yi }si=1 , n). We also define a weaker security notion of security with unprotected memory access (UMA) for garbled PRAM in an analogous way to [GHL+ 14], where the simulator is additionally given the initial memory data mem, as well as the history of memory access throughout the computation, including both access pattern and memory update content.

28

Write Write Definition 4.2 (UMA security). Let MemAccess = {(addrRead j,` , addrj,` , bj,` ) : j = 1, . . . , t, ` = 1, . . . , m} denote the output memory instruction of the CPU-step for each CPU and each timestep of the execution. A garbled PRAM has (weaker) security with Unprotected Memory Accesses (UMA) if in the place of the Security requirement in Definition 4.1, we require only existence of a universal simulator Sim such that

˜ 1, . . . , Π ˜ s, x ˜ Π (mem, ˜1 , . . . , x ˜s ) ≈ Sim(1κ , {Pi , ti , yi }si=1 , mem, MemAccess, n). Finally, we also define a predictably timed writes (ptWrites) property for a PRAM program in an analogous way, which is used in intermediate steps of our garbled PRAM construction. Definition 4.3 (ptWrites). A collision-free PRAM program Π has predictably timed writes (ptWrites) if there exists a poly-size circuit WriteTime such that the following holds for any execution of Π, each timestep j, and each CPU `. Let the input/outputs of the timestep of the CPU be Read Write Write Read Π Read CCP U (statej,` , bj,` ) = (statej+1,` , addrj,` , addrj,` , bj,` ). Then, u = WriteTime(j, `, statej,` , addrj,` ) at timestep u. is the largest value of u < j such that some CPU ` wrote to location addrRead j,`

4.2

Overview of GPRAM Construction

At a high level, our construction takes the following form, analogous to the steps in [GHL+ 14]: ptWrites, OPRAM+ (2) (3) PRAM (1) Garbled PRAM −→ Collision free −→ Collision free −→ Π G(Π) O(Π) O(Π)cf tw Step (1) is a collision-free “OPRAM+ ” compiler, consisting of standard collision-free OPRAM (as defined and constructed in the previous sections), together with a simple layer of symmetric-key encryption (SKE). Namely, data is encrypted using the SKE under a random key k that is hardcoded into each CPU. Within each CPU step, read values are decrypted before computation, and values to write are first encrypted (both using k). Thus, OPRAM+ hides both the memory content and memory access patterns of the original program (i.e., these values can be simulated). Step (2) converts a collision-free OPRAM+ compiled program to one with predictably timed writes (ptWrites), while preserving the above simulation property and collision freeness. This can be achieved by combining the generic transformation of [GHL+ 14] to obtain the ptWrites property, together with techniques developed in our OPRAM construction in order to regain collision-freeness. We elaborate on this transformation in Section 4.3. Step (3) converts any collision-free, ptWrites PRAM into one with security with unprotected memory access (UMA), as defined by [GHL+ 14] (i.e., that it leaks only memory access patterns and database memory contents). When composed with the initial OPRAM+ compiler, this yields full GPRAM security. We elaborate on this transformation in Section 4.4

4.3

Obtaining ptWrites and Collision-Freeness

As part of their garbled RAM construction, Gentry et al. [GHL+ 14] provide a general transformation taking any (sequential) RAM program generically to an equivalent one with the predictably timed writes (ptWrites) property. The same approach may be taken in the PRAM setting, but direct application of the [GHL+ 14] transformation introduces access collisions across CPUs, which 29

will be a problem when attempting to garble the program (see Section 4.4). To avoid this, we will apply a second transformation on top that removes these collisions. We make use of the specific structure of the [GHL+ 14] transformation (and assume that we begin with an original PRAM that is collision-free). The [GHL+ 14] transformation applies a binary tree on top of the original data, where the leaves of the tree correspond to the bits of the original data, and each internal node of the tree contains the last write time of each of its two children (initially, these are all set to 0). For each memory access request to location addr in the original data, the transformed program will now access the path of nodes in the tree down the path to addr. The last-write time of the root corresponds to the total number of write operations performed so far, which can be stored within the state of the computation. Whenever a node is accessed, we temporarily remember the last-write-time of its children (by keeping this info in the state). This ensures that before the contents of any node in the tree are read (including the actual data at the leaves), its last-write time is known. To write to some location in the original data, the same procedure is followed as in the case of a read, but after the values in each node are read, we also increment the last-write-time for the corresponding child on the path to the leaf. The resulting overhead is log n (for data size n), since each memory access is now performed by accessing a log n-depth path in the tree. Now, consider imposing the same tree structure in the PRAM setting. If the original PRAM was collision free, then no two CPUs will wish to access the same leaf node addr in any step. However, they will necessarily have collisions in nodes higher in the tree. We observe that this is precisely the same scenario as faced in our OPRAM construction, when CPUs wished to simultaneously update distinct paths within the ORAM data tree. To address this, we provided the UpdateBuckets procedure (Figure 8), where for each level of the tree, the CPUs perform a “coordination stage” (communicating through coordinated reads/writes in the memory) in which for every collision the CPU with the smallest id receives and implements the aggregated collection of instructions to take place at the target memory address. This same procedure will also successfully remove collisions in the ptWrites-compiled PRAM program. The resulting overhead is a factor of log m, since in each level of the tree (i.e., each memory access in the ptWrites-compiled program), the m CPUs must execute the O(log m)-cost UpdateBuckets procedure. Theorem 4.4 (ptWrites and Collision Freeness). There exists an efficient compiler taking any collision-free PRAM Π to a functionally equivalent collision-free PRAM Π0 with ptWrites, with both total and parallel overhead polylog(n). If the original program has simulatable data values and access patterns, then this property is preserved.

4.4

Obtaining UMA-Secure GPRAM

We first describe the construction of [GHL+ 14] for obtaining UMA-secure garbled RAM, and then present our analogous construction for garbled PRAM. Construction of [GHL+ 14] and its UMA Security. Let Π be a RAM program with ptWrites Π property. Π is represented as a small CPU-step circuit CCP U which executes each single CPU step. Π Namely, CCP U on input a CPU state state and a read-bit bRead read from memory, outputs an updated CPU state state0 , a next read location addrRead , write location addrWrite , and a bit value Π bWrite to write to addrWrite . The RAM computation is done by iteratively applying CCP U for t

30

steps starting with some initial state stateinit and memory meminit , where t is the runtime of the computation. Π At a high level, Π is garbled by garbling t copies of some “augmented” CPU-step circuit CCP . U+ The garbled CPU-step circuits can pass the CPU state securely from one to the next by identifying Π the state output wire labels of j-th garbled circuit C˜CP (j) to the state input wire labels of j +1-st U+ Π ˜ garbled circuit CCP U + (j+1). The main issue is to handle memory accesses, which deal with runtime information that cannot be determined in the compile time (i.e., the time to generate garbled Π program). To handle a memory read, C˜CP (j) outputs some translation information translate, U+ Read ˜ which together with the garbled memory bit mem[addr ] allows the evaluator to compute the Read Π Π ˜ input label of the read-bit b of the next garbled circuit CCP (j + 1). To do so, C˜CP (j) has U+ U+ Π Read ˜ both labels label0 and label1 of CCP U + (j + 1)’s b wire hard-wired in, the translation information translate consists of encryptions (ct0 , ct1 ) of the labels (label0 , label1 ) under distinct keys, and the Read ˜ garbled memory bit mem[addr ] stores exactly one of the secret key skb that allows the evaluator to decrypt labelb of the bit value of addrRead while hides the other label¯b . In this way, writing to memory corresponds to outputting an appropriate version of a secret key. A subtle circularity issue may arise in the above strategy. Roughly speaking, the security of garbled circuits relies on one label for each input wire being hidden, which in ture relies on the Π semantic security of the encryption scheme. However, to update memory, C˜CP (j) needs to have U+ the ability to produce secret keys (say, with some master secret key hard-wired in). Thus, semantic security in turn relies on the security of the garbled circuits. To cope with circularity, [GHL+ 14] relies on a weaker “bounded” variant of 2-level hierachical IBE (HIBE) called timed IBE (TIBE), which can be constructed based on any regular IBE. Here, we present their construction based on 2-level HIBE, which enables a clean generalization to the parallel setting. We discuss how to modify the construction to reduce the assumption back down to IBE in the end of this section. ˜ Specifically, in the [GHL+ 14] construction, a garbled memory bit mem[addr] is a secret key skid of a 2-level HIBE scheme with identity id = (lwtime, (addr, b)) indexed by the timestep lwtime that the memory is updated, the address addr of the memory, and the bit value b stored in the memory. Here, the first-level id is the timestep lwtime, and the second-level id is (addr, b). To compute Π the translation information translate = (ct0 , ct1 ) for read location addrRead , C˜CP (j) relies on the U+ Read ptWrites property to compute the last access time lwtime of addr , and encrypts each labelb (which are both hardwired) with identity (lwtime, addrRead , b) using the hardwired master public key mpk. Namely, ctb = Encmpk (labelb , (j, (addrRead , b))) for each b ∈ {0, 1}. To write bWrite to Π memory location addrWrite , a delegation key dskj is hard-wired in C˜CP (j) to generate skid with U+ Write Write identity id = (j, (addr ,b )). The initial memory content is garbled using timestep lwtime = 0, ˜ init [addr] = sk(0,(addr,meminit [addr])) . namely, mem At a high level, the UMA security is proved by a sequence of hybirds that “erase” the computation by “erasing” the garbled circuits and “unused” input labels step by step “forward in time.” Π Namely, starting from the real garbled program, the first garbled CPU-step circuit C˜CP (j = 1) U+ is “erased” by replacing it with a simulated one, then the unused input lables of the second garbled Π CPU-step circuit C˜CP (2) are “erased” by replacing ciphertexts in translate with encryption of U+ Π ˜ dummy, then CCP U + (2) is erased, and so on. This can be done since each time when we want to Π erase a garbled circuit C˜CP (j), we are in a hybrid where one of each input wire labels is inforU+ Π mation theoretically erased, and when we want to erase the “unused” input label for C˜CP (j + 1), U+ the ciphertexts are encrypted with timestep ≤ j and all “future” garbled circuits only contain 31

delegation keys with timestep ≥ j + 1. At the end, this leads to a hybrid that can be simulated by a UMA simulator who is given the inital memory content as well as complete history of memory access. Our Construction of UMA-Secure Garbled PRAM. Let Π be a PRAM program with Π ptWrites and collision free property with CPU-step circuit CCP U (recall that all CPUs have the same CPU program with the same input/output interface as the RAM program). We show that the above construction of [GHL+ 14] can be directly generalized to garble Π with UMA security. Π For each timestep j, instead of one garbled CPU-step circuit C˜CP (j), we generate m garbled U+ Π ˜ CPU-step circuits CCP U + (j, `), one for each CPU ` ∈ [m]. As before, each garbled CPU-step circuit Π Π C˜CP (j, `) can pass its CPU state securely to the next timestep C˜CP (j + 1, `) by identifying U+ U+ wire labels. Also, thanks to the collision free and ptWrites property, memory access can be handled ˜ in the same way. Namely, each garbled memory bit mem[addr] is a secret key skid with idenΠ ˜ tity id = (lwtime, (addr, b)). To handle memory read, CCP U + (j, `) computes translate = (ct0 , ct1 ) with ctb = Encmpk (labelb , (j, (addrRead , b))) using hard-wirded master public key mpk. To hanΠ dle memory write, delegation key dskj is hard-wired in C˜CP (j, `) to generate skid with identity U+ Write Write id = (j, (addr ,b )). Note that all CPUs handle memory access in the same way, independent of their CPU id `. Note that ptWrites of the original program Π is required for correctness of the scheme (as in [GHL+ 14]), and that collision-freeness is crucial for security. Indeed, if there is a write collision of two CPUs in the same timestep with different write values, this would release both 0 and 1 HIBE secret keys for the corresponding memory address in the GPRAM evaluation, which will decrypt both the 0 and 1 input labels for the next garbled circuit who reads in this value. • GData: The initial memory content is garbled using timestep lwtime = 0 as before. Namely, for each location addr, the corresponding garbled data bit will be a 2-HIBE secret key corre˜ init [addr] = sk(0,(addr,meminit [addr])) . sponding to identity (0, (addr, meminit [addr])): i.e., mem Π • GProg: Generate m garbled CPU-step circuits C˜CP U + (j, `), one for each CPU ` ∈ [m]. This is done in reverse chronological order: for each timestep j, the resulting garbled input wire labels are hardcoded into the circuit to be garbled for timestep j − 1. In addition, within each circuit for timestep j is hardcoded the 2-HIBE public key pk and a delegated secret key skj that can generate 2-HIBE secret keys for ids (j, ·).

• GInput: Initial CPU state inputs are garbled simply as the corresponding input labels to the m garbled circuits at initial timestep 1. • GEval: Evaluate the m garbled circuits in parallel for each timestep, mimicking [GHL+ 14].

Theorem 4.5. Suppose Π is an m-processor PRAM with collision-free accesses and ptWrites. Then, assuming the existence of 2-HIBE, the procedures (GData, GProg, GInput, GEval) described above yield a UMA-secure garbled PRAM of size O(poly(κ) · m · time(Π)) and (parallel) evaluation time O(poly(κ) · time(Π)). Sketch of proof. The size of the garbled PRAM corresponds to m · time(Π) garbled CPU-step circuits, which may be garbled in parallel time comparable to time(Π) (since CPU-step circuits for the m CPUs may be garbled in parallel for each timestep). The proof of security mirrors that of [GHL+ 14], except that we now “erase” garbled circuits and unused input labels along two dimensions: first removing each garbled CPU circuit one by one 32

for a given time step j, and then progressing “forward in time” to the next time (j + 1). This can Π be done since each time when we want to erase a garbled circuit C˜CP U (j, `), we are in a hybrid where one of each input wire labels is information theoretically erased, and when we want to erase Π the “unused” input label for C˜CP U (j + 1, `), the ciphertexts are encrypted with timestep ≤ j and all “future” garbled circuits only contains delegation keys with timestep ≥ j + 1.

4.5

GPRAM: Combining the Steps

Combining Theorems 4.4 and 4.5, we obtain UMA-secure GPRAM for any PRAM, assuming 2HIBE. It remains to combine this with the original collision-free OPRAM+ step to obtain full security, and to reduce the 2-HIBE assumption back down to IBE. Full Security. Recall that UMA security leaks the patterns of memory accesses, and the values held in memory during the GPRAM evaluation. Following the generic transformation of [GHL+ 14] (which generalized to the parallel setting directly), when the PRAM program Π is first compiled by OPRAM+ compiler (as discussed in Section 4.2), then the final garbled PRAM program G(Π) is fully secure. Indeed, the OPRAM+ compiler precisely guarantees that these values can be simulated without any secret information: OPRAM for the memory access patterns, and the extra layer of SKE for the values stored in memory. Reducing the Assumption to IBE. Note that the above construction of garbled PRAM relies on 2-level HIBE, instead of the timed IBE (TIBE) used in [GHL+ 14]. The reason is that in TIBE, each delegation key dskj can only be used to generate a single secret key skid with id = (j, ·) (otherwise, the security breaks down). Namely, TIBE can be viewed as 2-level HIBE with “1bounded key delegation security.” In the PRAM setting, the m CPUs may perform parallel writes (to distinct locations) in a timestep j, which create m secret keys with the same j. To overcome this problem, simply “generalize” a timestep to consist of pair (t, i) corresponding to an actual timestep t and a processor i (and record these generalized timesteps in the ptWritestree); this means that generalize timesteps are only used once and TIBE suffices.

References [Ajt10]

Mikl´ os Ajtai, Oblivious rams without cryptogarphic assumptions, STOC, 2010, pp. 181– 190.

[AKS83]

M. Ajtai, J. Koml´ os, and E. Szemer´edi, An 0(n log n) sorting network, Proceedings of the Fifteenth Annual ACM Symposium on Theory of Computing (New York, NY, USA), STOC ’83, ACM, 1983, pp. 1–9.

[Bat68]

K. E. Batcher, Sorting networks and their applications, Proceedings of the April 30– May 2, 1968, Spring Joint Computer Conference (New York, NY, USA), AFIPS ’68 (Spring), ACM, 1968, pp. 307–314.

[BCP15]

Elette Boyle, Kai-Min Chung, and Rafael Pass, Large-scale secure computation: Multiparty computation for (parallel) RAM programs, CRYPTO, 2015.

33

[BGL+ 15] Nir Bitansky, Sanjam Garg, Huijia Lin, Rafael Pass, and Sidharth Telang, Succinct randomized encodings and their applications, Proceedings of the Forty-Seventh Annual ACM on Symposium on Theory of Computing, STOC 2015, 2015, pp. 439–448. [CCC+ 15] Yu-Chi Chen, Sherman S. M. Chow, Kai-Min Chung, Russell W. F. Lai, Wei-Kai Lin, and Hong-Sheng Zhou, Computation-trace indistinguishability obfuscation and its applications, Cryptology ePrint Archive, Report 2015/406, 2015. [CHJV15] Ran Canetti, Justin Holmgren, Abhishek Jain, and Vinod Vaikuntanathan, Succinct garbling and indistinguishability obfuscation for RAM programs, Proceedings of the Forty-Seventh Annual ACM on Symposium on Theory of Computing, STOC 2015, 2015, pp. 429–437. [CLP14] Kai-Min Chung, Zhenming Liu, and Rafael Pass, Statistically-secure ORAM with 2 ˜ O(log n) overhead, Advances in Cryptology - ASIACRYPT 2014, 2014, pp. 62–81. [CLT15] Binyi Chen, Huijia Lin, and Stefano Tessaro, Oblivious parallel ram: Improved efficiency and generic constructions, Cryptology ePrint Archive, 2015. [CP13] Kai-Min Chung and Rafael Pass, A simple ORAM, Cryptology ePrint Archive, Report 2013/243, 2013. [DMN11] Ivan Damg˚ ard, Sigurd Meldgaard, and Jesper Buus Nielsen, Perfectly secure oblivious ram without random oracles, TCC, 2011, pp. 144–163. [FDD12] Christopher W. Fletcher, Marten van Dijk, and Srinivas Devadas, A secure processor architecture for encrypted computation on untrusted programs, Proceedings of the Seventh ACM Workshop on Scalable Trusted Computing (New York, NY, USA), STC ’12, ACM, 2012, pp. 3–8. + [GGH 13] Craig Gentry, Kenny A. Goldman, Shai Halevi, Charanjit S. Jutla, Mariana Raykova, and Daniel Wichs, Optimizing oram and using it efficiently for secure computation, Privacy Enhancing Technologies, 2013, pp. 1–18. + [GHL 14] Craig Gentry, Shai Halevi, Steve Lu, Rafail Ostrovsky, Mariana Raykova, and Daniel Wichs, Garbled RAM revisited, Advances in Cryptology - EUROCRYPT 2014, 2014, pp. 405–422. [GHRW14] Craig Gentry, Shai Halevi, Mariana Raykova, and Daniel Wichs, Outsourcing private RAM computation, Symposium on Foundations of Computer Science, FOCS 2014, Philadelphia, PA, USA, October 18-21, 2014, 2014, pp. 404–413. + [GKK 12] S. Dov Gordon, Jonathan Katz, Vladimir Kolesnikov, Fernando Krell, Tal Malkin, Mariana Raykova, and Yevgeniy Vahlis, Secure two-party computation in sublinear (amortized) time, the ACM Conference on Computer and Communications Security, CCS’12, Raleigh, NC, USA, October 16-18, 2012, 2012, pp. 513–524. + [GKP 13] Shafi Goldwasser, Yael Tauman Kalai, Raluca A. Popa, Vinod Vaikuntanathan, and Nickolai Zeldovich, How to run turing machines on encrypted data, CRYPTO (2), 2013, pp. 536–553. [GLO15] Sanjam Garg, Steve Lu, and Rafail Ostrovsky, Black-box garbled RAM, Electronic Colloquium on Computational Complexity (ECCC) 22 (2015), 56. [GLOS15] Sanjam Garg, Steve Lu, Rafail Ostrovsky, and Alessandra Scafuro, Garbled RAM from one-way functions, Proceedings of the Forty-Seventh Annual ACM on Symposium on Theory of Computing, STOC 2015, 2015, pp. 449–458. 34

[GM11]

Michael T. Goodrich and Michael Mitzenmacher, Privacy-preserving access of outsourced data via oblivious RAM simulation, Automata, Languages and Programming 38th International Colloquium, ICALP, 2011, pp. 576–587.

[GMOT11] Michael T. Goodrich, Michael Mitzenmacher, Olga Ohrimenko, and Roberto Tamassia, Oblivious ram simulation with efficient worst-case access overhead, CCSW, 2011, pp. 95–100. [GMW87] Oded Goldreich, Silvio Micali, and Avi Wigderson, How to play any mental game or a completeness theorem for protocols with honest majority, STOC, 1987, pp. 218–229. [GO96]

Oded Goldreich and Rafail Ostrovsky, Software protection and simulation on oblivious RAMs, J. ACM 43 (1996), no. 3, 431–473.

[Gol87]

Oded Goldreich, Towards a theory of software protection and simulation by oblivious RAMs, STOC, 1987, pp. 182–194.

[KLO12]

Eyal Kushilevitz, Steve Lu, and Rafail Ostrovsky, On the (in)security of hash-based oblivious ram and a new balancing scheme, SODA, 2012, pp. 143–156.

[KLW15]

Venkata Koppula, Allison Bishop Lewko, and Brent Waters, Indistinguishability obfuscation for turing machines with unbounded memory, Proceedings of the Forty-Seventh Annual ACM on Symposium on Theory of Computing, STOC 2015, Portland, OR, USA, June 14-17, 2015, 2015, pp. 419–428.

[LO13a]

Steve Lu and Rafail Ostrovsky, Distributed oblivious ram for secure two-party computation, TCC, 2013, pp. 377–396.

[LO13b]

, How to garble RAM programs, Advances in Cryptology - EUROCRYPT 2013, 2013, pp. 719–734.

[LPM+ 13] Jacob R. Lorch, Bryan Parno, James W. Mickens, Mariana Raykova, and Joshua Schiffman, Shroud: ensuring private access to large-scale data in the data center., FAST, 2013, pp. 199–214. [NWI+ 15] Kartik Nayak, Xiao Shaun Wang, Stratis Ioannidis, Udi Weinsberg, Nina Taft, and Elaine Shi, GraphSC: Parallel secure computation made easy, IEEE Symposium on Security and Privacy (S&P), 2015. [OS97]

Rafail Ostrovsky and Victor Shoup, Private information storage (extended abstract), STOC, 1997, pp. 294–303.

[PF79]

Nicholas Pippenger and Michael J. Fischer, Relations among complexity measures, J. ACM 26 (1979), no. 2, 361–381.

[RFK+ 14] Ling Ren, Christopher W. Fletcher, Albert Kwon, Emil Stefanov, Elaine Shi, Marten van Dijk, and Srinivas Devadas, Ring ORAM: closing the gap between small and large client storage oblivious RAM, IACR Cryptology ePrint Archive 2014 (2014), 997. [SCSL11]

Elaine Shi, T.-H. Hubert Chan, Emil Stefanov, and Mingfei Li, Oblivious RAM with O(log 3 N ) worst-case cost, ASIACRYPT, 2011, pp. 197–214.

[SS13]

Emil Stefanov and Elaine Shi, ObliviStore: High performance oblivious cloud storage, IEEE Symposium on Security and Privacy, 2013, pp. 253–267.

[SvDS+ 13] Emil Stefanov, Marten van Dijk, Elaine Shi, Christopher W. Fletcher, Ling Ren, Xiangyao Yu, and Srinivas Devadas, Path ORAM: an extremely simple oblivious RAM 35

protocol, ACM Conference on Computer and Communications Security, 2013, pp. 299– 310. [WCS14]

Xiao Shaun Wang, T.-H. Hubert Chan, and Elaine Shi, Circuit ORAM: on tightness of the goldreich-ostrovsky lower bound, IACR Cryptology ePrint Archive 2014 (2014), 672.

[WHC+ 14] Xiao Shaun Wang, Yan Huang, T.-H. Hubert Chan, Abhi Shelat, and Elaine Shi, SCORAM: oblivious RAM for secure computation, Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, 2014, pp. 191–202. [WST12]

Peter Williams, Radu Sion, and Alin Tomescu, PrivateFS: A parallel oblivious file system, Proceedings of the 2012 ACM Conference on Computer and Communications Security (New York, NY, USA), CCS ’12, ACM, 2012, pp. 977–988.

[Yao82]

Andrew Chi-Chih Yao, Protocols for secure computations (extended abstract), 23rd Annual Symposium on Foundations of Computer Science (FOCS), 1982, pp. 160–164.

36

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & Close