 Okay, so I'm going to talk about the limits of practical sublinear secure computation, which is a joint work with Inlet and Joval. Secure to party computation allows the set of two parties to compute a joint function on their inputs in such a way that the honest party receives the correct output, and the output is the only new information leaked. And we want this to hold in the presence of an adversary, and in our work for simplicity the adversary is going to be semi-honest, and our negative result will translate to the malicious setting. So we live in a war with ever-expanding volumes of data, and our ability to collect and analyze this data increases our understanding. And while big data technology offers great promises, it poses a challenge. We want to compute and perform complex computations while preserving the privacy. And we want to ask this guy to perform like complex computation on big data and secure computation, and we don't want this to happen. So efficiency of secure multi-party, two-party computation protocols on big data refers to how much data we need to transfer during the execution of the protocol, refers to its communication complexity, and how quickly the protocol runs, refers to its computation and complexity. So we don't want to have complexities that grow linear with the input size of the database. And we have actually all-generic protocols that we know. They have sublinear communication complexity in the size of the database, like fully homomorphic encryption and PIR-based protocols. However, these protocols pay the price of high computational complexity, which is linear in the input size of the database, and in fact, it's like bad linear in the sense that it doesn't require symmetric crypto operations, but it requires heavy public key operations. So ideally, we would like to have sublinear computational complexity as well. And if we stack with linear computation complexity, it better be symmetric key operations and not heavy public key operations. So from now on, when I will refer to communication complexity, I would always mean sublinear. So we saw that the PIR protocols and the FHC protocols, they have linear computation complexity. See here, I marked them with the right sign. But there are some exceptions. So there's some combinatorial problems, which are actually some graph problems, where the two parties have some parts of the graph that actually do enjoy sublinear computation and communication complexity, like it's the median convex hull, single-source orders destination, approximate set cover, and all-pair orders distance, and minimum spanning trace. So there are these works, Agrival et al, Briekels, Matikov, and Selat and Mutu. They provided, as I call them, easy protocols, which enjoy sublinear communication and computation. So are these functionalities here a special case? So can we have more functionalities with these complexities? So can we characterize which functions can and cannot be computed with sublinear overhead? Are the median problem and the convex hull only like isolated cases? So can we classify these functions? We're going to actually provide a framework for separating hard and easy problems. And once we have set the framework, we can actually provide form and reduction, showing if the problems actually are hard. It's like the anti-completeness, where we can show that some variants of some protocols are easy and some of them are hard. And moreover, we're going to provide some intermediate hardness, which is going to cut to protocols that are neither easy on our hard. It's like with anti-completeness, that factoring is conjectured to be like not to be NP-hard, but we believe it's hard. And we're going to consider three types of functionalities. So we have the two-sided functionalities, where both parties receive the output. Then we have one-sided functionalities, where only one party receives the output here. And the one-sided functionalities are going to imply the secret-serred output functionalities, where one party, it can be viewed as one party that receives the output in a secret-serred form. The brackets mean secret-serred. And then he can send the secret-serred output to the other party. So these are two-sided functionalities, where parties get the secret-serred version of the output. And this is very useful when we want to compose many MPC protocols, like put an MPC protocol in a larger MPC protocol. So we're going to take the one-sided version of all these problems, and the secret-server of all these problems. And in fact, we're going to show that they are hard. The answer is true. So to cut through this hardness, the measure that we're going to use is private information retrieval. Let me first define the problem. So the problem is very simple. We have Alice, and she wants to get some entry from a remote database. So she sends a request, and she wants to receive back the entry at location i. And the privacy is that we don't want the server to learn anything about the index i. So is this possible? There's a trivial solution. So Alice can send a generic request, like wake up. And then the database sends back all the entries that it has. So does this satisfy the privacy notion? Yes, because the database sends all the data, so he cannot learn anything about the index i of Alice. However, this is very inefficient. The communication complexity is huge. Imagine that the server is Google, and Alice asks for a website, and then the server sends back the whole internet, and they say, OK, try to find your website. So what do we want to do? We have this non-triviality requirement that we want the communication complexity to be sublinear in the input size of the database. And based on the current state of the art on one server peer protocols, they require communication complexity which is sublinear in the input size. But they require a lot of computational complexity. And this is inherent, even if we have pre-processing. And as I said before, it even requires a lot of public key operations. And despite these great advances in lattice-based peer protocols, like there are the system x-peer and sealed peer, still these systems are magnitudes of orders slower than symmetric key operation. Yeah, and we cannot have one server information so if we have pre-processing, it's not going to help. And also, there's more work, assuming some pre-processing, but they're still very slow. So given the current state of affairs, we can see that peer is really the measure that can really capture the hardness of 2PC protocols. Because if a protocol reduces to peer, then it really means that it's going to have linear computational complexity, and even given pre-processing. So this brings me to our framework. So we define peer hardness, and the problem is peer hard if any secure protocol for this problem implies non-trivial peer on a large database. Non-trivial, I mean that we have sublinear communication complexity. And if this happens, that means that this problem really inherits all the bad consequences that peer has, like the bad communication complexity. And here's like the simplest notion that we provide in our paper, we say that the two-party functionality is peer hard if there is a single server protocol on a database of size n to n, making a single call to the function f. And this notion, we can actually extend it to multiple calls. So now I'm going to show you a simple example why the one-sided median problem is peer hard. So what is the median protocol? Like two parties have a list of some medical entries, and they want to find the median of the combined set. And it's one-sided, so only Alice will get the output. So to prove that the one-sided median is peer hard, we're going to construct a peer protocol, making only a single oracle call to this function f, to the median functionality. So how are we going to do that? Here we have Alice and Bob. No, it's not Bob, it's the server. So how are we going to make our call to the median functionality? So for simplicity, suppose that the server has only two entries. So what he's going to do? He's going to sort the two entries. And then suppose that Alice is interested in the first element, say i is 0. So then the two parties are going to call the median functionality with these inputs, like d0 and d1 and the minimum element, where the minimum element is like the smallest element in the field where the numbers lie. So now if we run the median protocol, so you can see that the order of the elements is going to be like this. And the output, the median, is going to be like the d0. So in that case, Alice will receive d0. And here we can see that we constructed peer, where Alice is getting d0. And likewise, if i is interested in the second element, it's going to put the max element in the field. And then the ordering is going to be like this. Now d1 is the median element. And then the protocol is going to give d1 to Alice. That was a toy exam. And for the generic case, when we have many data in the database, the client is trying to make the set such as the median element is the element that he wants from the database. So you can actually notice that this reduction completely fails if we're in the two-sided case. Because if the server receives the element d0 and d1, he can really see the index of the client, what he asked. So this reduction completely fails. And these are the peer-hard problems that we saw in the paper. So we saw it for the median, the convex hole, and these problems. I'm not going to repeat them. And just as a side note in the paper, like to make this reduction, we use a combinatorial tool, which is the VC dimension, usually used in learning theory. So this measure tells us about the capacity or the richness of a function. So a functionality is peer-hard if it has some certain VC dimension. And essentially, we're saying how much peer we can squeeze out of some functionality. And if, for example, functionality has high VC dimension, then it's peer-hard. And if it has low VC dimension, then it's not peer-hard. I'm not going to talk more about this. We'll just a side note. So are we happy now? So we proved that one-sided functionalities are hard, peer-hard. And we have all these two-sided functionalities that the previous works of Mutu and Abisod that they're easy. They have sublinear communication and computation. So are we happy now? Is this a generic phenomena that two-sided functionalities are easy? So maybe not. Let's see. So take this real scenario. So we have a party, Alice again. So she has a location in Manhattan. And she wants to go to a restaurant. And Bob has the map of all the restaurants, as you see there are too many. So now we have the nearest neighborhood problem, where it outputs the nearest location, like the nearest restaurant, to Alice's location. And Alice wants to keep her location private. So this is the setting of the problem. And why is this a two-sided functionality? Why we should send the output to Bob? But this is like we are acting on the output. We are going to the restaurant. So this information is going to be publicly known. So it's inherently two-sided functionality. And it captures natural problems that we want to solve. So based on this example, we're going to define semi-peer hardness, which is a relaxation of peer hardness, where we only have privacy if the element in the database is only a one. So if the element in the database is zero, then the server is going to learn the location i of the client. There's some asymmetry here. So the server only learns the output if the entry is zero. So this is very useful also for some other exam. Suppose that you have a list of candidates, and you are revealing the winning candidate. So the fact that you are revealing the winning candidate, everybody's going to know that. But you want to hide the rest of the candidates. So this notion motivates these kind of problems. So now I'm going to show you why the nearest neighbor problem is two-sided. Oh, this counts like downtown. So I have 10 minutes, right? So remember that in the semi-peer notion, the server gets the index i of the client only if the element in the database is zero. So what we're going to do, we're going to build, again, a peer protocol using only a single invocation of the nearest neighborhood problem. So again, suppose for simplicity that the database has four entries, 0, 1, 0, 1. So how are we going to do the mapping of the inputs? Like the inputs that they need to use in the nearest neighborhood problem. So if the entry is zero, then we get the circle with center C. And if the entry is zero, we are picking a location on the circle. So it's going to be like that. So when we have a zero, we pick a location on the circle. And if it is a one, we pick a location outside of the circle. So this is how the server is going to encode his database. So now suppose that Alice is interested in some location. Suppose she's interested in location three. So how is she's going to pick her location? So it's going to take like the location that intersects the line that crosses the center with the element that she's interested. And another circle that has like half radius from the bigger circle. So now if we run the nearest neighborhood problem, where Alice gives the location x, y, which is this one, the red one. And Bob gives the center and all these four points here. So you can see that if the location is one, so we are here in this example. So the nearest element to this location is the center. It's not this element, because this is half radius of the circle. So this means that we are revealing to the server the center. So this means that we didn't reveal the location i, so we are good. And now suppose that the location is like zero. So the client gives this element if she's interested in this in the first element. So in that case, the nearest element to the red spot is the center and the element that we want. So in that case, we see that the server does learn the location, the index i that Alice asked. So this is really semi-peer. So you learn the output. The server learns the output only if the entry in the database is zero. So that's why it implies semi-peer. And you can imagine how it goes if you have more elements in the database. So that was an example to show that nearest neighborhood is a semi-peer hard problem. And in the paper, we saw that other natural problems are semi-peer, like single source, single destination shortest path, shortest selection, and closest destination. Here are problems that we want to pick like, say, the minimum or maximum element from a list. So we also show information theoretic separations between semi-peer and peer. And in fact, we prove that we cannot construct peer, making a one call to semi-peer. And in fact, in the paper, we can afford more calls. I'm going to be specific here about this. So this really means that semi-peer really captures the true complexity of some natural problems. Then we give an evidence that actually semi-peer is as hard as peer, because we saw that the existence of polylogarithmic semi-peer implies the existence of slightly sublinear peer using an adaptive reduction that makes multiple calls to semi-peer. And our reduction uses locally decodable codes. And in fact, if you want to show that the polylogarithmic peer implies polylogarithmic, no. If we want to construct for a logarithmic peer from polylogarithmic semi-peer, we will have a breakthrough in coding theory. Because for that, we will need to construct this dream locally decodable codes where they have constant query complexity and polynomial rate. So for the rest of the talk, like I have five minutes, I'm going to show you how we can construct polylogarithmic semi-peer. No. How we are going to construct from polylogarithmic semi-peer slightly sublinear peer. And we're going to use locally decodable codes. And we're going to make two-to-the-queue adaptive calls to semi-peer. So we're going to call the semi-peer two-to-the-queue times to construct peer. So as a first step, I'm going to reduce semi-peer to what we call round half-peer. What is round half-peer? It's a probabilistic peer where the server learns the index with half probability. So how we're going to do it's very simple. So we get the database. And essentially, we double the database, adding the complement of the database. So if this is like 0, 0, 0, 1, 1, then the complement will be 1, 1, 1, 0, 0. So we double the database. And now, if the client wants to ask for, say, entry i, he's going to ask either for entry i or i plus 1 plus n, where n is the size of the database. So these two elements, one will be 0 and one will be 1 because we took the complement here. So this really means that with half probability, the server will get the answer, get the index i. So having this, now I'm going to show you how we can construct from round half-peer, peer. So how we're going to do that? So the server is getting the database, which is like this. And he encodes it using a locality-codable code. Then the client, he's going to run the decoder of the locality-codable code to get the index that he's interested in. So locality-codable codes, they can be viewed as one round multi-server peer, where if we want to access some entry i in the original database, we need to do queue queries to the database. That's why the locality-codable code is queue query. So to access entry i, we need to make queue calls to the database. So on the slide, I assume that queue is five. So how we're going to do that? So to recover entry i, we need to make five calls. So because this is the round semi-peer, it means that each query links with half probability. But we want to build peer, so we cannot afford any leakage. So how we're going to do? So imagine that we are playing a video game. And we are telling you, if you lose two times, then your device is going to self-destruct. So what you're going to do? So what you're going to do? OK, if you lose once, you restart the game. And the device is there, right? So what you're going to do? You ask one query. And if it leaks the bit, then you restart again. So since I assume that queue is five, so now each query leaks with probability 1 half. So the probability that nothing leaks is 1 over 2 to the 5, right? And this means that the expected number of times that we need to run to restart actually this reduction is 2 to the 5. Here's why the reduction works. And we proved that we can have 2 to the queue, which is here five calls. In fact, it's queue times 2 to the queue. OK, so this is the reduction. So to conclude, we gave this framework for classifying, like, if a problem is hard or easy, based on peer hardness. And then we also saw, based on our framework, that some problems are peer hard. So changing slightly some functions, we saw that when we go from one-sided, from two-sided to one-sided, we saw that it's actually hard. They are peer hard. And then we also introduced the semi-peer hardness which capture the complexity of some natural problems, as we saw. Here is like our taxonomous. So we have all these easy problems. Then we have the semi-peer hard problems. And here are the peer hard problems. So we provided this classification of hard and easy problems. But as you know, reality is more complex. And like NP completeness, you should take our framework with the grain of salt. And there are many future directions to explore. So for example, like, can we have a hierarchy of hardness beyond semi-peer and peer hardness? For example, can we have, like, different levels of somewhat homomorphic encryption, which is actually more inefficient than peer? And let's say if we want to do that for polynomials of degree two polynomials. Because we saw in some of this talk, degree one computations with homomorphic encryption is easy. So what about degree two? And then also we want to have a better understanding of our semi-peer to peer reduction. So here we saw that we had adaptive codes. We were starting. And we saw that if we're going to have a non-adaptive reduction, we need to build this dream locally decodable codes. And then also this VC dimension measure that I mentioned, we want to see, like, if it can capture actually two-sided functionalities. It works very good with one-sided. Or if we do side it, we want to explore this even more. And what about multi-party functionalities? There are more problems, but I'm going to end here. Thank you.