Oblivious RAM Simulation with Efficient Worst-Case Access Overhead

Obli vious RAM Simulation with Ef ﬁcient W orst-Case Access Ov erhead Michael T . Goodrich Uni v . California, Irvine goodrich@ics.uci.edu Michael Mitzenmacher Harv ard Univ ersity michaelm@eecs.harvard.edu Olga Ohrimenko Bro wn Univ ersity olya@cs .brown.edu Roberto T amassia Bro wn Univ ersity r t@cs.bro wn.edu October 17, 2018 Abstract Oblivious RAM simulation is a method for achie ving conﬁdentiality and pri v acy in cloud computing en vironments. It in volv es obscuring the access patterns to a remote storage so that the manager of that storage cannot infer information about its contents. Existing solutions typically in volve small amortized ov erheads for achieving this goal, but ne vertheless inv olve potentially huge variations in access times, depending on when they occur . In this paper, we show ho w to de-amortize oblivious RAM simulations, so that each access takes a worst-case bounded amount of time. 1 Intr oduction In the cloud storage model, a user , Alice, remotely stores a large set of data with a remote serv er , Bob, of ﬂoading her need to maintain her data. T o achie ve conﬁdentiality from Bob, Alice should store her data in encrypted form, but encryption alone is not enough, since information about her data may be leaked by the pattern in which she accesses it. Obli vious RAM simulation tackles this priv acy-protection problem by hiding data access patterns from Bob . Such solutions simulate a general random access machine (RAM) computation with respect to the external storage, but they perform additional obfuscating accesses that hide the locations of requests. Re- cently there has been a considerable amount of work on methods that optimize the access overhead , i.e., the number of additional accesses to the data repository per request to provide oblivious access (e.g., see [7, 6, 1, 12, 10, 2, 14, 5]). Nev ertheless, existing obli vious RAM solutions still suf fer from a worst-case access overhead that can be as bad as Ω( n ) for n data items. This worst-case overhead makes obli vious RAM unsuitable in many practical scenarios, such as real-time systems and multi-user systems. For example, consider a multi-user environment where a group of users share the same external storage: one of the users has to make Ω( n ) accesses in the worst case to make sure all accesses remain obli vious. And she may hav e to spend this much time with each of her accesses. Thus, we are interested in this paper of de-amortized solutions that hav e the same access ov erhead for ev ery request. 1.1 The Oblivious RAM Model An oblivious RAM ( ORAM ) is an interface between a client, Alice, and a data repository , Bob, whereby Alice outsources the storage of n data items to Bob. When Alice makes a r equest for item x , she issues a sequence of accesses to Bob’ s data repository to retrie ve x in such a way that Bob is unable to determine which item is being accessed (any better than a random guess). Of course, there is a simple way for Alice to obfuscate her requests—she could simply read all items from the data repository with each request (her 1 T able 1: Comparison of Oblivious RAM simulation Methods. Client Memory Server Storage Overhead Amortized Access Overhead W orst-Case Access Overhead Goldreich-Ostrovsk y [5] √ n O (1) O ( n ) O ( √ n log 2 n ) O ( n log 2 n ) Goldreich-Ostrovsk y [5] log n O (1) O ( n log n ) O (log 3 n ) O ( n log 2 n ) W illiams et al. [14] O ( √ n ) O ( n log n ) O (log 2 n ) O ( n log n ) Goodrich-Mitzenmacher [6] (1) O (1) O ( n ) O (log 2 n ) O ( n ) Kushile vitz et al. [10] O (1) O ( n ) O (log 2 n/ log log n ) O ( n ) Stefanov et al. [12] O ( √ n ) O ( n ) O (log 2 n ) O ( √ n ) Goodrich-Mitzenmacher [6] (2) O ( n ν ) O ( n ) O (log n ) O ( n ) Goodrich et al. [7] O ( n ν ) O ( n ) O (log n ) O ( n ) Boneh et al. [1] O ( √ n log n ) O ( n ) O (1) O ( n log n ) De-amortized log n O ( n τ ) O ( n ) O (log n ) O (log n ) De-amortized √ n O (1) O ( n ) O ( √ n log 2 n ) O ( √ n log 2 n ) requested item x is sure to be in this collection). But such a solution has access ov erhead Θ( n ) ; hence is quite inef ﬁcient. 1.2 Related Prior W ork Prior work on obli vious RAM addresses the trade-of f between the size of the client’ s memory , the access ov erhead, and the space overhead at the data repository , i.e., the additional space used beyond the n items. Based on the assumptions about the client, oblivious RAM models can be split into stateless and stateful solutions. A stateless obli vious RAM is not allo wed to k eep a state between requests and hence can be used in a multi-user scenario. Stateful solutions assume Alice keeps information in a priv ate storage (which she maintains), which helps her perform her accesses obli viously in the remote storage. Stateless oblivious RAM simulation was ﬁrst proposed by Goldreich and Ostrovsk y in [5], who present a preliminary simple solution with O ( √ n log 2 n ) amortized access ov erhead, referred as the squar e-r oot solution , and a more complex solution with O (log 3 n ) amortized access overhead. Goodrich and Mitzen- macher [6] improv e this result by giving a method with O (log 2 n ) amortized access overhead with high probability . Recently Kushilevitz et al. [10] sho w that techniques from [6] can be e xtended to obtain O (log 2 n/ log log n ) amortized access ov erhead. All the above methods are stateless and consider a priv ate memory of size O (1) for Alice, an overly restricti ve assumption in practice. Other solutions [7, 13, 14] improv e the ov erall access overhead by assuming that a client has a w orkspace of non-constant size. W illiams and Sion [13] achiev e O (log 2 n ) expected amortized access overhead and O ( n log n ) space o verhead with O ( √ n ) priv ate memory . W illiams et al. [14] improve the method from [13] to achiev e O (log n log log n ) amortized access o verhead. Goodrich et al. [7] gi ve an obli vious RAM simulation method with O (log n ) amortized access overhead gi ven that a client has access to workspace of size O ( n ν ) , for a gi ven constant ν > 0 . Other recent papers provide stateful solutions, i.e., where a client maintains a state between requests to the data repository in a non-constant sized priv ate cache. A RAM simulation by Goodrich and Mitzen- macher [6] achie ves an ov erhead of O (log n ) and uses a priv ate cache of size O ( n ν ) , for any giv en ﬁxed constant ν > 0 , which maintains a state. Boneh et al. [1] propose a scheme that achie ves an amortized ov erhead of O (1) b ut using a cache of size O ( √ n log n ) , which also maintains state. Damg ˚ ard et al. [2] and Goodrich et al. [7] present stateless oblivious RAM simulations without crypto- graphic assumptions about the existence of random hash functions. Damg ˚ ard et al. [2] show that amortized access ov erhead of O (log 3 n ) is possible for oblivious RAM simulation without using random functions. 2 Goodrich et al. [7] present a method with O (log 2 n ) amortized access ov erhead that also does not use random functions. T o sum up, then, all the methods described abov e ha ve amortized access ov erheads. (See T able 1 for the comparison of ORAM simulations.) Indeed, e ven the most ef ﬁcient previous solutions can incur an O ( n ) ov erhead in the worst case for any gi ven request. This is slightly improv ed in recent work by Stefano v et al. [12], who gi ve an obli vious RAM simulation that achie ves an O ( √ n ) access overhead in the worst case, while having O (log 2 n ) amortized overhead complexity; hence, their solution is also amortized, b ut not as inef ﬁcient as previous schemes on a per -access basis. Obli vious RAM simulation has also been used to protect against traf ﬁc analysis in a networked ﬁle system [15]. K osaraju and Pop [9] give an o vervie w of general de-amortization techniques. E.g., one of the tech- niques, de-amortization via data duplication [3], maintains two copies of the data set: one for performing the redistrib ution of the data and one for accesses. W e cannot apply these general techniques to our problem, ho wev er , since we also need to ensure the obliviousness of the de-amortized algorithm. 1.3 Our Results W e present tw o obli vious RAM simulations that achie ve a sublinear access ov erhead on e very request made by the client to the data repository . The ﬁrst is a de-amortized version of the square root solution originally presented in [5]. This method has O ( √ n log 2 n ) access o verhead in the worst case while using O ( n ) space on the data repository and assuming O (1) workspace on the client side. W e then de-amortize an ef ﬁcient obli vious RAM simulation by Goodrich et al. [7], that we refer to as the “ log n hierarchical” solution. In this solution, we achieve wost-case access overhead of O (log n ) and space overhead of O ( n ) , assuming that a client has access to a workspace of size O ( n τ ) , for any gi ven ﬁx ed constant τ > 0 . 2 Pr eliminaries W e assume that the client outsources n data items to a remote data repository that supports the following access operations : • r e ad ( i ) : return the content of location i ; • write ( i , x ) : write data item x to location i ; • c opy ( i, j, c ount ) : copy a memory block of size c ount from location i to location j . The latter block-copy operation is not actually required by our methods b ut using it makes the algorithms more intuiti ve. W e also assume that pro vider of the storage service, Bob, is an honest-b ut-curious adversary [4], in that he correctly performs all operations and does not tamper with the data. A data item is stored by Alice in the repository as the encryption of a pair ( x, v ) , where x is the virtual address of the item in the RAM and v is its v alue. T ypically , obli vious RAM solutions use pr obabilistic encryption to make sure that Bob cannot distinguish between reads and writes or track repeated accesses to the same data item. Namely , Alice encrypts each data item that she writes to the data repository using a probabilistic encryption scheme based on her priv ate ke y . Also, Alice reencrypts and re writes each data item she accesses so that its encryption will change even if the data item is not modiﬁed. This technique ensures that Bob is computationally unable to determine the plaintext of an y memory cell from that cell’ s contents alone. Also, it is unfeasible for Bob to determine whether two memory cells store encryptions of the same data item. 3 T B dummy items (a) Memory to handle requests B cur B prev T next W Workspace to handle rebuilds dummy items T cur (b) Figure 1: Memory layout of the data repository during obli vious RAM simulation: (a) original version of the square-root solution [5]; (b) our de-amortized version (Section 3.1). 2.1 Square-Root Solution W e ﬁrst gi ve an ov erview of the square-root oblivious RAM simulation method [5], which has O ( √ n log 2 n ) amortized access ov erhead. W e giv e enough details about the method for a reader to understand our de- amortized version pro vided in Section 3.1. Please refer to [5] for the full description. The square-root solution uses storage space of size n + 2 √ n at the data repository . (See Figure 1(a).) This space is split into a b uffer , B , and a table, T . The buf fer B has size √ n and is used to cache the last √ n requests. T able T contains a pseudo-random permutation of the n data items and √ n dummy items. Each data item is associated with a key (virtual RAM address) x , x = 1 , · · · , n and each dummy item is giv en a key n + d where d = 1 , · · · , √ n . All items in T are ordered according to a pseudo-random permutation function π such that π ( x ) giv es the location of the item with ke y x in T . (The full solution, which uses a binary search, is omitted in our description since the overall complexity of the request is O ( √ n ) .) The square-root ORAM simulation method is outlined in Algorithm 1. Note that table T has to be rebuilt after ev ery √ n requests. The reb uild phase consists of obli viously replacing the items in T for which there is a ne w instance in B , associating the k eys of real and dummy items with tags from a new permutation Algorithm 1 Oblivious RAM simulation using the square-root approach [5]. Generate pseudo-random permutation function π Initialize table T by storing the n data items and √ n dummy items according to permutation π count ← 1 while true do { process a request } found ← f al se Scan all the locations in buf fer B . During the scan, if data item x is found, set found ← true . if found then Access location π ( n + count ) in T { a dummy item } else Access location π ( x ) in T { data item x } end if Re write B , adding or replacing data item x count ← count + 1 if count > √ n then Generate pseudo-random permutation function π 0 Construct a ne w table T 0 with π 0 using items in T and B . clear B and set T ← T 0 , π ← π 0 , and count ← 1 end if end while 4 π 0 , and sorting items in T according to π 0 . The rebuild phase takes O ( n log 2 n ) accesses. Since the rebuild happens only once ev ery √ n requests, the amortized access overhead per request is O ( √ n log 2 n ) : O ( √ n ) accesses for the request phase and O ( √ n log 2 n ) accesses for the reb uild phase. Obliviousness: Requests are handled by scanning buf fer B and accessing T . Due to the scheduled rebuilds, data items are associated with ne w tags e very √ n requests. Between the reb uilds, unique locations are accessed in T : either an item x is not present in the b uf fer and hence a unique location, π ( x ) , is accessed, or a unique dummy item, π ( n + count ) , is accessed. 2.2 log n Hierarchical Solution W e now describe the efﬁcient obli vious RAM simulation by Goodrich et al. [7]. This method has O (log n ) amortized access ov erhead, O ( n ) space ov erhead at the repository , and client memory of size O ( n ν ) , where ν is an arbitrary positiv e constant. This method is stateless and thus suitable for a multi-user scenario since no client keeps a state between requests. 2.2.1 Cuckoo Hash T able Since the method of [7] uses cuckoo hash tables , we gi ve a short description of a cuckoo hash table. (See [11] for more details.). A cuck oo hash table for n items consists of two hash tables, T 1 and T 2 with two hash functions, h 1 and h 2 . Each hash table contains m = (1 +  ) n memory cells, with  a (small) positiv e constant. An item with ke y x is found either in location h 1 ( x ) in T 1 or in h 2 ( x ) in T 2 . W e say that a failure occurs when there are only two possible locations for three ke ys x , y , z , i.e. h 1 ( x ) = h 1 ( y ) = h 1 ( z ) and h 2 ( x ) = h 2 ( y ) = h 2 ( z ) . In this case a stash, S , of constant size is used to k eep items that did not ﬁnd a place in tables T 1 and T 2 . The retrie val of an item no w includes a scan of S , which takes O (1) time. Kirsch et al. [8] show that a cuckoo hash table with a stash of size s o verﬂo ws with probability O (1 /n s +2 ) . Recently Goodrich and Mitzenmacher [6] showed that one can construct a cuckoo hash table of size n with a stash of size s obli viously using O ( n + s ) accesses to the data repository and assuming access to pri vate workspace of size O ( n ν ) . 2.2.2 Oblivious Simulation W e are now ready to describe the oblivious RAM simulation by Goodrich et. al. [7]. The memory at the data repository consists of a cache C for q data items, cuckoo hash tables T 1 , · · · , T L and a stash S . (See Figure 2(a).) The size of the cache, q , is O (log n ) and stash S has also size O (log n ) . Each table T i has size 2 i q and L is the ﬁrst integer i such that | T L | ≥ n , hence L is O (log n ) . Each cuckoo hash table T i is initialized with two hash functions, h i 1 and h i 2 . Stash S is shared between all L tables and is large enough to av oid ov erﬂows in tables T 1 , T 2 , · · · , T L with high probability [7]. On a request for item x , the client ex ecutes Algorithm 2. After q requests cache C becomes full and we obli viously mov e elements from C to T 1 . The mov e consists of creating a new cuckoo hash table T 1 from the elements in C . The ne xt time C becomes full, instead of moving C to T 1 , we mo ve the items from C and T 1 to T 2 . Similarly , when we are about to move items to T i for the second time, instead we move all items from C , T 1 , . . . T i − 1 to the ﬁrst empty table among T i through T L . Oblivious construction of cuckoo hash table T i takes O ( | T i | ) accesses to the data repository . Since table T i is rebuilt ev ery O ( | T i | ) requests and e ventually e very request causes O (log n ) tables to be rebuilt, the amortized overhead is O (log n ) accesses per request. Obliviousness: Scans and writes to cache C and stash S are oblivious since it is done sequentially . T able T i is accessed either according to a pseudo-random hash function or in random locations because item x is found in an earlier lev el of the construction. Cache C and tables T j , j < i are empty when T i 5 Algorithm 2 The request phase during oblivious RAM simulation with the log n hierarchical approach [7]. f ound ← f alse scan cache C and stash S . if x is found in one of them set f ound ← tr ue f or each le vel i , 1 ≤ i ≤ L do if f ound is tr ue access random locations in T i . else access locations h i 1 ( x ) and h i 2 ( x ) in T i . if x is found set f ound ← true end f or Remov e x from S if x was found in S . Rewrite S . Re write C , adding or replacing data item x . is reb uilt and hence are used to cache items found in T i . Since T i is emptied and initialized with two new pseudo-random hash functions as soon as le vels abo ve it become full, it is never accessed twice for the same item. Hence, from the point of view of the adv ersary , Bob, accesses to T i look random. 3 De-amortized ORAM Simulation 3.1 The Square Root Solution In this section, we present an obli vious RAM simulation method with O ( √ n log 2 n ) access ov erhead in the worst case. This method is based on the square-root approach originally proposed in [5], which has O ( n log 2 n ) worst-case access overhead and O ( √ n log 2 n ) amortized access o verhead (see Section 2.1). W e present ﬁrst the simple square-root solution, to demonstrate some of the ideas behind the more efﬁcient technique dev eloped in Section 3.2. Note that only recently an oblivious RAM solution with sublinear worst-case access o verhead has been proposed [12]. Intuition: The most expensiv e step of the square-root approach is building a new table, where items and dummy v alues are ordered using a ne w pseudo-random permutation. This step is ex ecuted e very √ n requests and takes O ( n log 2 n ) accesses. Our idea is to split the accesses for the rebuild into √ n batches, each with O ( √ n log 2 n ) accesses, and to ex ecute each batch after processing a request so that the ne w table is ready to be used after processing √ n requests. W e will show how this idea can be implemented while preserving obli viousness and keeping the same asymptotic access ov erhead and storage ov erhead as the original method. Memory Layout: W e organize the memory on the data repository into ﬁv e areas. W e make use of two buf fers, B cur and B prev , each of size √ n . W e also hav e two tables, T cur and T next , each of size n + √ n . These tables are built using dif ferent pseudo-random permutations on the n data items outsourced by the client and √ n dummy values. Finally , we employ a workspace W of size n + 2 √ n for constructing incrementally the new table, T next , while the current table, T cur , and the two b uffers, B cur and B prev , are being used to process requests. (See Figure 1(b) for illustration.) Initialization: W e split a sequence of requests into epochs , where an epoch consists of exactly √ n requests. Initially , buf fers B cur and B prev are empty and each of the tables T cur and T next contains the n items and √ n dummy items permuted according to a pseudo-random permutation, where T cur uses permutation π 0 and T next uses permutation π 1 . Processing an Epoch: During an epoch, b uffer B cur caches the √ n items being requested in the current epoch while b uffer B prev caches the √ n items that were requested in the previous epoch. Thus, B prev is empty during the ﬁrst epoch. Also, during an epoch, table T cur is used for processing requests and workspace W is used to build incrementally a ne w table, based on a new pseudo-random permutation. 6 Algorithm 3 Oblivious RAM simulation with our de-amortized v ersion of the square-root approach. Generate pseudo-random permutation function π cur Initialize table T cur by storing the n data items and √ n dummy items according to permutation π cur Initialize W with n data items and √ n dummy items while true do { process the requests in an epoch } Generate pseudo-random permutation function π next r e quest c ount ← 1 while true do { process request for data item x } found ← f al se Scan all the locations in buf fers B cur and B prev . During the scan, if data item x is found, set found ← true . if found then Access location π cur ( n + r e quest c ount ) in T cur { containing a dummy item } else Access location π cur ( x ) in T cur { containing data item x } end if Re write B cur , adding or replacing data item x Execute the next batch of c √ n log 2 n accesses to workspace W to construct table T next using permutation π next r e quest c ount ← r e quest c ount + 1 if r e quest c ount > √ n then break { end of the epoch } end if end while Copy the ne w table from W to T next Copy B cur to B prev Copy T cur and B cur to W Empty B cur Copy T next to T cur π cur ← π next end while T ransitioning to the Next Epoch: At the end of an epoch, the ne w table is copied from W to T next . Next, table T cur and buf fer B cur are copied to W . Finally , table T next is copied to T cur to accommodate the requests from the next epoch. Also, we ov erwrite B prev with items from B cur and we empty B cur . Incremental T able Construction: The construction of the new table, T next in workspace W takes as input T cur and B cur from the previous epoch. W e say that the instance of a data item in T cur is stale if there is an instance of the same data item in B cur . Using an algorithm from [5], we obli viously ﬁlter out the stale instances of the data items and we construct a table for the set consisting of the n data items and √ n dummy items, storing them according to ne wly generated pseudo-random permutation. Since this algorithm performs O ( n log 2 n ) accesses to the data repository , we de-amortize it by splitting its sequence of accesses to workspace W into √ n batches of c √ n log 2 n accesses each, for some constant c > 0 . The construction of table T next starts at the beginning of the epoch and a batch of accesses is executed after processing each request. Hence, the new table T next is ready by the end of the epoch. Our oblivious RAM simulation algorithm based on the square-root approach is outlined in Algorithm 3 and its properties are summarized in Theorem 1. 7 Theorem 1. Our oblivious RAM simulation method based on the squar e-r oot appr oach has O ( √ n log 2 n ) worst-case access overhead per r equest, O ( √ n ) space overhead at the data repository , and O (1) client memory , wher e n is the number of data items. Pr oof. ( S K E T C H ) The worst-case access o verhead of each request is O ( √ n log 2 n ) since we scan two buf fers of size √ n , access one table entry , and ex ecute O ( √ n log 2 n ) accesses to perform one batch of the table rebuild. Also, O ( n ) additional space is used at the serv er . W e no w consider the obliviousness of our method. During each epoch, unique items are accessed in table T cur . Namely , if the requested data item is not found in the buf fer , we access it in T cur , else we access a new dummy item in T cur . Moreover , in the beginning of each epoch T cur is initialized with a new permutation ov er n items and √ n dummy v alues. The method is correct since the user is always returned the most up-to-date instance of the requested item: if the requested data item was last requested in the current epoch then it is found in B cur , else if it was last requested in the pre vious epoch, it is found in B prev , else T cur has the latest instance. Read/Write Data Repository: In Algorithm 3 we made an assumption that data repository allo ws us to manage outsourced memory using copy operator . Howe ver , it is not required for e xecution of our de- amortized method and achieving the same worst case overhead of O ( √ n log 2 n ) . W e provide only an intuition behind this approach. If the data repository supports only read and write operations one can alternate blocks of memory used for reb uild and for handling requests between the epochs, e.g. during e ven numbered epochs B cur is used to cache current requests while during odd epochs it serv es as a buf fer of requests from the pre vious epoch. 3.2 The log n Hierar chical Solution W e now describe the de-amortization of the obli vious RAM simulation method presented in [7], which is based on a hierarchical memory layout at the server and has O (log n ) amortized access ov erhead. The intuition behind the de-amortized version of this method is similar to the one we used in the square-root solution (see Section 3.1): we incrementally rebuild tables while handling requests using previous versions of tables and buf fers. Requests are handled using two sets of buf fers: one for items requested in the current epoch and the other for items requested in the previous epoch. Howe ver , recall that the construction of [7] has O (log n ) buf fers implemented as cuckoo hash tables. This complicates our task since now we need to hav e a copy of each cuckoo hash table. Also due to the dynamic arrangement of the b uffers, one buf fer spills into the next one and so on, we e ventually need to construct O (log n ) cuckoo hash tables during each epoch. Memory Layout: Our memory layout at the data repository is schematically illustrated in Figure 2(b). Extending the oblivious RAM data structure of [7] (see Section 2.2), we emplo y two caches, C cur and C prev , of size q = O (log n ) , one stash, S , of size O (log n ) , and 2 L − 1 cuckoo hash tables T 1 , T 0 1 , T 2 , T 0 2 , . . . , T L − 1 , T 0 L − 1 , T L where each T i and T 0 i has size 2 i q and L is the smallest i such that 2 i q ≥ n . W e also k eep a workspace W for rebuilding cuckoo hash tables. The w orkspace stores the last 2 L q requested items in a list, D . In addition, it contains L work areas for rebuilding cuckoo tables. The i -th w ork area consists of storage space T W i , of size O (2 i q ) , for a cuckoo hash table at le v el i and of o verﬂo w space S W i , of size O (log n ) , for the corresponding stash. Initialization: W e build T L as a cuckoo hash table for the n data items and put into stash S any items that did not ﬁt. Both caches C cur and C prev and other tables T i and T 0 i (for i < L ) are empty . Processing an Epoch: In this section an epoch is deﬁned as a sequence of q requests. During an epoch, cache C cur stores data items last requested in the current epoch and cache C prev stores data items last requested in the pre vious epoch. Thus, these caches play roles similar to those of buf fers B cur and B prev in Section 3.1. Each request is processed by scanning caches C cur and C prev , scanning stash S , and accessing locations in tables T 1 , T 0 1 , T 2 , T 0 2 , . . . , T L − 1 , T 0 L − 1 , T L . In addition, a batch of accesses is made to workspace 8 ................................ T T C S 1 2 L T L (a) ................................ S ................................ Workspace for table rebuilds Memory to handle requests ................................ D C cur T w 1 T 1 L ....... T w 2 T w L S w 1 S w 2 S w L C prev T 2 T L T' 1 T' 2 T' L (b) Figure 2: Memory layout of the data repository during obli vious RAM simulation: (a) original version of the log n hierarchical solution [7]; (b) our de-amortized version (Section 3.2). W toward rebuilding its cuckoo tables. The incremental reb uilding process guarantees the completion of a cuckoo table in T W i and its stash in S W i after 2 i − 1 epochs. Incremental Construction of L Cuckoo Hash T ables: Recall that a cuckoo hash table T i of size 2 i q can be constructed obliviously using 2 i q accesses to the data repository and O ( n ν ) pri v ate memory [6]. T o help us explain the concurrent oblivious rebuild of L cuckoo hash tables, we introduce a data structure I that stores the set of indices of the cuckoo tables that need to be rebuilt in workspace W . Note that Queue depends only on the number of requests made so far hence it can be computed in constant time. I starts empty . After e very 2 i − 1 epochs index i is added to I . When an index i is added to I a sequence of 2 i bq accesses is required for a reb uild of T W i , for some constant b > 0 . After each request, the client ex ecutes 2 b accesses for each index in I so that the construction of table T W i is completed in 2 i − 1 epochs. Observe that after the ﬁrst 2 i − 1 , epochs index i is always present in I . Moreov er , after 2 L − 1 epochs indices 1 , 2 , . . . , L are present in I and I does not change from then on. This also means that ev entually all L tables are being rebuilt during an epoch. (See Figure 3 for an illustration of the rebuilding process.) T o accommodate L concurrent rebuilds, we increase the requirement on the size of client’ s priv ate memory from O ( n ν ) in [7] to O ( n τ ) , for some ﬁxed constants τ > ν and ν > 0 . T ransitioning to the Next Epoch: W e append items in C cur to D , the list in workspace W that keeps track of the 2 L q previously requested items. W e then copy C cur to C prev and empty it. Hence C cur can be used to cache requests during the next epoch. W e then check which tables are ﬁnished, i.e. T W i is ﬁnished if the current number of epochs is a multiple of 2 i − 1 since T W i takes 2 i − 1 epochs for a rebuild. Each such table T W i is then copied to either T i or T 0 i . If T i and T 0 i are both empty or both full T W i is copied to T i , stash S W i is mer ged with S and T 0 i is cleared. If only T i is full T W i is copied to T 0 i , stash S W i is mer ged with S . If T L , the table from the last level, is ﬁnished we clear ﬁrst 2 L q items from D since all these items are now in T L and no table from earlier le vels requires them for a rebuild. 9 q 2q 3q 4q 5q 6q 7q 8q Table rebuild T1 T2 T1 T1 T3 T2 T4 T1 2q 4q 2q 8q q 2q 3q 4q 5q 6q 7q 8q 9q 10q T1 T1' T1' T1 T1 T1 T1' T1' T1 T1' T1 T2 T3 T2' T2 T3' 8q Accesses from request phase Accesses from table rebuilds Accesses from request phase Accesses from rebuild of T1 Accesses from rebuild of T2 Accesses from rebuild of T3 Accesses during de-amortized version of logn hierarchical solution Parallel table rebuilds T2 T2' 4q 2q 4q 2q 2q 2q 2q q 2 q 2 q 2 q 2 q 2 q 2 Request count Request count Accesses during logn hierarchical solution 11q 12q Figure 3: Sequence of accesses during oblivious RAM simulation: (a) original version of the log n hierarchical solution [7]; (b) our de-amortized version (Section 3.2). The size of the cache is denoted by q , which is O (log n ) . Stash Size: Goodrich et al. [7] sho w that a single stash of size O (log n ) is enough to a void o verﬂo ws in cuckoo hash tables T 1 , . . . , T L where T i contains 2 i q items. In our construction, we use a single stash S for two collections of cuckoo hash tables. A single stash ensures that if item x happened to not ﬁt into tw o tables T i and T 0 j then only the most recent copy is present in S . One can vie w stash S as a joint stash between tables T 1 , . . . , T L and T 0 1 , . . . , T 0 L − 1 . Suppose a stash of size s log n is used in the construction of [7], where s > 1 is a constant. Then we set our stash S to be of size 2 s log n , where the ﬁrst s log n locations are used for tables T 1 , . . . , T L and the remaining s log n locations for T 0 1 , . . . , T 0 L − 1 , with the additional constraint that only unique items can be present in S . The latter constraint is enforced when we merge stash S W i of a ne w table T W i with S . Our oblivious RAM simulation algorithm based on the log n hierarchical approach is outlined in Algo- rithm 4 and its properties are summarized in Theorem 2. Theorem 2. Our oblivious RAM simulation method based on the log n hierar chical appr oach has O (log n ) worst-case access overhead per r equest, O ( n ) space overhead at the data repository , and O ( n τ ) client memory , wher e n is the number of data items and τ is any ﬁxed positive constant. Pr oof. ( S K E T C H ) W e ﬁrst show that handling of each request using the abov e protocol takes O (log n ) accesses. Retrie ving a data item takes O (log n ) accesses since three blocks of size O (log n ) are scanned 10 Algorithm 4 Oblivious RAM simulation with our de-amortized v ersion of the log n hierarchical approach. Initialize T L and S with a cuckoo hash table with a stash using n data items. I ← {} , r e quest c ount ← 0 while true do while true do { on request x } f ound ← f alse Scan all the locations in caches C cur and C prev and stash S . During the scan, if data item x is found, found ← true . f or each le vel i , 1 ≤ i ≤ L do if i 6 = L and T 0 i is not empty if f ound is tr ue access random locations in T 0 i . else access locations h i 0 1 ( x ) and h i 0 2 ( x ) in T 0 i . if x is found, f ound ← true . if T i is not empty if f ound is tr ue access random locations in T i . else access locations h i 1 ( x ) and h i 2 ( x ) in T i . if x is found, f ound ← true . end f or Re write C cur , adding or replacing data item x . if x is found in stash S remov e x from S . Rewrite S . f or i ∈ I Make ne xt 2 b accesses to wards a rebuild of table T W i r e quest c ount ← r e quest c ount + 1 if r e quest c ount mo d q = 0 then { end of the epoch } Copy C cur to C prev and append it to D . Empty C cur . f or i ∈ sorted decr or der ( I ) if r e quest c ount mo d 2 i − 1 q = 0 if i = L copy T W i to T L . else if T i and T 0 i are both full or both empty Empty T 0 i and copy T W i to T i . else copy T W i to T 0 i . Merge S W i and S . f or each le vel i , 1 ≤ i ≤ L if r e quest c ount mo d 2 i − 1 q = 0 Copy last 2 i − 1 q items from D to T W i if i 6∈ I I ← I ∪ { i } . if i = L empty D . end if end while end while 11 and two accesses are made to 2 L tables, where L is O (log n ) . The batch of accesses for table rebuilding made after each request consists of 2 b accesses for ev ery table in I , where I has at most L indices and b is a constant. The method clearly requires only O ( n ) space on the data repository . For every rebuild, we use the method of [6] which requires O ( n ν ) , ν > 0 , of client pri vate memory . Since our method concurrently makes O (log n ) reb uilds O ( n τ ) of pri v ate memory is required for τ > ν . W e now consider the obliviousness of the method. T able rebuilds remain oblivious since they follow a predetermined schedule that depends on n and r e quest c ount and are performed in the same way as in the original ORAM construction in [7]. It remains to sho w that each request remains obli vious. Accesses to the caches, C cur and C prev , and the stash, S , are obli vious since their memory locations are scanned (read and re written entirely) for each request. Since accesses to table T i depend on whether an item is found in T 0 i we ﬁrst sho w the obli viousness of access sequence to T 0 i . Observe that when T 0 i is substituted with a ne w cuckoo hash table T W i cache C cur and all tables T 0 j

Original Paper

Loading high-quality paper...

Related Papers

Loading...

Comments & Academic Discussion

Loading comments...

Leave a Comment

Twitter Facebook