 OK, the next talk will be Secure Computation on the Web, Computing Without Simultaneous Interaction by Shai Elevi, Yudhe Lindel, and Benny Pinkas. And Yudhe will be giving the talk. Good afternoon. I'm going to talk about Secure Computation on the Web, or Computing Without Simultaneous Interaction. And I'll start with my standard first slide for Secure Computation, unlike my predecessors, there's no cloud on it. But basically, what we talk about is a set of parties with private inputs, and they want to carry out some joint computation. Without revealing their inputs, they want to guarantee correctness. They want to guarantee independence of inputs and other properties. And these properties have to be ensured, even if some of the parties involved attack maliciously or in some other way. Semi-honestly, the protocol that's going on. And what we say, and this is what I want to focus on, is what we like to say, is that this models any problem, essentially, elections or auctions, private statistical analysis, and so on. So if it's an election we're talking about, then privacy means that my individual input won't be, my vote won't be learned. The correctness says that the candidate who gets the most amount of votes will be the one that actually wins, and so on and so forth. The question that we address in this paper is really whether Secure Computation does actually model these problems that we're trying to solve. So the real-world problem of online elections, auctions, statistical analysis of distributed parties data, for example, a website wants to carry out some statistical computation aggregation about the parties who visit the website. Does Secure Computation really model these problems? And I'm not talking about the problem of efficiency. So assuming that we can do things really, really efficiently, there's still a question as to actually whether we can solve these problems. And the reason is that in all known protocols for Secure Computation, all the parties interact simultaneously. So everybody has to come together and give their inputs at the same time. Now let's analyze some of these problems that we're talking about. Let's take a simple problem with a closed group of parties. Everyone knows who's there. It's not too many. We just want to carry out a vote for faculty members tenure. That's all we want to do. Since there's a lot of politics in our department, we want to make sure this is a secure protocol. And the problem is that if anybody's ever tried to schedule three faculty members in a meeting, you'll know that it takes about two months. So getting 40 faculty members, or however many you have in your department, together at the same time, even to go online at the same time when half of them are overseas or at different conferences, is actually a very, very big problem in practice if you want to run such a protocol. You need everyone to get online at the same time, and that's hard to do. It gets even worse if you want to talk about this application of a website that wants to somehow, I don't know, compute demographics, statistics of demographics of the parties who are coming to visit the website because each party comes, does whatever it does and goes. It's not going to hang around till another 5,000 parties get together and then run some joint protocol with parties that it has nothing to do with anyway. So this actually becomes a very, very big problem. Stated differently, this is the model that we're used to with secure computation. It doesn't have to be synchronous, but everyone's there and everyone's computing. However, the real world model is more like this. The party comes, does some computation and goes. A couple come, they go away. The only stable member here is the web server. Everyone else just comes and goes, and we want to somehow see if we can do secure computation in this sort of model as well. And the question is, can we make secure computation non-simultaneous? So can the parties come along and just visit once and go away and actually compute securely on their inputs? And this actually is an important theoretical question. It gives deepens our understanding of what communication is necessary for secure computation, for secure protocols, which is really a very, very important and basic primitive of cryptography in general. But it also has very important ramifications to practice because if we want to actually have secure computation be used in reality, then maybe actually one of the biggest obstacles to adoption is the fact that we need everyone there at the same time and that rarely happens. So this is important to practice, especially if it can be done efficiently and that we'll talk about a bit later on. I just want to know it because he sort of seemed to need to say that these days, fully homomorphic encryption doesn't solve the problem. You can think about it a bit and you'll see why because we just basically have to think of who owns the key. So our model is as follows, we have n parties p1 through pn and we have one server s. And each party interacts with the server once and exactly once. So you come, interact and go away and all of our protocols that I'll talk and one that I mentioned here, these interactions actually just retrieve something from the server and send it back. But as far as the model is concerned, we don't mind if you interact a few times, that doesn't matter. What is important is that you carry actual computation on your input and then go away. You don't have to speak to anyone else. You don't have to worry about when the other parties are going to be online. At the end, the server obtains the output. The reason why only the server is attending output is because only the server is there to get the output. Obviously if you wanted you could have the server post that and you could come back later to get it but you don't have to be there for the computation to take place. And we call a protocol for this setting one pass because all the parties just take, we just do one pass over all of the parties. Now this actually, if you think about what this model means, it means that we have to compute what we call residual functions. So since the protocol is one pass, it means that the last n minus i parties, p i plus one through p n and the server actually have to compute this residual function of the first i parties input. So parties, I don't know how you use the pointer on this thing like this, yeah. So the first i parties came and they gave their inputs and then the last n minus i parties have to give their inputs but whatever their inputs are, these ones are already fixed. So we can actually look at this residual function. Why is this important? Because it means that if these last n minus i parties and the server are all corrupted and colluding, then they can actually compute this residual function on many sets of final inputs. And this is inherent to the model. This is not something that our protocol doesn't achieve. Any protocol which works in this model, this one pass model, has to have this problem because the legitimate last n minus i parties and server have to be able to compute on any set of their inputs. In particular, they can do this many times but it's only, again, I wanna stress if both the server and these last n minus i parties are colluding, this could be one, two, three, four, depending on what's the corruption setting we have. So this leads us also to talk about something called function decomposition. So decomposition of a function is just really a series of n two input functions which is a series computing the final function. So you first compute f1 on the first input, then f2 on that result on the second input and so on and so forth. In the end, you get the final output. And in the one pass setting, it's again inherent to the model what's actually happening. Pi and the server s, if they're interacting are actually computing the i-th function fi in this decomposition series. And also what that means is that if the last n minus i parties and the server are all corrupted and colluding, then what they're learning is the output of that i-th function in the decomposition. Function decomposition and these residual functions are inherent to this one pass model. The question we have to ask ourselves if it's inherent to the model, then what does it reveal if these last n minus i parties and the server are corrupted? Then what are they actually going to learn? And what we're going to say, what we define in the paper is that if this output of the i-th function reveals nothing more than that what the residual function gives, then we call it minimal disclosure. And that's because as we said the residual function is inherent to the model. And so we would like, if we have a decomposition that reveals only that, then that's the best that you can do. And so that's okay. Well, of course it depends on the application. Let's just look at a couple of examples. You can be stupid and define your residual function, your decomposition this way that they're just identity functions. So f one of x one gives you x one, f two gives you just the outputs of that, the inputs and you essentially have all of the first n minus one functions giving you the identity functions and the last one will compute it. So this just tells you that everything can be decomposed, but of course it's not interesting because if the last party and the server are both corrupted, then that's all you need and they get absolutely everything. So this is a very undesirable and stupid design. In contrast, let's look at this decomposition for the sum function. It's just the partial sums until the i-th input. Now it's clear that if you're given the output of the i-th function, you can get the sum of the first i, but that's all that you're getting. And indeed this is minimal disclosure because you could get that anyway by just having your, by knowing your inputs and even the standard setting of secure computation, any n minus i colluding parties can learn this information. So this is completely minimal disclosure and what you can actually say is that all that is revealed by the i-th function in decomposition is what would be the output if only those parties were computing. So this is optimal and sufficient for many applications. So we define security by in the standard way of secure computation, the ideal real paradigm I won't go into it, it'll be discussed more tomorrow morning, I think, but all I wanna stress is that in addition to what an adversary can usually do in the secure computation model, we allow it to get the output of the i-th function in decomposition, but only if both the server and the n minus i last party is corrupted. If the server is honest, it gets absolutely nothing, just the standard definition of secure computation and if the server is corrupted, then it just depends who the last party who came in the series in this one past series is corrupted and we call a protocol optimally private if it computes the decomposition, a decomposition that's a minimal disclosure. So I just wanna stress one thing about the security definition, it talks about securely computing a decomposition. So whatever decomposition you have for your function, the protocol should then compute to that level of leakage which is modeled by the decomposition itself. You'd like optimally private, you don't always have. The main question I wanna deal with the rest of my time is, can this notion be achieved if yes under what assumptions and at what cost? Cause it sounds like something which is quite difficult. And in fact, at least to my surprise, we can do this really, really efficiently for a number of very interesting problems. Let's talk, we'll talk in this talk, focus on binary symmetric functions. These are functions with binary inputs zero one and but the output depends only on the hamming weights. So if you think about and or parity or majority which is again voting for tenure for our faculty member, then all we care about is how many people voted yes and how many people voted no, we don't care what the order of that is. So these functions, binary symmetric functions have a very concise truth table representation. So instead of a for n inputs having a truth table size two to the n, you actually have a truth table of size n plus one. Why is that? Because you just look at the hamming weight and for each possible hamming weight you write each possible out, you write the output and because there are only n bits for input there are n plus one possible hamming weights and the function only depends on the hamming weight. So this is a complete description of the function. And this is the majority function. You can see if up to two parties only have one then the output is zero and otherwise the output is one. So now I need to describe to you this decomposition into functions and then I'll show you how we can use that. So we're gonna define y one which is the f one of x one to be this complete truth table but we're going to erase the first row if the first input is one and the last row if it's zero. So let's see that if the first party if the party has the input one then we know that the hamming weight of the function cannot, the hamming weight of the output cannot be zero of all the inputs sorry cannot be zero because we already have a hamming weight of one given by this bit so we erase this row. On the other hand if the first party's input is zero then we erase the last row because again it means that the hamming weight of all the inputs cannot be five because we already have one zero. The second function is defined similarly we take the truncated truth table which we already got and now we just erase the first or last row depending on the party's input. So if the input is one then again we know we can't get the first row that's remaining so we erase it. The third party if it has one then we again erase the first row. The fourth party has zero so it's the last row the last party has zero so that's the again the last row each one just relates to the first or last row of the remaining table. And note the magic that indeed the majority of zero one one zero zero is zero which is the only remaining row in the truth table. I just wanna stress that we're not actually giving the hamming weight that would be too much we're only looking at this. So this is just erasing the first or last values of this table which is the second column. So that says nothing about cryptography about decomposition this is just a decomposition away of dividing a function into a series of two part of two input functions along the way. This is actually a minimum disclosure because the truth table at any given point only shows only tells you the it only enables you to compute on compute the residual function. Essentially it's there's nothing more disclosed than the aggregate of what was beforehand or in other words what you could compute given your residual inputs. Now I wanna show how to actually compute this very very efficiently. The main tool is layer re-randomizable encryption so you can think about you have a number of keys and you encrypt the input under many many keys and different randomness each party using different randomness and we call it layer re-randomizable if you can actually just re-randomize all of the random values in this sort of onion encrypted cipher text and I just wanna say that you can do this with El Gamal really really efficiently it's the cost of a single encryption you can do crypt threshold wise you can re-randomize very very efficiently so this is actually not difficult to do. And I just wanna note that all our protocols assume a PKI it's essential for the model but you can see the paper for more details. In the semi-honest model our protocol works as follows. The server starts by encrypting the entire truth table under all the party's keys and uses re-randomizable layer encryption. Then each party again it's a one pass protocol so each party comes talks to the server and goes away so each party comes takes the truth table that remains from the server and erases either first or last row depending on what its input is which already showed how that works but you can do the oblivious you don't have to know what was already done beforehand and that's the beauty of the decomposition. So I just get back what's remaining of the truth table erase the first or the last row now I peel off my secret key so I decrypt under my secret key and re-randomize everything that's there. At the end all that remains is a single row which is encrypted under the server's public key and the server then decrypts that and gets the results. So let's just look at that graphically here's our table what it means is the server encrypts this table or the value 000111 under the six public keys five public keys of the parties who are participating and its own public key is the sixth one. The first party gets this truth table all encrypted and has input of zero so it erases the last row the last element last ciphertexts then it removes its key and re-randomizes so you can see now that it's the public keys from two to six rather than from one to six the second party has input one it erases the first row again now removes its key so now we go from pk3 to six and re-randomizes and we continue p3 again erases the first input because it had x3 equals one removes the key re-randomizes p4 has zero so it erases the last and we're left now with these two values encrypted under pk5 and pk6 and what this means is if the fifth party is corrupted and colluding with the server then they're able to actually get these two values but all that means is that they know that the first four parties were evenly divided they don't know anything else beyond that and in fact they would even know this if it was a regular secure computation scenario so this is actually optimal and nothing is lost in at least most applications or anything that I can think of. The security of this protocol is that follows from the fact that if the server is honest then no one learns anything because everything the entire time is encrypted under the server's public key but even if the server is corrupted as long as the truth table is encrypted under at least one of the honest party's keys nothing is learned and the re-randomization prevents from making any connections between what was erased the first or the last row along the way and so that the means is until the last honest party comes nothing is learned once the last honest party has come and the remaining parties are all corrupted then as we said this is inherent to the model that they can then see what remains but that's as if we just computed on the subset of parties which is actually okay. The concrete cost of this is three and over two exponentiation for n parties and since we can do even probably 3,000 exponentiation per second if we have good software then this can be practical even for thousands of users the only problem can be 500 come at the same time they actually have to wait for each other but at least for many of our real scenarios like the tenure of votes or others this is definitely practical. For malicious adversaries and I won't go into exactly how we can actually also do this efficiently using the Fiat-Chemir paradigm to help us get really efficient zero-knowledge proofs and our estimate is that for about 40 parties you take 10 seconds computation per party so this is really something which is practical and can be used for something like voting that we talked about and in the paper we actually have highly efficient protocols for other problems as well and in addition important results since we're studying this also from a theoretical point of view is that we prove that in fact any decomposition can be securely computed under in this one pass model and that's an important general feasibility result saying that this one pass model actually has a lot of applicability and this is our result is under the DDH assumption and if you need and for a malicious adversary you also need non-interactive zero-knowledge and this works for any decomposition so if it's minimal disclosure then that's the best you can get that but otherwise it depends on the application whether your decomposition is good enough and that's part of your design-free application so in summary fully interactive secure computation is actually a problem in practice and in many cases we need what we call a one pass client server protocol in addition to this being of interest from a practical perspective it's also interesting from a theoretical point of view to understand what communication is needed for secure computation we introduced this model and define security for it we also studied inherent limitations and we used and introduced this notion of function decomposition and residual computation and minimal disclosure in order to understand this and then we constructed highly efficient protocols for this setting and showed that for many natural problems actually we have we can really do this in practice and we also proved a general feasibility result showing that we can solve any protocol problem at least within the inherent limitations of the model thank you and fortunately again we don't have time for questions