 Hi everyone, I'm Wei Kai and I'm going to talk about our improved lower bound for Oblivious RAM. This is a joint work with Elon Komagatsuki from the Hebrew University. So the problem of Oblivious RAM or O-RAM considers the scenario of outsourcing storage. We have a client, it has only a very small storage. So we outsource a huge data array to a cloud server. The data is accessed piece by piece. In case the server is compromised or corrupted by an adversary, we encrypt all the data on the server. However, encryption is not enough because the adversary can still see the location of the accessed data. If these locations depend on the data contents, then just looking at these locations, the adversary can infer very sensitive information about our data. To defend such an adversary, Goldwright and Ostrovsky formalized this problem using the standard random access machine model. Of course, at their time, the cloud storage was not as popular as today. So the correctness of O-RAM is exactly the same as a standard array. We can update or query an array entry using the index of this entry. And just like the standard array, a query has to be answered before the next operation either update or query comes in. So it's totally the same as the standard array. Now the array is just an abstraction. The processor or the client has no space to really store the content of this array. So this array must be stored on the memory or the server side. Historically, we say the memory is an array of memory cells and read or write a memory cell is called to probe the memory cell. This terminology also distinguishes the physical memory array from the abstract data structure array. So that's the correctness of O-RAM, just an array. For security, we consider an adversary that can see all the memory probes, that is the locations of probe the memory cells. For security, we hope the adversary doesn't learn anything from the probe the locations. And especially we don't want the adversary to learn our top secret. Our operations performed on the abstract array. To do so, we require or recall an O-RAM is secure if for any array operation on the top, the produced memory probes are computationally indistinguishable to the adversary or even stronger identically distributed. The identical distribution is a stronger notion of security but in this talk, we are considering the lower bound side. So stronger security makes it easier to think about later in this talk. So that's the security and the correctness. Come back to the data outsourcing scenario. We have a client, we want to run some program that is written in 64 bits. So our O-RAM wants to simulate an array of n entries. Each entry has 64 bits for the 64 bit program. But the server speaks in network packets, each network packets may be a million bits so we have the memory cell a million bits in size. Or alternatively, the adversary can be even dropping a hard drive where the black size in this hard drive is 1 megabits. This introduces to extra parameters the entry size B and the cell size W. In some scenarios, the cell size is equal to the entry size but in the scenario here the cell size can be a million times greater than an entry. With the parameters M, B and W, we define the efficiency of O-RAM as the following. That's the cost per operation. The cost is measured in the number of memory pools. This is the standard definition for standard efficiency for data structure problems. We want to know the per operation cost and the cost is measured in the number of memory accesses. In the literature of O-RAM, this efficiency is so-called the overhead but in our scenario we consider the cell size can be different from the entry size so we feel IO efficiency is more appropriate and avoids confusion. I also want to stress that we care less about the number of bits processed but of course the number of bits can be translated from number of probes by just multiplying a vector W. With the model of O-RAM, there's a long list of upper bound constructions. In one extreme, when the cell size equals to an entry size, we have a recent construction upto Rama that achieves log N in efficiency. That's optimal. On the other extreme, when the cell size is square root, we have the famous square root O-RAM proposed by Gorak and Ostrowski. I want to note that when the cell size increases, the same construction can still achieve the same IO efficiency so the IO efficiency can only be decreasing with respect to the cell size and the lower bound by Larsen and Nielsen is consistent with this intuition. The lower bound says that the efficiency increases with respect to cell size or inverse of cell size. So the main question in this work and in this talk is whether we can achieve better efficiency when the cell size W is greater. On the upper bound side, we now have better techniques from recent works, also many classic algorithms like sorting can actually do better when the cell size is larger. On the lower bound side, this lower bound suggests that if the cell size W is a million times greater, we could probably enhance the performance by a million times. That would be amazing. Or speaking asymptotically, if we could improve or increase the cell size by a logarithmic factor, this suggests that we could improve the IO efficiency from log N to a constant. That is also a huge improvement. So there's no impossibility so far but like our title suggested, we improved the lower bound side and our lower bound says that the efficiency can only be increased with respect by a log factor in cell size. That means if we increase the cell size by a logarithmic factor or polylogithmic factor, the efficiency will only improve by roughly a log-log factor. Or speaking in the example, if we increase, if we have a cell size a million times greater than an entry, then the speed up can only be something like 10 to 20 at most. Moreover our lower bound matches the upper bound in the other extreme when the cell size is very large, like greater than any N to the epsilon. So our lower bound leaves a very narrow range in parameters that is still open in upper and lower bounds. Next I will dive into our lower bound proof. I will first use the correctness of OREM, that's an array to prove a technical lemma. And then I will use the security of OREM to improve our technical lemma to our lower bound. Our starting point is the previous work by Larsen and Nielsen. They proposed a hard sequence consisting of an update phase that stores a long list of random values into the abstract array. And then there is a second phase, the query phase that restores these random values back from the abstract array using queries. Because these random values is a very long random string of bits, so the OREM has no way to store these random bits in the processor side or the client side, this long random string has to be stored on the memory cells. And similarly in the query phase, in order to answer the queries correctly, the OREM has to read memory cells to answer the queries. So there is an imaginary war between the update phase and the query phase. Any information from the update phase has to go through the memory cells to get to the other side of the war, the queries. More precisely, every random bit in this random string has to be stored in the intersection of the blue and the brown sets to see why consider some random bits that is stored in the blue set or some information about the random string that is stored in the blue set but not stored in the intersection. Then that means when the query comes in, the change in the random bit cannot be reflected in the outcome of these queries. And then the OREM cannot be correct. So if this intersection has to store the whole long random string, then this intersection has to be large enough, the longer random string consists of n times b bits, so this intersection is at least n times b divided by sales size w, number of cells divided by the number of queries. Then we have a lower bound for the cost per query, that's b over w. However, we argue that this b over w is too good to be true. Why? Because when the sales size w is extremely large, it seemed like we could have a construction that answers a query without even reading one single memory cell. That just doesn't happen in upper bound constructions. But this can happen for this specific query because this query sequence is sequential 1, 2, 3, 4, 5, so there could be a construction that prepare all the future hundreds of queries in advance. To address this, our key ideas throughout this work is to use an even harder sequence of operations. We use the same sequence, same update sequence as before, but now we query random entries in the whole array. That means for every query, we pick a uniformly random entry in the whole array and query this entry. Like before, there is still an imaginary wall between the two faces. Before the wall in the update face, the ORM has to somehow write down the long random stream in this blue set of cells and then later in the query face, the ORM has to read memory cells in order to correctly answer the queries. And we hope that the intersection between the blue and the brown set is still large enough even we change the sequence of operations. To do so, let me take a closer look. In the update face, the ORM has to write down this long random stream to prepare for any random query so the blue set is roughly large enough to store the whole random stream. And now in the query face, I want to prove that every random query will make the ORM to read or prove a distinct memory cell in this blue set. I claim this indeed holds with high probability and this is actually intuitive. To see why recall that in the update face, ORM has already written down the long random stream in this blue cells. In this blue set, the ORM may use any arbitrary maybe crazy encoding to write down this long random stream. For example, the ORM may use locally decodable code. But anyway, this long random string is fixed, written in this blue set. Now a random query comes in. In order to answer this query correctly, the ORM has to read a corresponding memory cell. Not any other cell, but the specific memory cell that can answer the given query. And we have a sequence of random queries. This enforces ORM to perform reads or probes on random memory cells in this blue set. That way, every random query will enforce the ORM to probe or read a memory cell in this blue set. Until almost all the cells in the blue set are probed or touched by the ORM. And this is exactly why we use a shorter sequence of queries. Because we want to probe or hit almost a lot of cells in the blue set using a small number of queries. Putting it together, we can prove that with high probability, the intersection between the two faces is still roughly the same in size in the number of cells. But now we use a shorter query sequence. So now the query cost is almost one probe or one IO with high probability. This is our main technical lemma. It's very simple. It's very intuitive. But it is also very hard to prove because we don't assume any restriction on the ORM construction. I will briefly show the challenge in the proof later in almost in the end of this talk. So now we have our technical lemma. We use only the correctness of ORM. I will boost or enhance the technical lemma to a stronger lower bound using the security. So in the security model, we have an adversary. The adversary sees all the memory probes. It doesn't see the abstract operations performed on the array. So the adversary doesn't really know we are performing a hard sequence or not. However, our technical lemma says that if we perform a hard sequence, then there is a sufficiently large intersection in the probes. The adversary observes the probes can calculate this intersection easily. So if we switch the sequence of operation to any second sequence, the second sequence must have the same set of intersections. Otherwise, the adversary can distinguish between the first and the second and that would violate the security. And we intentionally choose the second sequence to be another hard sequence that is padded with some more operation and shifted the wall a little bit. This way, the second sequence will also imply another sufficiently large intersection by our technical lemma. And this second intersection is defined with respect to a different range of operations. So these two intersections both add to the total cost of ORM and we can switch to a third sequence of operation and so on to add more cost to the ORM. This slightly improves the lower bound and we are not stopping here. In addition to move the wall, we can scale down the hard sequence. That's a shorter sequence of updates and even shorter number of queries. This shorter hard sequence we will give another intersection at some more cost and we can still move the wall and so on to add some more cost to the ORM and we can keep doing so. We can even further scale down the hard sequence recursively that will make a complete tree. The tree degree is proportional to sales size W and every tree node will have a corresponding hard sequence. We say corresponding sufficiently large intersection and so that will add an extra cost to the ORM. The remaining is just a calculation. We have a lower bound for N query or update operations and the lower bound is proportional to the tree height. That is log N base W over B and this is exactly the lower bound I clamped earlier in our main result. So at a higher level, our move consists of three steps. The first step we use random queries, the second step we prove our technical lemma and in the third step we enhance the technical lemma to our main result, the lower bound. I want to stress that our lower bound is very strong. It is unconditional in terms of no restriction on the ORM construction and it is computational and the ORM can use any arbitrary computational assumption because our adversary is extremely efficient. It just needs to calculate the intersections. I promised earlier that I will show our main challenge in the technical lemma. We prove it by a contradiction. Suppose the lemma doesn't hold, then we have a too-good-to-be-true super-efficient ORM. Then that means we can construct our strategies to use this ORM to construct an impossible compression that can compress down a random string. If we can do so, then that is already a contradiction because random strings cannot be compressed. The compression is based on the result of Patrasco and Domain and the main challenge is in the analysis of this compression or more specifically the main challenge is to bound a specific involved conditional probability. We spend a lot of effort to reduce and simplify this conditional probability and the simplified version is the following. It is very simple and clean. I'm not going to elaborate on this probability problem, but I believe it is an interesting practice problem in, for example, probability course. I hope this inequality in conditional probability will be useful in your future research, hopefully useful for my own future research. I'm wrapping up here. We improved our lower bound and our technique extends to other settings. For example, multi-server ORM, there are still open problems. For example, the lower bound or upper bound for weaker or stronger notions of ORM. I also want to advertise for our new related results. For example, we constructed an optimal ORM that runs in worst case time. It is also published in the crypto conference this year. Thank you for your attention. If you find this result interesting, please read our flow paper or send us an email. Bye.