 Hi, everyone. I'm Kevin, a researcher from Google. And today, I'm going to be presenting our new work on Blower Bounds for Multi-Server of Livia's Ramps. This is a joint work by fabulous colleagues from Ahuish University, Casper Green-Larsen, and Mark Simkin. All right, let's get started. So today, we're going to be focusing on our things called privacy-preserving storage protocols. So what does that mean? We're considering a setting where, on the left, you have a client. And on the right, you have a server that you can imagine is holding some data. So in this case, we can imagine an array of n entries to be one is the first entry, b2 is the second entry, so on and so forth. And what's going to happen is the client will receive and wants a query to retrieve the it index from the server held array. And maybe it'll do so in some privacy-preserving way, so some very fancy or complex way, such that in the end, it retrieves the if entry. But it wants to do so in such a way that whatever the server sees, so for example, the accesses that are occurring or whatever is stored in server memory, the server can't really tell what was the requested index. So what was I, in this case? And to do this, there are a variety of different techniques that can be done, but at a high level, one of the main techniques, especially in this sort of area, is the following where you can imagine the client is holding some sort of private key. And what it'll do is essentially encode the database in some way, so maybe it'll randomly shuffle, it'll encrypt the entries. In some way, that's hidden that the server will not know the ordering or where entries are stored on the server. And of course, what happens is as queries occur, these things will change over time and the blocks will be reshuffled and we encrypt it over and over again. So in particular, what we're really going to focus on is this primitive called oblivious RAM. So what is an oblivious RAM? What you can think of is taking an access pattern. What oblivious RAM does is it takes an access pattern and sort of obfuscates it in a way such that what the server sees are sort of the results of the oblivious RAM, whatever the oblivious RAM accesses or stores in memory, sort of this is what we donate by ORAM at the access pattern, it sort of hides what the original access pattern is. So what is this ORAM at the access pattern? It's essentially whatever the server sees. So this is whatever store and server memory as well as whatever accesses to the encrypted memory are done by the client. And for privacy, what an oblivious RAM essentially says is that let's say you take two sequence, two access patterns of the same length. The resulting server's view created by the ORAM will be essentially indistinguishable. So what it means is the server cannot distinguish any two access patterns of the same length. So what we're really going to focus on is the multiserver variant of this case. So what you can imagine is now there are K servers. Let's say one, maybe labeled one to K left to right. And each of them can store an encoded version of the database. But what's going to happen is that the adversary will be able to compromise exactly one server. And I want to quickly caveat the fact that sort of the user or the courier doesn't know which of the servers have been compromised. Otherwise the problem is very straightforward that you can retrieve an item from the server that's not compromised. All right, so sort of before we begin and dive into our results, I wanted to sort of outline two very simple ways of doing multiserver oblivious RAMs. So trigger the algorithm number one is sort of the following. The user has an index I and wants to retrieve the index. To do so, it'll just do a plain text query to a random server. So the query doesn't know which of the servers are compromised. So instead it's going to pick a random one and hope that the one is chosen is not compromised. So of course this has ordered one overhead. You just literally retrieve the entry. But what is the adversary's advantage? It's essentially one over K. It's just the probability of what was the courier unlucky enough to have chosen the server that was compromised by the adversary. All right, so this is trivial algorithm one. And this seems a little, it's weak. It doesn't really, it's essentially a naive sort of algorithm in terms of privacy. So let's go to the other extreme. What's another trivial algorithm for doing multiserver ORAM? Well, a very simple one, for example, would be to just use a single server ORAM query, pick one server and always do a single server ORAM query. So this will have a logarithmic overhead. Essentially the best ORAMs have been proven and single servers have been proven to have to be tied a logarithmic overhead. And the adversary's advantage now becomes much smaller than one over K. In fact, it'll be negligible in some security parameter. It's no negligible in N typically. But sort of this seems wasteful in the sense that if you think about it deeper, if you're just doing a single server ORAM query, you're assuming actually the adversary has compromised every single server and it's sort of the worst case. We're not really utilizing sort of the power of only one of the servers being compromised and K minus one of them being sort of free and sort of whatever's happening is out of the view of the adversary. So, if we were able to guarantee that we always did a plain text query to a non-compromised server, we would actually get an ORAM essentially. So single server ORAM seem to be very, they don't seem to utilize the power of multi-server setting where K minus one servers are not compromised. All right, so given these two trivial algorithms, this actually leads us to our main results which is actually a very strong lower bound. So in our paper what we essentially proved that any multi-server ORAM with K servers where the adversary compromises exactly one server, that oblivious RAM must have logarithmic overhead when distinguishing advantages at most one over four K. So what it's essentially saying is that, we have this trivial algorithm, if you want it slightly less advantage, just a factor of four less, you actually require logarithmic overhead. So what does this theorem sort of imply? The first sort of corollary is that multi-server ORAMs that require negligible advantage, or just typical privacy guarantees of an oblivious RAM, they actually require logarithmic overhead even with a polynomial number of servers. So that's actually very strong. If I had a polynomial number of servers, it still doesn't help me get a better multi-server ORAM with better overhead. And sort of the second corollary is that the two trivial algorithms are actually optimal for their regimes of distinguishing advantage. So for example, if you're okay with the situation of advantage one over K, where K is the number of servers, just use this sort of trivial algorithm where you pick a server from the random and hope that it's not compromised by the adversary. And simultaneously, if you want anything less than one over K, so it's like less than one over four K, a single server ORAM actually suffices to give you the optimal solution. And you can just ignore K minus one server, the K minus one server is other servers. All right, so sort of now for the rest of the talk, what I'm gonna go through is sort of outlining the proof of how we are able to prove this very strong theorem. So to prove, to show how I prove this lower, how we prove this lower bound, we start with start off by telling you what the model is. So what we're gonna do is we're gonna prove our lower bound in the cell probe model, which is used quite often for data structures and cryptographic data structures. So what happens again, we have the client on the left, the server on the right. And what we want to do, what we're gonna consider is a server memory is gonna be split up into something called cells. So each cell is the same size, what we're gonna call W bits. Then we'll assume that each cell is uniquely addressed by some integer. And what happens is in so we have these cells and what we're gonna do is we call a probe. So let's say for example, when we see the client probes a server cell, what essentially means either reading and or writing to that specific memory cell. And in the cell probe model, that's the only cost. So probing or reading or writing to a cell W bits is essentially the only cost in the cell probe model. Everything else is free. So computation is free, random oracles are free, random disgeneration is free, excuse me. Accessing client storage is free. And what I wanted to sort of emphasize is that by considering a very weak cost model, we actually end up with a very strong lower bound. So you can imagine any reasonable model that also charges computation, random disgeneration client storage access. Well, the lower bound will also hold in such a model. All right, so what we're gonna do is we're gonna prove our lower bound using a technique called the information transfer technique. And this was introduced by Mihail Petrosky and Eric Domain in the mid 2000s and was recently used the last couple of years by Casper Larson and Jesper Nielsen to prove lower bounds in OREM. And this was the first sort of paper that connected the cell probe model to oblivious data structures in particular oblivious RAM. So what we're gonna be doing is we're gonna be adapting the information transfer technique you used in both of these papers to prove our multiserver oblivious RAM lower bound in the cell probe model. All right, so let's just dive into the details now. So it's called the information transfer technique and it's because of the underlying sort of structure that they have sort of virtually in the memory is something called information transfer tree. So what this is is a binary tree with essentially N nodes if you're considering N operations. And what you're gonna do essentially is uniquely assign each operation to a leaf node of the tree. So for example, if there's N operations, you can imagine that they're uniquely assigned going from the first operation all the way to the entire operation from top to bottom. So what is this operation we're talking about? An operation can think of as a virtual operations. For example, reading to an entry of an oblivious RAM, writing to an entry of an oblivious RAM. And what's actually happening in these operations is that they're underlined by some sort of cell probe. So cell reads and cell writes. So for example, the first operation is sort of underlined by a sequence of cell operation. So maybe it's reading to the 15th cell on the third server, where the sort of the superscript represents the server and we see each server as you do like a five XM integer. And the argument is essentially the address of that cell on that server. So essentially these virtual or RAM operations are sort of implemented using a series of cell read and writes. So okay, so given that we know what a virtual operation is defined as, how, where does the information transfer tree come in? So what essentially we're gonna do is for each of the operations, so for example, let's say the third operation had a red cell 15th in the ith server. For each of these cell reads, what we're gonna do is we're gonna go back until we've, I mean, we're gonna go back in time. So you know, the third operation, we're gonna go back to the second operation and maybe the first operation and find the last time that the cell, the 15th cell on the ith server was written to. So for example, let's suppose it's the first operation. And what we're gonna do is we're gonna take the two nodes that are associated with each of these operations, find the lowest common ancestor and essentially assign this cell probe to that internal node. So here it's assigned to the level, to the sort of internal node two levels above. All right, so why is this interesting? You know, this seems to be very arbitrary way of assigning cell probes to internal nodes. So what the key point that ends up, that's being used throughout all these papers is the following. So let's suppose, let's look at this, this internal node is the one, the colored red. What is essentially, what essentially information transfer tree does is it characterizes the exact amount of information that we transfer from operations of the top subtree rooted at the red node to the bottom subtree rooted at the red node. And essentially what it's essentially saying is that whatever pros were assigned to this red node must be the totality of information that's being transferred from any operations that were written in the upper subtree of this root at the red node to the bottom subtree root at the red node. So at a high level, this isn't this, you know, maybe this doesn't make sense off the bat, but what you can later do is sort of try different, different nodes to see if this is not true. So for example, if you consider either the left or the top or bottom child of this red node, you'll see that the information here sort of assigned, any probes assigned here actually can transfer information to the bottom subtree because otherwise, if any cell writes that were done here were right here, they would have also been assigned to the red node. And vice versa, you can see that any probes assigned to any sort of parents of the red node, they were actually not read in the subtree rooted at the red node. Instead they were read outside of this, outside of the subtree root of the red node. So it's actually, what will eventually happen is if you think carefully, you'll actually see that the totality information transferred from the top subtree root of the red node to the bottom subtree root of the red node, all that information must be contained essentially in the probes that are assigned to this red node, as well as any information that can be stored in the client storage. But for now, let's suppose that client storage is quite small and it's not significantly large. All right, so let's say, okay. So let's say, you can take it for granted sort of what I've told you, or maybe later you go into the details of our paper and find out what I'm trying to tell you about this red node. So what I'm gonna show you next is how to maximize the assigned probes to a node, to an internal node. So what I just said before in the last slide is true. How can we maximize the number of assigned nodes to this red node, for example? Well, what we're gonna do is we're gonna try to maximally write as much information in the top subtree of the red node and then subsequently read it in the bottom subtree of the red node. As a result, if truly all the information is sort of contained in the probes that are assigned to this red node, it must be that in this case, the information is maximized because of every sort of operation in the top subtree is subsequently read in the bottom subtree. So if we're truly writing random sort of entries and then reading them afterwards, all that information must be stored in the probes that are assigned to this red node. All right, so now that we sort of have an idea of what does the assignment of probes mean and sort of what does it mean to maximize a single internal node, this leads us sort of to our lower bound. So what's gonna happen is our lower bound is actually a very trivial sequence. It's just reading zero consecutively n times. All right, so then you might ask me right now, saying this sounds, this is not hard to implement. In fact, if I wanted to read zeros, if I'm only reading a single index, I can just always retrieve that index and that'll be oblivious. So isn't this operation easy to handle? The answer is it's not. And the key idea is that the sequence must be indistinguishable from all other possible sequences of the same length. So for example, I shouldn't know if I'm reading only zeros, if I'm reading only one, if I'm reading only two, so on and so forth. So really the key idea is that even though this hard sequence is not very hard, in fact, every specific sequence might not be too difficult. It just so happens that hiding them from each other ends up being very difficult. And you can sort of take the worst parts of each sequence. So all right, that might seem very vague. So let's go right into sort of the ideas of how to do the proof. All right, let's suppose, this is a very trivial sort of, I've taken the hard sequence and I've just put them into the information transfer tree. All right, well, let's take this idea. Okay, the key idea is sort of, you need to sort of be indistinguishable from other sequences. Okay, so let's try this. I'll change every other operation to a write to zero. Well, actually, okay, if we take a look at this carefully, what we're actually doing is if each of these writes are truly writing random bits to the zero entry and subsequently reading them, what we're actually doing is maximizing the information transfer for all of these red nodes of the parents just above the leaf. Okay, so that seems interesting. So let's do this again. Can we do it for the other turn of notes? Well, again, if we sort of did write zero, write one, read zero, read one in the first four operations, this subsequently maximizes the information transfer for this red node. And of course, I can do it again sort of for the bottom subtree and get and maximize that, the other red node at the same level. You know, just to make sure everyone is clear, you can sort of do this one more time as well and sort of even maximize the route by sort of doing four writes, subsequently four writes random entries with subsequently four reads. Okay, so let's take these ideas and actually complete the lower bound. So what actually happens in a single server lower bound is this actually suffice to sort of put the lower bound. So by security, the number of probes assigned each internal node cannot differ too much from sequences that maximize the assigned codes. So for example, the reason for each node, there is some sort of sequence that maximizes the assigned probes to that node, just for correctness, just to be able to correctly return the answer. And just by security, if for example, you see that a specific node doesn't have something close to that maximum, you can sort of rule out with high probability that it was this specific hard sequence with that internal node that was executed by the challenger in the security game. And it turns out by just by summing the maximum number of probes assigned over all nodes, you get the, it provides a lower bound of N log N. So we had N operations. If you sum up the maximum number of probes assigned over all nodes, you'll end up getting N log N. All right, but the problem for the multi server case is that actually this sort of first security argument, it doesn't really go through. So let's see sort of why. So, okay, we have this information transfer tree. You know, I've just given sort of random numbers. So, you know, I'm telling you 16 probes have been assigned to the roots and you know, subsequent support first top child, seven probes were assigned and the bottom child nine probes were assigned. But if you think about it carefully, when I described the information transfer tree earlier, it was really actually the probes across all of the servers, right? So actually the 16 is the sum of all the assigned probes from across all of the paid servers potentially. So let's say we take a two server example. So what is the adversary sort of really see? It doesn't see this information transfer tree. What it really sees is, you know, depending on which of the two servers the adversary had compromised. If it, for example, compromised server one, it would see something like this, you know, where, you know, it's sort of, you know, a subset of the assigned probes in the original information transfer tree. And subsequently if the adversary had a compromised server two, you might have seen something different. And so that we can see right away that since the adversary doesn't see both the servers, it can't really sort of automatically get that each internal node must be maximized, must be close to the maximum number of assigned probes. All right, so then how do we sort of get around this? Well, the answer is sort of in the following way. So we're gonna use two facts, which actually I've already explained before in some ways. The first fact is that the sum of assigned probes in internal node over all servers views must be large. And this is for the specific hard distribution for that node. So we know there's just some hard distribution for a specific node that maximizes the number of assigned probes across all servers just for correctness, just to be able to return the correct answer. So even if you split this up across multiple servers just for correctness, I know that the sum of these assigned probes across all the servers must still be large. And the second thing is sort of just, I mean, sort of obvious, but in a sense, what we're trying to say is that each server's view cannot be significantly different for each sequence. So we know there's some maximum sequence that would with high probability take the sum over, maximize the sum across all of the servers. Well, it can't be that an individual server's view can differ significantly for any sequence, even if it's not hard for that specific node. So the best way I like to view this is sort of as a PDF. So what I'm saying is, so I was trying to say is, we can imagine this probably density function where you have the densities, and sort of, we're looking at a specific node here and that node's hard distribution, the one that should maximize the number of assigned probes summed across all the servers. So what happens here is the y-axis, sort of the density, the probability of seeing this number of probes assigned for a specific server, and then we can maybe see sort of the number of probes assigned, maybe this is the range from zero to 15. So, okay, from the first fact we know that, for example, this PDF shouldn't be zero. If I pick a random server, since I know that the sum across all servers must be large, it must be that some of the many of these servers have a non-zero, like they're not assigning, they're not always having zero probes assigned for the specific node. So it must be that this sort of PDF is sort of skewed at least to the right and that there must be a non-zero number of probes assigned, quite a bit of number of assigned probes on average across all the servers. So what we actually do is we sort of take that PDF and convert it to something that we can actually sort of use as an adversary. So what we do is we sort of group them into exponentially growing sort of, into exponentially growing groups. So for example, we do is the very first group we assigned from zero to one probes. The second group we assigned from one to two probes. The left side is inclusive, the right side is exclusive. Then you go to a group of size from two to four, then four to eight, eight to 16 and so on and so forth. So it's exponentially, the group size is sort of growing exponentially. And what I'm gonna do is I just took the PDF over all the possible assigned probes in each of these ranges. So what I did is I took from this previous thing, I just combined them into sort of this PDF where the densities are summed up over each of the ranges. And at a high level, all of the, what we're gonna do is the following, the adversary will essentially just check. So for example, it'll say, okay, I know for this specific distribution for the hard nodes, hard distribution. And for this specific server, the adversary knows that, okay, well, for example, seeing a number of probes assigned between eight to 16 is at least 40%. So what actually happens is that the PDF of assigned probes for the hard distribution, the original hard distribution where it's reading only the zeros, it really has to be within range. It can't be too different. Otherwise, as an adversary for this specific server, I might pick the server with probability of one over K if truly one of these densities was significantly different, I can actually detect that difference as a PPT adversary. And in fact, when I were to get maybe, if I were to able to, I can submit a challenge where I have either the nodes hard distribution or the true hard distribution for the lower bound, which is reading all zeros. And I can try to just guess, pick one of these ranges where the probability densities have changed significantly and sort of just guess between them. And I'd be correct with the significant probabilities. And essentially, just by this reasoning alone for the PPT adversary, you can prove they essentially that the PDF or the assigned hard distribution can't be really different than the nodes hard distribution. And we can also prove that this is very large just by the fact of like I said before, for correctness. This nodes hard distribution, just to be correct on the answers requires you to have that the expected sum across all the servers is large. And that means that even for this hard distribution that's really trivial, reading the 0th entry end times, it must still have a large number of pros assigned. And in fact, once you sort of have this intuition, the rest of the proof is actually complete in a sense in that you can show that essentially by sort of using these range, by sort of using these ranges, okay, maybe in this case you have, maybe in the nodes hard distribution, you might actually assign 15 very often or 14 very often. And maybe in this PDF, it might only assign eight very often, but this is only a factor of true loss. And by the way, we've done this sort of exponential range sort of grouping. We ensure that from the single server lower bound to the multi-server lower bound, we only lose the factor of two essentially. And this is in factor of two is very small in the lower bound, so we still get a lot of group of lower bound. And that actually completes the proof for our lower bound. I mean, the rest of it sort of putting it all together and putting the map together, but that's more technical. And this is sort of the high level main idea of how to construct the adversary. All right, so I mean, that's actually the end of the lower bound proof and essentially the end of this presentation. And before I wanted to go, I wanted to present some other cryptographic self of lower bound that exists, so in particular, I wanted to shed light on other work that has been done in this area. So for example, like I said, the earliest, the first work was by Larson and Nielsen proving a tight logarithm make oblivious random lower bound, shortly afterwards, Jacob and all in 2019 at SOTA, they proved lower bounds for other oblivious data structures, so things like stacks, queues, deeks. Similarly, there was work at Eurocrypt in 2019 that showed an omega log in lower bound for slightly weaker kind of primitive called differentially private RAMs. The first sort of super logarithmic cryptographic cell lower bound where the non-cryptographic version was still logarithmic was done for oblivious new neighbor search at SOTA 2019. And similarly at Crypto this year, there was a paper by actually, by myself as well as the Pino Prasiano where we showed a logarithmic lower bound for other for even weaker primitive such as encrypted search and things called encrypted multi-maps. I also like to note that there's other works where they consider the cell for lower bounds with other settings. So for example, ones where the adversary doesn't know the query boundaries. So in our work, we assume that the adversary knows when one query ends and then the query begins, but this paper by Hubachek and all at TCC 2019 showed that even if the adversary doesn't know when queries start and end, you can still prove a logarithmic lower bound. So I hope you enjoy the talk and I thank you for listening in. And if you have any questions, I guess I'll be feeling them during the actual TCC live session. Thanks again.