 אוקיי, תודה, אבי. So in this talk, I will present a protocol for the specific case of three parties that is secure against malicious overloadry who controls minority of the parties. And this protocol achieves a high throughput. So in our setting, we have three parties who wish to compute jointly some functionality. And since we require an honest majority, it means that only one of the parties may be corrupted. Okay, and we assume that the functionality that we want to compute is represented by a Boolean circuit and we consider security with a boat, meaning that we achieve privacy and correctness. We don't guarantee fairness and we don't guarantee that there will be an output. The only thing we guarantee that is that if the parties did not abort during the computation, then the output is correct. Okay, so a few words about what we mean when we say we want to achieve high throughput security for party computation. So in general, we have two ways to measure the performance of a protocol. So the first way is to see how much time it takes to compute a single function. This is what we call the latency of a protocol. A different way is to see how many functions we can compute in a single unit of time. Let's say one second. This is what we call the throughput of the protocol. Now, these are not just ways to measure a protocol, but also different goals that are translated into different designs of protocol. So if we want to achieve, for example, low latency, then we usually, probably, we would like to have constant rounds of communication. And this will be done using what we call the global circuit approach when we send large amount of data in very few rounds. On the other hand, if we want to achieve high throughput, then we care less about the number of rounds, and we care more about low bandwidth and simple computations. Because even if the parties need to wait for messages to arrive, then meanwhile, they can start already the next computation. So when we want to achieve high throughput, we usually, we would like to pipeline the computations as much as we can. And in this case, we will use the secret sharing approach, which is what we will do in this case, in our protocol. So the starting point of our protocol is the semi-honest protocol from CCS 16, by Arakai, Furukawa, Lindel, Ohara, and myself, that is based on replicated secret sharing. And it has a very low communication. It requires only one bit of communication sent by each party per end gate. And when we implemented it, it achieved a throughput of over 7 billion end gates per second, which is translated into over a million A.S. operations per second. So this gives us a motivation to take this protocol and compile it into a maliciously secured protocol with low cost. So when we move from semi-honest to maliciously secured protocol, we ask basically three questions. So the first question is how do we force the corrupted party to share its inputs on the input wires correctly? The second question is how to verify that end gates, where we have interaction between the parties, are computed correctly. And the last question is how to verify that the values on the output wires are reconstructed correctly. So the first and the last questions are solved in a very standard way in our protocol. I will only focus from now on on the second question of how to verify that the end gates were computed correctly. So this also, this is what actually determines the throughput of the protocol. So this is the interesting question. So we follow the Beaver triple method as in many other protocols. So in Beaver, in this method, we consider multiplication triples, which is a triple of shares, A, B, and C, that are shared among the parties, such that C equals A times B. Now every time we compute an end gate, we also generate such a multiplication triple, where the X and Y are the shares on the input wires of the gate, and Z is the share of the output of this gate. Now, assume we have another random triple, or A, B, and C. So we have this protocol in our protocol called triple verification using another without opening that has the property that if we have a valid random triple, a correct random triple, then we can use it to verify a multiplication triple that was generated when computing end gates and detect cheating with probability one. Okay, so if the corrupted party cheated in an end gate, in a computation of an end gate, so if we have a valid random triple, we can detect it with probability one. And to implement this, and this sub-protocol requires, in our protocol, it has very low communication codes, cost only two bits per each party. So this already gives us a very simple online protocol to start with. So after sharing the input, the parties run the semi-honest protocol, and then they use the verification protocol that I just mentioned to verify all end gates computation. So, and then they reconstruct the output. So this, because the semi-honest protocol requires one bit of communication per party, and verification requires two bits of communication party, so we already have an online protocol that has a communication of only three bits per party. So the only question that remains, of course, is how we generate these random triples that are used in the verification step. So now we will focus on the preprocessing protocol or offline protocol that generates these triples. Okay, so how do we generate correct random multiplication triples? So in our protocol, we start by generating just random shares. So we generate, so we can generate random shares without any interaction. Okay, so we can, it requires no interaction between the parties, except to some set-up step of generating keys that are later used to generate, to using AES to generate as much random sharing as we want, and then we compute the sharing of C using the semi-honest protocol. So this requires only one bit of communication, and now the question remains, of course, is how to verify that this triple is valid, because we use the semi-honest protocol to generate it, so the corruptive party may cheat. So we use here the cut-and-choose method, or if you want the cut-and-choose and bucket method. So we start by generating a large amount of random multiplication triples using the semi-honest protocol. Since it is so cheap to generate them, we can generate a large amount of triples. And after we did that, we start, we continue with promoting randomly these triples. Now the key here is that, of course, the parties cannot know the actual permutation before they generated the initial list of triples. And then after we promoted the triples, we open, we sacrifice, we open C triples from this list. And when I say open, I mean that the actual values of these triples are being, are being revealed to the parties. And therefore if one of the open triples is incorrect, then the honest parties will detect it and abort. Okay, so this is the first test. If we pass this test, we continue by taking the remaining triples and split them into n buckets of equal size. In each bucket, we have beta triples. Okay, so the next step, now we have these buckets. And then we verify the first triple in each bucket using the other beta-1 triples. We do that using the verification sub-protocol, verification of one triple using another that I mentioned before. So we execute for each bucket this sub-protocol beta-1 times. And if we pass this test too, then we take the first triple in each bucket and output it, and this is the output of the preprocessing protocol. And now the property we have here is that if one of the buckets is mixed, meaning that it has both bad and good triples, then the honest parties will detect it with probability 1 and abort. Okay, so the only way the adversary can win can make the preprocessing protocol output an incorrect triple is by having a bucket that is fully bad, that contains only bad triples. Okay, so this is the process of cut and choose. Now, if you look at the communication cost of this process, so to generate the initial list of M random triples, we need M bits of communication per each party. Then we open C triples, so we need three bits for each opening, so we need three C bits. And then we run the sub-protocol of verification and beta minus time for N buckets, and it costs two bits of communication, so we have this communication cost. So overall, we get this formula for the communication cost, and obviously this depends on the values of beta, the size of the bucket, and C, the amount of triples that we open. So of course, as we increase these parameters, the probability that the adversary wins is smaller, but on the other hand, it increases also the cost of the protocol. So this protocol, so this process can be viewed as a communitarian game, where we have an adversary who chooses N beta plus C balls, where each ball can be better, good. A ball is, of course, a multiplication triple in our protocol, and then C balls are randomly chosen and opened, and if a bad ball was opened, then the adversary loses, and then the balls are randomly thrown into N buckets of size beta, and only if, and the adversary wins, if and only if all buckets are fully good or fully bad. Okay, and the goal is that given some statistical parameter, sigma, and number of triples, and number of triples that we want to generate, we want to find beta of C of minimal size, or minimal size because we want to minimize the communication cost, such that the probability that the adversary will win is smaller than 2 to the minus sigma. So this is the communitarian game, so we are not the first one to investigate this combinatorial game. It was already investigated in the tiny OT protocol. We present in our paper an improved combinatorial analysis, which is tighter. And just to, for an example, if we take, let's say we want to generate a million triples and equals million, and the statistical security parameter is 40, then according to their analysis, you need that the size of the bucket will be 4. We need only the size of the bucket in our analysis is only 3. We need to open much less triples, and therefore we need to generate much less triples to start with in the preprocessing protocol. So finally, if we use these exact parameters, we can see the whole protocol. So we have the preprocessing protocol where we start with generating n beta plus C triples, which, with these parameters, it's 3 million triples. We open only 3 triples, that's all. And then we split them into buckets, into million buckets, and use beta minus 1 triples to verify 1 triple, which means we need to, for each bucket, we need to run the verification sub-protocol exactly twice. And if we look at the overall communication, it costs 7 bits per n gates. So overall, with these parameters, we need exactly 10 bits per n gate sent per each party. So we started with the same minus protocol, which has a communication of 1 bit per party, and to achieve a malicious skew, we need to blow up the communication by a factor of 10. So just to show an efficiency comparison to a work from CCS 15 by Mossar, Roslick, and Zen, they presented the protocol in the same setting, with three parties and one corrupted party, one malicious corrupted party, that has the same communication of a semi-honest yaw. So it's a very efficient protocol, and as you can see, for each n gate, they need 85 bits, we need only 10, and we need much less AS computations per n gate. But of course, their protocol achieves a constant run, so it has its own justification. So we'll finish with telling you that we have a follow-up paper that will appear in IEH S&P, and in this paper, we managed to reduce the communication even further from 10 bits to 7 bits. This is achieved by better commutals that allow us to reduce the size of the bucket from 3 to 2. We also managed to reduce the computational work by replacing the random permutation that we have here in this protocol, so we call that we need to promote an array of 3 million triples, actually. So when you implement it, you have many cache misses, so we presented a way to shuffle the array that is cache-efficient, and it is not a random permutation, but even though it has, we can show commentarily that it achieves the same level of security. And when implementing it, so the basic limitation of the protocol that I just presented you achieves a throughput of 500 million gates per second, and after the optimization, we will manage to break the 1 billion gate barrier in the presence of a malicious adversary, which is much, much more than was known before. Of course, it's for a specific setting, but it still achieves a very high throughput, and that will be all, thank you very much. Plenty of time for questions. So I will ask one, how do you do the permutation for the preprocessing? Is that in the seven, that's counted in the seven n bits? So it's actually almost without any interaction, you start by generating random shells, which doesn't require any communication, and then you open it, and then this is a seed that you use that you use it to generate how many set randomness that you need. Basically, it's a constant cost. Okay. So the Oakland paper, does it actually, the title doesn't say three-party, does it actually extend to? So all the methods that we show there are generic, can be applied to any NPC protocol that uses this kind of cutting-chill method, but the implementation is, there is for this specification, the three-parties, but the methods there are definitely generic. So have you tried running for like five or seven or something like that? We didn't try that. The problem is that this protocol is based on a replicated secret sharing. So as we know, this kind of secret sharing grows, the size of the sharing, this sharing grows exponentially with the number of parties, but for five or seven, maybe it will still be efficient, but we didn't.