 Hi, I'm Dima, a fourth year PhD student at Stanford working with Dan Bonet, and today I will be talking about private information retrieval with sublinear online time. This is joint work with Henry Corrigan-Gibbs. Thank you for watching this virtual presentation, and I hope you enjoy it. In this work, we present a new method for making PIR faster. Specifically, our new PIR schemes push the bulk of the work to a preliminary offline phase, during which the client fetches a short string from the server. In a subsequent online phase, the client can privately query the database, and the server can respond to the query very quickly, in time sublinear in the database size. Moreover, our schemes do not require any additional storage on the servers. First, let me give you a little bit of background about PIR. Private information retrieval, introduced by Shor, Goldrach, Kushi Levitt and Sudan, is a cryptographic protocol between a database and a client that allows the client to read any record in the database without the database server learning which record the client is reading. And throughout this talk, we will model our database as an n-bit array, meaning each record is only a single bit. However, using standard techniques, PIR can be applied to databases with larger records, as well as to key value databases rather than plain arrays. PIR is useful in scenarios where the user's query contains some sensitive information. For instance, a query to a database of medical conditions might reveal some information about the user's disease, and a query to a database of stock prices may contain information about the user's financial interests. And in both cases, the user would ideally want to keep his query private. PIR is also useful as a building block in larger privacy-preserving systems for applications such as private messaging, search, or DNS. More formally, a PIR protocol has to satisfy the following properties. First, correctness, meaning that an honest client interacting with an honest server should learn the correct value of its bit of interest. And second, security, meaning that the server should learn nothing about which bit the client is reading. And as always, learning nothing means that the view of the server when the client is reading bit i should be indistinguishable from the view of the server when the client is reading bit j. And actually, there's a trivial protocol that meets both of these requirements. The client can simply download the entire database and perform its query locally. However, downloading the entire database is impractical in most settings, so we would want the protocol to be efficient, meaning that the total communication between the server and the client should be minimized. And indeed, these requirements can be met. The same work that introduced PIR also presented a protocol that achieves sub-linear communication by replicating the database on two or more non-colonial servers. And ever since, there has been a long line of work improving the communication complexity of multi-server PIR. And today, the best PIR protocols have communication complexity and to the little of one, and they provide information theoretic security. Moreover, if we settle on computational security, recent protocols achieve logarithmic communication just from one-way functions. In addition, soon after the original multi-server PIR paper, Kuszy Levitz and Ostrowski showed that one can build PIR with only a single server, but here computational assumptions are necessary. Today, we know how to build PIR with polylogarithmic communication complexity in the single server setting from a wide range of public key assumptions. So it seems that in terms of communication, our situation is actually very good. However, the situation is not as good if we look at computation. In fact, in the protocols on the last slide, a server needs to scan the entire database to respond to a query. And in practice, doing linear work on every query is very expensive. It turns out this is in some sense inherent, since the expected server work in any PIR protocol must be linear in the database size. The intuition is that a server must touch every bit of the database, since if it doesn't touch one of the bits while it is responding to a query, it can guess that this untouched bit is not the bit the client is attempting to read. And although it is not at all trivial, it also holds in the multi-server setting. There have been several approaches to reduce the server work in PIR by somehow circumventing this lower bound. A very promising approach is called PIR with pre-processing, where the basic idea is that the servers store the database in encoded form, and using this encoding, they can respond to user queries much faster than in linear time. The catch is that now this encoding of the database, which the servers need to store, is much, much larger than the original database. So for instance, to get query time and to the .6 using this approach, the servers need to store code words that have length larger than n cubed. And this is not very practical for databases that are gigabytes in size. There have also been other approaches that reduce the server's work in PIR by batching queries, sharding the database, relaxing the privacy guarantees, or moving the more expensive part of the work to an offline phase. However, the overall amount of online work in all of these approaches is still linear in the database size. So the plan for the rest of this talk is, first I will define the offline online model, then I will present our results in more detail. Then in the main technical part, I will explain the main ideas behind our two-server PIR construction. In the end, I will talk a little bit about the single-server setting, and then I will conclude. But let's start by defining the model. For simplicity, we will be working in the two-server setting, and we will refer to our two servers as the left server and the right server. And crucially, we assume that the two servers are non-colluding, meaning that the adversary controls at most one of the two servers. Our scheme starts with an offline phase. In the offline phase, the client interacts with the left server who provides it with a hint, which is a string that depends on the database itself. The length of the hint has to be sublinear in the database size, as otherwise the hint could just be the entire database. And to give you a preview in our constructions, the hint will be about square root n bits in length. To produce this hint, the server does need to perform a linear amount of work, but the key point is that this phase can take place before the client has decided on which bit it wants to read from the database. So the server has much more flexibility to perhaps run this phase overnight and without any strict latency requirements. So after completing the offline phase, the client stores this hint and waits for the online phase to begin. And know that unlike in the PR with pre-processing approach, the servers don't use any extra storage, and in fact, they just store the database in its original form. And then the second phase is the online phase. Here, the client decides on the actual input index i, the index of the element from the database it wants to read. And it uses the locally stored hint to generate the query to the other server, the right server. And the response to this query together with the hint allow the client to recover the bit of interest x sub i. And crucially, the servers work in this phase, as well as the communication between the client and the server has to be sub-linear in the database size. I should mention that an offline online model has been considered in the past, yet previous schemes in this model either have linear online time or require additional storage on the server. So now we can state our results in a bit more detail. Our first result is a two-server offline online PIR scheme with square root communication and square root online time. And for simplicity throughout this talk, I will avoid explicitly writing factors that are polynomial in the security parameter lambda and polylogarithmic in the database size n. So when we talk about square root of n, what we really mean is o tilde of square root of n times some polynomial in lambda. And this construction uses only basic symmetric key primitives, so it is concretely efficient. The construction also has the extra property of allowing to execute multiple online queries without having to redo the offline phase from scratch each time. And this means that the linear cost of the offline phase can be further amortized across multiple queries. Our second result is a single server offline online PIR scheme, which uses n to the two-thirds communication and n to the two-thirds online time. In terms of assumptions, what we need here is black box use of any single server PIR scheme with low communication and additively homomorphic encryption. And both of these can be built from a variety of public key assumptions. If we are willing to use heavier tools, namely FHE, then we can recover back the square root of n running time. And an extra property of our single server scheme is that it doesn't require any public key operations in the online phase, which makes the online phase even faster. A drawback that our single server scheme has is that unlike the two-server scheme, it requires a separate execution of an offline phase before each query. And finally, we give a lower bound for offline online PIR schemes in this model, where the servers need to store the database in its original form. Specifically, we show that the product of the communication C and the online time T must be at least linear in the database size. And this matches our two-server scheme and the FHE-based single server scheme. And I should say that this lower bound holds even in the computational setting. So now we proceed to the main technical part of the talk and we'll see how the two-server scheme works. So let's start with the offline phase. Here the client chooses m random subsets for a parameter m that we will set later. So these are m subsets where each subset contains square root n independent random elements from the universe of one through n. And then what the client does, it sends those sets to the left server. And naively sending this amount of information would take too much communication. So we could either generate those sets using some shared randomness between the left server and the right server. Or we can just use a pseudo random generator and then the client only needs to send a seed to the left server. So yeah, when the server receives these m sets, for each of these sets it computes the parity of the database bits that are indexed by the set. So overall it computes m such parity bits, one for each set, and sends them back to the client. And what the client does, it stores the collection of this set and their parities as the hint. So the hint contains a collection of sets and their parity bits. And that's the entire offline phase. Notice that there's no index i in the picture, so everything here is completely independent of any particular database index and this can happen offline. Now we move on to the online phase. Here the client decides which index i it wants to read from the database. And the first thing it does is to look for a set in its local collection that contains the index of interest i. If none of the sets contain index i, then the client fails and we will later see how to deal with all these failures. If such a good set SJ does exist, then the basic idea is that the client removes element i from the set and send the set as prime, which we call the punctured set to the right server. Except that with some small probability of roughly one over square root of n, the client actually does something different. It sends to the right server a random set s prime that does contain index i. And this is also considered a failure, which we will account for later. In any event, the right server receives from the client the set s prime, which has size square root n minus one. And just like the left server did before, it computes the parity of the database bits index by this set and sends back the parity bit back to the client. And now the client has two bits. It has the parity bit hj from the hint, and it has the answer bit a from the right server. So the client just outputs their sum mod 2. And note that hj is the sum of all the database bits in the set SJ. And the bit a is the parity of all those same bits except bit x i, since the client removed index i from the set SJ. Therefore, the sum of those two bits is exactly the bit of interest x i. And that's the construction. Okay, so now let's go back and look at those two failure events. So the first failure event is when the collection of sets doesn't cover all indices. And here is where we choose the number of sets little m to be roughly square root n times log n. And then by standard coupon collector argument, the failure probability of this first event would be something negligible in n. And then the second failure probability, it comes directly from our construction, which is the event that we send this random set as prime that contains i and consider this a failure. And this happens with probability roughly one over square root of n, which is also the overall failure probability. So what we do next is we actually want to drive down the failure probability even further. We want it to be negligible in the security parameter lambda. So we repeat our entire construction lambda times in parallel. And this is not the most tight analysis. But in any event, now that we have lambda instances, the probability that all those instances fail happens with a probability that is negligible in the security parameter lambda. And one point that I want to emphasize is that those repetitions, they include both the offline phase and the online phase. So in fact, the client generates lambda independent hints in the offline phase. And it repeats this online phase lambda times in parallel completely obliviously of any successes or failures it has in some of those iterations to avoid leaking anything from those failures to the server. Okay, so that's overall we end up with a negligible failure probability. This is the correctness that we want. Okay, so now we turn to doing the sketch of the security proof. So first of all, the security from the left server is actually pretty immediate. The sets that the client sends to the left server, they do not depend on the index i in any way. So they can't possibly leak anything about index i. The security against the right server is trickier since the set SJ clearly depends on index i. And here is where the non-collusion assumption and this weird looking sampling come into play, since they guarantee that the resulting set S prime is a uniformly random subset of size square root n minus one independent of i, and therefore hides i from the right server. And to see this, we can identify the distribution of the set S prime with the following way to sample a uniformly random set. So fix any index i, and then a uniformly random set of size square root n minus one should contain this fixed i with probability square root n minus one over n, which corresponds to the first case above. And with the remaining probability, the set should contain elements which are all distinct from i. And this is what happens in the second case where we explicitly remove i from the set SJ. So overall, the set S prime is independent of i, which shows security from the right server. And just one more thing, if we generate all the sets using a PRG rather than using true randomness, then we simply lose some negligible distinguishing advantage, but the argument is basically the same. Let's now look at the efficiency of our protocol. The communication in the offline phase consists of the client sending square root n random sets, which we assume we can shrink using either a PRG or shared randomness. And the server sends back square root n parity bits. So the total communication in the offline phase is square root of n. In the online phase, the client just needs to send a single punctured set to the right server and get back one parity bit. So the total communication is also square root of n. In terms of computation, the offline phase is linear since the server needs to process all the sets, and the online phase runs in time square root of n since the server just needs to process a single set. Next, I want to discuss a main feature of our two-server scheme, which is that it amortizes the linear cost of the offline phase by running multiple successive online queries without having to redo the offline phase each time. The problem in naively running multiple queries as is, is that the client must be careful not to reuse the same set as j for two different reads. If the client would accidentally do that, then from the symmetric difference between the two appearances of the same set, the server would be able to learn the client's indices. So instead, the idea is that we refresh the hint by sampling a replacement set s new and then fetch the parity of this new set from the left server. And we need to be careful to sample the new set in a way that preserves the joint distribution of the sets in the collection to provide correctness guarantees for future queries, and also everything needs to be done in a way that hides index i from the left server. This refreshing procedure can be done any polynomial number of times, and the bottom line is that now preparing for the next query only takes square root n time rather than linear time, which is what redoing the offline phase from scratch each time would have cost us. So to sum up the two server results, we show the scheme with square root n communication in online time and even amortize total time per query. The client's storage and running time in our scheme is square root n, and the scheme requires either pseudo random generators or shared randomness between the client and the left server. We also have extensions to our scheme such as trading off communication for online time and vice versa, and there's also a statistical security variant that works even when there's no shared randomness. Finally, using punctual pseudo random functions, we can have the client send only a short description of a punctured set which shrinks the communication in the online phase to only log n. The resulting scheme is highly efficient in terms of communication, though the client's running time is not as good as before. The last thing I want to talk about before I conclude is to give you an idea of how our single server scheme works. The general idea is that we want to transform our two server offline online scheme into a single server scheme by running both phases on the same server. However, this breaks security which crucially relies on no single server seeing both the offline and online queries. To work around this, the client encrypts the offline query using homomorphic encryption, and the server evaluates the offline phase without seeing the client's query in the clear. The online phase remains the same as before. And here we have two options. We could either use fully homomorphic encryption which preserves the asymptotic running time of square root of n, or we can use an additively homomorphic encryption scheme, but then having to express the scheme as a linear transformation forces us to use a less efficient representation of the sets, which results in a worse asymptotic running time of n to the two thirds. The advantage is that the second scheme is concretely more efficient. So to summarize, we have seen a new type of PIR schemes that get sublinear online time and require no additional storage on the server. In the paper, we also have a lower bound for this model, which we prove using a reduction from a classic problem by Yao. And finally, I want to mention two open problems. First, it would be great to get schemes with better running time on the client's end. In our scheme with log n online communication, the client's running time is n to the five over six. It would be great to make the client more efficient. And second, one limitation of the offline online model is that the offline phase is separate for each client. It would be very interesting to be able to somehow amortize the offline costs across multiple mutually distrusting clients. And with this, I'll conclude.