 Okay, so hello everyone, thank you Mike for the introduction, so in this work, we consider the setting where n parties wish to compute some functionality which is represented by an arithmetic circuit over some finite field F in the presence of a malicious adversary who control less than half of the parties. Our security model is security with a board which means that the adversary may receive its output while preventing the honest parties from receiving their output. Although in the honest majority setting full security can be achieved since we want to achieve high efficiency, we consider only this slightly weaker notion of security but very reasonable for many applications. So this is the setting and the starting point of our protocol is two very simple observations. So the first observation made by Gengen et al in a series of works is that protocols that are many semi honest protocols that are based on secret sharing are actually not that weak. They are actually secure up to additive attack even in the presence of malicious adversaries which means that the only thing that the adversary can do is to add some value to the output but nothing beyond that. Even if it's a malicious adversary and the protocol that is being logged is secure only against semi honest. And this was used in their work to construct circuits that are resilient to additive attack. The second observation is that in the honest majority setting which is our setting there exists many highly efficient semi honest protocol which very low computation cost and with communication that grows only linear with the number of parties. So using this observation and following the work of Gengen et al, we present in this work a new protocol which is maliciously secured with a boat which for large field requires the parties to run a semi honest protocol exactly twice. And when I say large field I mean that the size of the field divided by three is larger than two to the security parameter. If we work over a smaller field then we would have to run the semi honest protocol delta times where delta is such that this inequality is satisfied. And we present in our work two instantiations to a protocol. The first one is for the specific case of three party computation where we use replicated secret sharing and we present a protocol based on our construction where each party is required to send just two field at a time. So this is a big concrete improvement. And the second is for any number of parties which is based on Shamil secret sharing where we present a protocol where each party is required to send just 12 field elements per multiplication gate. The previous best result was I think 42 if I remember correctly field elements per multiplication gate so this is a big concrete improvement. And later we'll also show some experimental results and some running times. So this of course is for large field if we work over small field then the communication grows linear with the delta parameter. So this is our main results and now let's go into the details. But before we proceed to some notation so we use the standard notation for a sharing of a value X. We assume that the secret sharing scheme that is being used has linear property and therefore only for multiplication gates there is interaction between the parties. F mult is our functionality that captures the idea of security after additive attack which can be realized as I just said by many semi honest multiplication protocols. And the front is functionality to generate random sharing and also here the way to realize it depends on the secret sharing scheme that is being used in the protocol. So these are our building box and let's go into the details. So we have this functionality F mult which is secure after additive attack which means that the only thing that they can do is to add some value to the output. Now achieving malicious security with a board when we use F mult eventually reduces the one basic question which is how can the parties in the tech when cheating took place and the value that was added to the output is not zero. So this is basically the question that we need to ask and now let's see how we answer this. So the main idea is as follows. So we start by generate some random sharing, some global random sharing R by calling our functionality F front. And then for each wire of the circuit we have this invariant where the parties hold a pair of sharing on each wire. A sharing of the actual value that is on the wire and a randomized sharing of this value. This random sharing can be also viewed as a Mac of the value which is exactly what Daniel mentioned in the first talk. Exactly the same Mac that is used in speed, mascot and all these family of protocols. So the idea is that to maintain this invariant so in order to achieve this the parties start by randomizing the input wires of the circuit by taking each sharing on the input wire and multiply it with the global random sharing R by calling F mult. And then the parties go over the circuit in topological order and maintain this invariant. So for addition gates the party can just locally add their shares, but for multiplication gates the parties need to interact. This is done as follows. So on each input wire of each multiplication gate we have a pair of sharings. So the party is called F mult twice. The first time they call F mult to multiply the sharings of the actual values that are on the wires. And the second time, so by this they have the sharing of the output. And then they call F mult yet again in order to multiply the randomized sharing on the left input wire and the sharing of the actual value on the right input wire. And by this they have, and this is how they obtain the randomized sharing on the output. But of course F mult is not fully secure, right? It is secure after additive attack and the adversary may cheat in this computation. But what we can use, what we will see in a moment that we can use the randomized sharing in order to verify the correctness of the sharing of the actual value. We will use the sharing of RZ in order to verify the correctness of Z. And this is done as follows. So the parties can take the sharing of Z, the sharing of the actual value on the wire and call F mult yet again to multiply it with the random sharing R. And then we have another randomized sharing of this value that was computed in a different way. Now the parties call this checking equality support protocol that we have. And check that the two randomized sharing that they have are the sharing of the same value. And the probability that we have is that if cheating took place, then since R is unknown and since we use F part, which is secure after this attack, we can show that the probability that the equality holds and the honest parties don't abort if cheating took place is negligible. So this is the Mayan D, but we actually can optimize it a little bit more and use the standard trick of batch checking. Instead of checking each multiplication gate separately, so at the moment we have three calls to F mult for each multiplication gate, we can get rid of the last call to F mult for verification. So what we can do is instead, what we can do is to take the linear combination of the sharing of the value on each wire, by first the parties do some coin tossing and obtain these alpha i's here, which are public random values, and then they can locally compute this value, this linear combination, and then call F mult once to multiply it with the random sharing R. By obtaining this value. Then they can take the linear combination of the randomized sharing on each value, and then call the checking equality protocol exactly once for the entire protocol. So now instead of having verification for each multiplication gate separately, we have one verification for the entire circuit. And the property that we have is that if cheating took place, then the only parties about it were ability one minus three over the size of the field. So if the field is large, then three over the size of the field is negligible. However, this is the cheating property is indeed negligible, however this optimization causes a security problem. And the security problem is caused by the fact that this last call to F mult, this one call that we do to F mult in the verification step, is done after the random coefficients, these alpha i's were chosen. And what we show in the paper is that in this one call to F mult, the adversary can carry out an attack which allows him to learn some information about internal values from the fact that the only parties are both or not. So what we need here is that this random coefficient, these alpha i's, will be chosen only after all the calls to F mult have been concluded. This is achieved, this is solved by doing the following. So now after we computed the circuit and we have two pairs of sharing on each wire of the circuit, now we can open R and reveal its value to the parties. And then we can compute here in step two, we can do local computation and proceed with the quality checking as before. Okay, so now here in step two, all to compute local computation after the parties no alpha i and no R, and therefore we don't need to call F mult even once in the verification step. And therefore now it is fully optimized and secure and we have the same property as before that the cheating probability is negligible. And as you can see, we have eventually, we end up with a protocol where we need to call F mult exactly twice for each multiplication gate. As you can see here, one for the real circuit gate and one to compute the randomized sharing. Okay, so this is what we've seen now is correct for large fields. What happened when we moved to, when we work over smaller fields? So the straightforward extension of our AD to small fields would be that instead of randomizing the value once, we can now randomize it multiple times. So instead of holding two pairs of sharing on each wire, now we will hold a couple of delta plus one sharing on each wire. Each randomization is with a different independent R. Okay, now when we want to maintain this invariant, so when we compute multiplication gates, instead of calling F mult twice, we will call it delta plus one time once for the multiplication of the sharing of the actual values and delta more times in order to obtain the randomized sharing on the output wire. And then we can run the verification step for each randomization separately. And since all the randomization are independent of each other, we have that the cheating mobility for each verification step is three over the service of the field, and overall the cheating mobility is three over the service of the field to delta. And then delta can be chosen in order to achieve a certain desired level of security. However, when this, although intuitively this looks correct, when trying to prove this, the proof fails. And I want to expand very briefly why. So if we look at our verification procedure, we can see that eventually everything almost is known in this verification step. R is revealed to the party, it is known to all the party, to the adversary, to the real world adversary, to the ideal world simulator, alpha i is known. The only thing that is not known is the value of the z i, the actual values that are on the wires. However, these values are known to the distinguisher. So the distinguisher knows exactly whether the equality that we check will hold or not. And it knows exactly if the honest party should abort or not. Now, the simulator doesn't know that. So before we could say that, okay, so the simulation failed, but this happens with negligible probability because three over the service of the field is negligible. But now three over the service of the field is not negligible anymore, so we cannot say, and we cannot say that the simulation failed with non-negligible probabilities. So the proof fails when we move to small fields and we need to change something in our verification step in order for this to work. And the idea is that we need to keep something else secret in the verification step, so even the distinguisher won't know if the honest party should abort or not. And what we do here is that instead of doing coins we'll do some coin tossing to obtain the random public alpha i's, we will now call f run to receive random sharings of these alpha i's. So alpha i's are kept secret now throughout the verification step. However, this looks from first glance like not such a good idea, right? Because now when we compute step three and in step four, we have here multiplication between shared values. Each time we want to multiply alpha i and z i, now alpha i is a shared value, so we need to call f mult each time we need to do that. So it looks like we need two more calls to f mult for each multiplication gate. So this doubles the cost of the protocol. But fortunately, we have a way to overcome this problem. And what I will show now is how we can compute this sum of products of shares at the cost of one multiplication, at the cost of running one multiplication protocol. Okay, so, and I will show it by an example, but using this example, you can see the idea and this can be applied to many other cases. So let's assume, for example, that we work with Shamir's secret sharing. So we want to compute this sum of products of shared values. So in Shamir's secret sharing, each sharing is points over a polynomial of Degree T. Now, if we work in an IV way, so we will look at each of the values that we want to, each two values that we want to multiply and then run a multiplication protocol for each of them separately. Usually multiplication protocols for Shamir's secret sharing work as follows. So the parties start by locally multiplying their shares and then they hold a correct sharing of the result, but the problem is that this is a sharing using a polynomial of Degree 2T and not a Degree T. So what the parties do is run some interactive protocol, which is eventually the main cost of the entire multiplication protocol, where they do Degree Reduction, and then they have a correct sharing of the result with the correct degree. And then they can sum all the results they have and obtain a sharing of the sum of products. Now, the very simple, but very powerful idea is that we can reverse the order here. Now we can start with the same way. Each party locally multiplies their shares, but now let's sum the results now before we do the Degree Reduction. And now we will have a correct sharing of the sum of products, but with Degree 2T, and then we can run the interactive protocol for Degree Reduction only once for the entire sum of products. So this is very simple, but very powerful. And by doing this, we can see that we can compute the sum of products of shares. It doesn't matter how many shares we have here at the cost of, eventually, at the cost of one single multiplication, because eventually the interactive protocol is the main bottleneck of all the multiplication protocol. So if we go back to this idea, I presented it using Shamu Secretaring, but this can be easily applied to many other Secretaring schemes that work in the very same way. So going back to our multiplication step, now we can see that we can compute these sum of products, the sum of products here, and the sum of products here, we can compute it at the cost of one single call to Fmult, the cost of one single execution of our semi-honest multiplication protocol. So eventually when we amortize it over the entire circuit, this is eventually nothing, and we are left with the same cost as before of two calls to Fmult for each multiplication gate. There's one little thing here that we need to call Frun, because we have alpha for each multiplication gate, so we need one call to Frun, but this is not too bad. Eventually we don't need to call Fmult more times for each multiplication gate. So this is the idea for, this is the verification step when we work over small fields. Another small advantage that this verification procedure has is that now we can, before we had to open R, because we had some security problem, now because alpha is kept secret, we don't have this problem anymore, so we can keep R also as a secret. This has advantage when we, for example, a computer reactive functionality or some ongoing computation when we release outputs and continue with the computation. We open R, we will have to re-randomize all the values of the circuit each time we release an output. If R is kept secret, we don't need to do that, so there is a small advantage if we don't open R. So to sum up what we've seen till now, so we've seen two protocols, one that is suited for large fields, where the amortar scores per multiplication gate is 2 calls to Fmult, and a protocol that can work also for small fields where the amortar scores per multiplication gate is 1 plus delta calls to Fmult, and delta calls to Frand. If we, of course, work on large fields with this protocol, delta is just equals 1, so it is almost the same as the first protocol. So these are our two protocols, our two constructions in our paper, and now I will finish with showing some experimental results. So as I said at the beginning, we have two instantiations in our protocol, one for three parties using replicated secret sharing and one for any number of parties using Shamir secret sharing. And here in this table, you can see the way we instantiate each of the building blocks of our protocol for each of these secret sharing schemes. So for example, if you Shamir secret sharing, so we have a protocol which realizes Fmult, which is basically secure after additive attack, which requires each party to send six elements per gate. The way we realize Frand, our protocol to generate random sharing, requires each party to send two field elements per gate. So two field elements per gate running for execution of Frand. So this is our building blocks for each of these secret sharing schemes. And we examined our protocol by running a very loud circuit of one million multiplication gates with different depths. You can see them here from 20 depths up to 10,000 layers. And here you can see we're running two different number of parties from three up to 110, and the execution time is in milliseconds. So we'll highlight two results. As you can see, we can compute one million gates with depth 20, and three parties in only 390 milliseconds. And we can compute 110 parties can compute one million gates in just about 8.2 seconds. So our protocol performs very well. This is these results are when the parties are in the same region. What happened when we moved to one configuration? So here the parties are in three different regions, which are very far away in the world, and here we run only two circuit depths and up to 50 parties. Obviously here the time is increased by much, because obviously these kind of protocols that are based on secret sharing requires many rounds of communication. So obviously it's when the parties are not closely located, obviously this performs this is not as good as before. As you can see now three parties can compute one million gates in three seconds, not before it was 300 milliseconds and 50 parties can compute one million gates in 128 seconds before it was 4 or 5 seconds 450 parties. But eventually as you can see our protocol can perform very well and can be used to solve real world applications. With that I will conclude my talk. Thank you very much.