 The front of the sorrow will be tomorrow. Okay, so Alexandra, the floor is yours. Great, can I get started? Great, so hi everyone, I'm Alexandra. I am a second year PhD student at MIT, and I'm going to tell you today about some new results on single server private information retrieval with sublinear amortized time. This is joint work with my advisor, Henry Corgan Gibbs, and with Dima Kogan. So to begin, let's not, yes. I've clicked on the slides. Do you know? Ah, there we go. Okay, so to begin, let me explain the private information retrieval problem. In this problem, we have a server that holds an N-bit database, and we have a client that holds an index I between one and N. What our client is going to want to do is to privately read the I-th database bit. It can do this if it interacts with the server following a private information retrieval or PIR protocol. At the conclusion of this protocol, our client is going to learn the I-th database bit, DI, while our server is going to learn nothing about the index I that the client is reading. And lots of work has shown that if we use PIR as a building block, we can build a wide array of very compelling applications. For example, we can build systems for private media consumption, privacy-preserving advertising, and much more. So there has been lots of work on making PIR as practical of a primitive as possible. To date, we know how to build PIR protocols with relatively small communication costs. And specifically in the setting where we have a client communicating with a single server, we know how to build protocols with communication polylog in the database size. Unfortunately, though, PIR requires high server-side computation costs, and bimolishai and milk improve the lower bound that shows that this is, in fact, inherent. So to answer even a single PIR query, the PIR servers must run in time that is linear in the database size. And intuitively, you can think of this as follows. If you have a PIR server that doesn't touch anyone location in the database when answering a client's query, then the server learns that the client probably isn't reading this location of the database, and so this would leak something about the client's query. And so since the server can't learn anything about the client's query, we need our servers to run in time at least n. Fortunately, though, this isn't the end of the road because prior work has shown that we can hope to amortize this linear server time over many queries. In other words, in the many query setting, we can hope to build PIR schemes with sublinear amortized per query server time. So what I'm going to do now is I'm going to survey the existing approaches to building PIR with sublinear server time. The first such approach is what we call batch PIR. In the setting, we have our client make a batch of queries to the server at once. The server is going to answer all queries together in time linear in the database size and then send all the answers back to the client. So the per query amortized server time is sublinear in the database size. A second approach is what we call offline online PIR. In these schemes, the client first communicates with a server in an offline phase, which requires linear server time, but thereafter, the client can make many queries for which it communicates with two servers in an online phase, which requires only sublinear server time. So again, amortized over many queries, the server work per query is sublinear in the database size. A third approach is what we call PIR with pre-processing. In these schemes, the server runs a one-time pre-processing step during which it somehow encodes the database. And after this, the server can answer PIR queries from PIR clients using this encoding in sublinear time. And finally, a trivial solution to the PIR problem is to have the client download the entire database. So here, the server pays a one-time linear cost to ship the whole database to the client. The client stores it locally and answers all of its queries on its own. So again, amortized over many queries, the server's work is sublinear. Unfortunately, each of these prior approaches come with some limitations that make them cumbersome to deploy in practice. Batch PIR requires the client to make its queries non-adaptively rather than slowly over time. Offline online PIR requires the client to communicate with two or more servers, which in practice requires careful coordination between multiple business entities because the security now stems from the fact that an adversary can't corrupt both servers rather than from cryptographic hardness. The known approaches to PIR with pre-processing in the single server setting require the server to store a large encoding which consists of roughly N bits for every client that it is communicating with or they require virtual black box obfuscation. And finally, if the client downloads the whole database then the client also needs to store the whole database which is impractical for large databases that are gigabytes or even terabytes in size. So at this point, the world of private information retrieval is in an undesirable state. We just saw that there are compelling applications but we don't have any schemes that are cheap and easy to deploy. This work does the following. What we do is we give the first PIR schemes that jointly achieve a number of properties that we care about in practice. Specifically, our schemes are gonna require the client to communicate with only a single server. They're gonna allow the client to make its queries adaptively. They require sub-linear extra storage. Specifically, our schemes are gonna have sub-linear additional storage on the client side and no additional storage on the server side. And finally and most importantly, our server is going to run in sub-linear amortized time. So as a quick preview of our results, we're going to give a scheme from DDH in which our server runs in amortized time n to the three fourths and our client has n to the three fourths extra storage. And then we're going to show that from FHE we can do even better. Namely, our server is going to run in amortized time root n and our client is going to have extra storage root n. In addition, we also give some new lower bounds on any PIR scheme in the many query setting and these bounds are going to relate the server time in the client storage. And they show that our most efficient FHE based scheme is in fact optimal when it comes to this trade-off. So in this talk I want to do the following. First, I'm going to give you some background on the types of PIR schemes that we construct. Then I'm going to walk you through our new upper bounds so our new PIR schemes with sub-linear time. And finally, I'm going to leave you with some open questions. So let's begin with the background. As I said, our goal in this work is to build PIR scheme that supports many adaptive queries with sub-linear amortized time. And so throughout this talk I'm going to use Q to denote a bound on the number of adaptive queries that our client wants to make. To achieve this goal, our approach is going to be to build PIR schemes that work in two phases. First, our client and our server are going to run a one-time offline phase which is going to require linear server work. And after this, for each of the Q adaptive queries that our client wants to make, it's going to run a sub-linear time online phase with the server. So again, amortized over many queries, namely if, and if Q is large enough, namely if it's at least n to the epsilon for some constant epsilon, this is going to give us a PIR scheme with sub-linear amortized time. So in a little more detail, our PIR schemes are going to look as follows. First, our client is going to run an offline phase with the server, which will require a linear server time. And at the conclusion of this offline phase, our client is going to retrieve and store a small hint about the database contents. This hint will have size sub-linear in n. Later, at some point, our client is going to decide that it wants to read some database index, say index I1. So our client is going to interact with the server, so send a query, get back a reply, and using this reply in the hint, our client is going to recover the I1 database bit. Even later, our client is going to decide that it now wants to read database index I2, and it can proceed exactly analogously and run another online phase to read database bit I2, and so on for Q queries. So what are the requirements on such a PIR scheme? Well, first, we care about correctness. Correctness means that if we have an honest client and an honest server that execute the protocol faithfully, then for any database held by the server, and for any Q adaptive indices queried for by the client, the client is going to correctly recover all the database bits that it wants to read with overwhelming probability. In addition, we care about security and more specifically malicious security. What this means is that even if we have a malicious server that does not follow the protocol, our server is going to learn nothing about the Q adaptive indices that the client is reading. So for any two adaptive query sequences, I and I prime, our server's view is going to be computationally indistinguishable, whether the client is making query sequence I or making query sequence I prime. And the way we achieve this malicious security property is by ensuring that in our schemes structurally, the client's queries are always going to be independent of the server's prior answers. So even by deviating from the protocol, the server can't learn anymore about what it is that the client is reading. And finally, now that we have these two requirements, our goal is going to be to minimize the costs of our PIR schemes. So to minimize the communication between the client and the server, minimize the computation, especially on the server side, and finally minimize the storage costs which in our schemes are only on the client side. Great, so now we are ready to start looking at some PIR schemes. And what I'm going to do first is give you a more formal overview of what exactly it is that we prove. So the first result that we get is that assumptions that imply linearly homomorphic encryption are enough to build this PIR with sublinear amortized time. More specifically, under the decision Diffie-Hellman, quadratic residuosity, decision composite residuosity, or learning with errors assumptions, we can build a single server PIR scheme such that on database size n, and if our client makes at least n to the one fourth adaptive queries, then our server is going to run an amortized time n to the three fourths. Our client is going to have extra storage n to the three fourths. Our server is going to have no extra storage in the amortized client time and amortized communication are also going to be sublinear. And this is a good point to note that throughout this talk I'm going to hide factors that are logarithmic in the database size and polynomial in the security parameter. Then we wondered if we can do better and we proved that from stronger assumptions, namely from fully homomorphic encryption, we can. Namely from fully homomorphic encryption, we improve the amortized server time to be root n and the client storage to be root n if our client makes at least root n adaptive queries. In this work, we also give a new lower bound which proves that the tradeoff between the server time and the client storage is in fact optimal in the second FHE based scheme. And now what I'm going to do is I'm going to give you a quick sketch of a construction that proves theorem one. So to prove theorem one at a very high level we're going to proceed as follows. We're going to start with a pre-existing result which is that single query private information retrieval with sublinear online time exists. And this was proved by my co-authors. And what we're going to do is we're going to build a new generic compiler which takes as input a single query PR scheme and outputs a many query PR scheme that supports Q adaptive queries. This generic compiler is going to apply ideas from batch codes but crucially unlike batch PR it's going to let the client make its queries adaptively. And so then if we take this pre-existing result and plug it into the compiler what we get out is a new PR scheme which lets the client make many queries and lets the server run in sublinear amortized time which is exactly what we sought out to construct. Okay, so let's begin with the pre-existing result. Single query PR with sublinear online time looks as follows. So specifically what my co-authors proved is that assuming QR, DDH, DCR, or LWE we can build a PR scheme such that first in the offline phase our client is going to interact with the server. This is we're going to require offline time N and the client is going to recover a hint about the database contents that has size N to the two thirds. Later on our client is going to decide that it wants to read some database index I and so it's going to again interact with the server and this online phase is going to require only sublinear server time. Namely server time N to the two thirds. At this point you may notice that this scheme does not give us sublinear amortized time yet because it's single query. So the client can only use this hint to make a single query and so even though the online time is sublinear the total per query time is still linear in the database size. Our job now is to compile this PR scheme in a way to support Q adaptive queries. We do this with the following idea. So to handle Q adaptive queries we're going to split the database into Q random chunks. So specifically we're going to have our client send a permutation over the database indices to the server. The server is going to apply this permutation to the database and then chunk the database into Q chunks each of size N over Q. Now we observe that by a balls and bins style analysis when our client is going to make Q adaptive queries then with overwhelming probability at most lambda distinct queries are going to fall into any one chunk. In other words for our purposes it's now going to be sufficient to build a PR scheme that lets the client read from each chunk adaptively at most lambda times. So we're going to do this as follows. First in the offline phase we're going to again have the client send a permutation to the server. The server applies this permutation to the database and chunks the database up into Q chunks each of size N over Q. And then our client and our server are going to run lambda offline phases of the underlying PR scheme on each of the Q chunks. So the client is going to get back some answer and it's going to recover lambda Q hints namely lambda hints about the contents of each of the Q chunks. Okay, so later on our client is going to decide that it wants to read some database index I1 and what it can do is it can first figure out which chunk it is that I1 falls into. Here I1 is going to fall into the middle chunk and so the client can select a hint that matches this middle chunk. With this middle hint the client can build a PR query exactly as in the underlying PR scheme. And now our server is going to take this query and it's going to answer it with respect to each of the Q database chunks. So our server is going to send back Q answers. And finally our client knows that it's only trying to read the middle chunk. So from the middle hint and the middle answer it can recover the I1's database bit exactly as in the underlying PR scheme. Now our client is also going to cache the I1's database bit. So if it should ever want to read this index again it can just use its locally cached value and make a dummy query. And finally our client is going to discard the hint that it just used because the underlying PR scheme is single query and so it can never reuse this hint again. Great. So now say our client wants to read some second database index I2. Well it can proceed exactly analogously make the same online queries and get back an answer which will let it recover database index I2. And the same thing happens when our client wants to read database index I3 again later. Great. So this completes the construction of the compiler and I'm going to give you some intuitive arguments for why this works. First of all correctness holds because as we argued before for any query sequence the client is not going to need to read any chunk more than lambda times with overwhelming probability. And so for any query sequence our client is not going to run out of fresh hints also with overwhelming probability. Security holds intuitively because the underlying PR scheme is secure and so the server learns nothing about which index the client is reading within each of the chunks and our query leaks nothing about which chunk it is that the client is trying to read. And finally the cost of this construction is dominated by that of running the underlying PR scheme lambda Q times each on a database of size and over Q. So what we can do now is we can pick a value for Q we'll take Q to be n to the one fourths and we can look at the performance of our input PR scheme think about running this input PR scheme lambda Q times on a database of size n over Q and this will give us the performance of our output PR scheme. And specifically we will see that we have just constructed a PR scheme with hint size n to the three fourths offline time n and online time n to the three fourths. In addition, our output PR scheme supports n to the one fourth adaptive queries and so the amortized per query server time is going to be n to the three fourths. So now we indeed have a PR scheme with sublinear client storage in sublinear server time which completes the construction. Great, so now we have seen a sketch of the proof of theorem one and you may wonder if we can prove theorem two in exactly the same way. Unfortunately, the answer is no. To prove theorem two, we give an entirely new PR scheme from scratch and this is somewhat more involved so I'm only gonna give you a high level overview of how this proof works and I'm gonna refer you to the paper for more details. So at a very high level to prove theorem two we prove two claims. First, we show that if the client has some prior knowledge of the parodies of roughly Q random independent subsets of the database, each of size n over Q, then our client is able to make Q adaptive queries each with online time n over Q. And so this is different from prior work because prior work only shows how to make a single adaptive query with online time n over Q but now we show that the client can indeed make Q adaptive queries. Then we give the second claim which is we build a Boolean circuit for retrieving the parodies of roughly Q subsets of the database each of size n over Q in roughly n gates. So the way our scheme is going to work is in the offline phase our server is going to run this circuit under fully homomorphic encryption. This is gonna happen in roughly linear time and because it runs under fully homomorphic encryption the server learns nothing about what these random subsets are. However, our client is going to learn exactly the prior knowledge that it needs by claim one to then make Q adaptive queries each in online time n over Q. And so when we take Q to be root n this indeed gives us the theorem statement where we have the client make root n queries in amortized time root n and with client storage root n. Great. So now I'm going to leave you with some open questions. What we saw in this talk is that adaptive single server private information retrieval with sublinear amortized time and sublinear storage is theoretically feasible. Unfortunately, these schemes are not quite concretely efficient enough for use in practice. So there's still a lot of work to be done to push PR closer to practice. There's been some follow-up work that improves the communication of our FHE based PR scheme to be O of one. And other exciting open questions are whether we can construct optimal PR schemes so schemes that match our lower bounds from assumptions weaker than FHE or whether we can somehow circumvent our lower bounds by building PR schemes in which the server encodes the database in addition to having some client storage. So at this point, I would like to thank you for your attention. I will refer you to the paper for many more details on everything I just told you about and I'm happy to take any questions. We have time for one short question. Yes. So you're asked. Alexandra, maybe you could repeat the question because maybe not already heard it. Yes, so if I understand correctly, the question is if the server has a database where the records are of length m instead of length one bit, whether they're how this would work. And so yes, the simplest way to handle this is to run the PR scheme m times each time on a database of size n where the first database contains the first bit of each of the records, the second database contains the second bit and so on. Yes, this is the way to do this. Yes. Thanks for the question. Okay, maybe we actually have time for one more question. So, Martin. Yes, great question. Yes, so the question is, what can we do if the database changes? So as you noticed in our schemes, the client is retrieving some hint about the database contents. And so if the database changes, our hint becomes outdated and what do we do then? So some prior work has shown that if the database changes, you can actually build on even older work on dynamic databases to handle these updates gracefully if there aren't too many of them. So specifically, if only a constant number of the records in the database change, then you can do this without any additional overhead. However, like in the limit, if the whole database changes, then of course we need to run the scheme again from scratch. Okay, thank you very much. Thank you. Let's thank Alexander again. Thank you.