 Okay, cool. So this talk is very related to the previous talk, and it doesn't work with Ivan Damgar, Claudia Orlandy, and by me, Mark Zimkin. So we also look at the multi-party computation setting, and I'm not going to explain again what is multi-party computation, but there is like one point that I want to highlight is that, like, let's say we have three parties, and they run some protocol in their private inputs, and they obtain some output. Now, if you consider passive security, then kind of what we know is that all of the parties behave honestly, and if the protocol is passively secure, then they don't learn anything beyond what they, like, learn from their input and their output. And if we consider active security, like, when we think about what is the difference between the two, well, basically there could be a malicious party, and he could start sending messages which are, which do not follow the protocol specification. And from these messages, he could, for example, learn something about another party's input, or he could influence the output of the computation. So on a very, very abstract level, the only thing we need to do to go from passive security to active security is we need to prevent malicious parties from behaving maliciously or, like, from not following the protocol specification. And so this is what we do in this talk. Okay, so we have several contributions. So the first one is we show a generic way of taking any passively secure protocol and transforming it into an actively secure protocol for some slightly worse corruption threshold. And the nice thing about this compiler is that, so, first of all, it doesn't look at the specific way the semi-honestly secure protocol works. So, like, if you fulfill the security properties that we need, then you can plug it in and you get an actively secure protocol. The compiler is information theoretically secure, which means that if you plug in an information theoretically secure passive protocol, then you get an information theoretically secure, actively secure protocol. To kind of give a concrete example in the paper of a protocol that we can plug in there is we look at beaver circuit evaluation approach, which is very similar to what you've seen before. So this is, again, something where you compute on these additive secret shares and you add them locally and you need to multiply them with some correlated randomness. So we apply our compiler to the online phase and then we give a specific pre-processing phase, which we can then kind of use along with our compiler to get a full protocol kind of from start to end. And then the last thing that I'm not going to talk about in this talk in detail is we also provide a complete fairness compiler. So what does this compiler do? It takes an actively secure protocol, where active security, I mean active security with a board, which means that kind of the adversary gets to see the output and based on the output he can decide whether he wants to abort the protocol execution or not. And in complete fairness we have the case that the adversary doesn't see the output of the computation and he has to decide kind of blindly whether he aborts or not. So we show a compiler that takes a protocol that is actively secure with a board and the compiler makes the protocol actively secure with complete fairness. Okay, so let's start with the first question. Like how can we go from passive to active security in a black box manner? And again, like in a black box manner means we cannot look at the specifics of how the protocol works. We need to find some generic way. And there are two very simple main ideas. So let's say for the sake of this talk we focus on three parties and we want to have a protocol that is secure against one active corruption, okay? Three-party computation with one active corruption. So then there is a simple observation, which is well known, I guess. So if we take any pair of two parties and one of them is malicious, then the other one is honest. And the other thing that we do is instead of letting the real parties directly execute the semi-honestly secure protocol, we will kind of introduce one layer of indirection. So the real parties will kind of simulate some virtual parties and these virtual parties will execute the semi-honestly secure protocol. And the idea is kind of in the way the real parties simulate the virtual parties, we prevent an active adversary from misbehaving, okay? So let's look at the idea. So imagine we have three virtual parties, v1, v2, and v3. And we are given some semi-honestly secure protocol that tells us how we can compute some functionality. And these three virtual parties would like to run this protocol. So what this means is if the protocol says v1 sends a message to v2, then we kind of simulate this in some way. And if neither v1, v2, or v3 misbehave, if they all behave honestly, then kind of the semi-honestly security guarantees tell us that they learn nothing apart from the output and what they learn from their input. So how do we simulate? Well, we let kind of always two parties in this case simulate one virtual party. So for example, in this case, we have p2 and p-, the real parties p2 and p3 simulate the virtual party v1, okay? And then we do this kind of for all of them. And what you can already observe here is that every real party simulates two virtual parties, okay? So for example, we have the real party p2, it simulates v1, and it simulates the real party v3, okay? And what do they do to simulate? Let's for the moment assume that somehow the, for example, the real parties in v1, let's say p2 and p2, somehow they already agreed on an input and they already agreed on a random tape that they want to use for the computation. So if they have the same input, and if they have the same random tape and they run the same protocol, then they always, then they can always send the identical message. So what we then do is kind of let's say v1 should send a message to v3 and the protocol execution of the semi-honestly secret protocol, then we will let p2 and p3 send the message to each p1 and p2. So p1 in this case will receive a message from p2 and p3. And p2 will also receive a message from p2 and p3. Like, it doesn't make sense that p2 sends a message to p2, but like you get the point. So now that let's say p1 receives two messages and we know that we have, we want to be secure against one active corruption. So what does that mean? That means if the adversary misbehaved, then he will not be consistent with the other honest party. Because he can either behave honestly, then the two messages that the party receives are the same. Or if one party misbehaves, then the two messages receiving party receives are not the same. And in this case, the party can abort and it doesn't respond to a maliciously formed message. So this is the idea of the protocol. And this way, like we can see that in this case, we, for example, achieve security against one active corruption. And now the question is what do we need from the semi-honestly secure protocol in terms of security guarantees? Well, as I said before, like every real party participates in the simulation of two virtual parties. So now, basically, if I corrupt one real party, then I corrupt two virtual parties. So that means that the underlying semi-honestly secure protocol that I need, it needs to be secure against two semi-honestly secure corruptions. Okay. And this idea also generalizes. So for example, there is no reason why this needs to be three. So it can also be more than three. It can be like an end party protocol. And you can also increase the number of corruptions that you can handle. The main point here is that every virtual party contains one honest party. So that means that if all but one part, like if you have, let's say, five corruptions, if you want to be secure against five active corruptions, then every virtual party will be simulated by six parties, which means that if any of them or all of them misbehaved, there will be at least one same, like one honest party that sends the correct message. Okay. Cool. So there are two kind of small details that I glossed over. So the first one is I said they already agreed kind of on an input and a random tape that they will use. But obviously, like one party cannot just distribute their plain input. So we need to somehow take care of this. And the second thing is, what about the random tapes? So the random tapes, we either use coin tossing for so that kind of the group, like a group of a set of real parties to simulate a specific virtual party, they will basically run a coin tossing protocol to agree on a random tape that they will use. And then the inputs of the virtual parties, we take care of them as follows. So let's say I have again, the real parties P1, P2 and P3. And they would like to compute the function f of x, y, z where x, y and z are their actual inputs. But now we have the virtual parties. And what we now do is, well, we simply split. So for example, P1 simply splits his input x into three shares. And then he gives one share to every virtual party. So what does it mean by he gives a share to a virtual party? He sends it to all the real parties that simulate that virtual party. Now, as I said, like an active adversary would kind of corrupt two virtual parties. And this means that he's still missing one share to reconstruct the input. And all of the other people do that as well. And then instead of computing the original functionality, we compute a related functionality which first reconstructs the inputs, and then evaluates the function f on them. So apart from this being nice, what is this good for? So what we then looked at, we said, okay, let's take a specific protocol and see how efficient our compiler gets with this. So we've focused on the Beaver's circuit evaluation approach, which requires a pre-processing phase. So we design a pre-processing phase with active security. We apply our compiler to the online phase. And then we get an efficient 3PC overrings. So why is it interesting that it's overrings? I didn't mention that before. When we consider semi-honestly secure protocols, we can do them over many domains. We can do it over a field. We can do binary circuits. We can do rings. But as you have seen in the previous talks, it's quite challenging to get active security over a ring. For example, the approaches with Macs, you need to do a lot of trickery and magic to get there. But since the compiler doesn't use any kind of Macs, if you start with a semi-honestly secure protocol overrings, the actively secure protocol will work overrings just fine. Because the only thing you do is you send message redundantly. You don't need to exploit any kind of underlying structure over which you do the computations. So like this I will do very quick, because we've just seen it. So the Beaver's circuit evaluation approach, everybody additively secret shares his input. They evaluate the circuit gate by gate. And then they reconstruct the outputs. So for example, if you have an input X, for the case of three parties, it will be split into X1, X2, and X3. And one of the real players gets one of those. If they want to add them, they can do it locally. And if they want to multiply them, well, then they need multiplication triple. So now kind of the question is, how do we generate these multiplication triples efficiently overrings? And I will only give a very high level idea of the protocol to not get lost in the details. But kind of the main challenge is we can generate multiplication triples with semi-honor security very easily. And then how do we lift them to active security is we generate two multiplication triples which may be potentially incorrect. And then we sacrifice one of them to check the correctness of the other one. So if we generate two triples, we lose one of them. But we know that the other one is correct. And we don't learn anything about the secret shared values of those multiplication triples. The issue with this is that if we want to generate multiplication triples over a ring, then this check of sacrificing one triple to check the other one doesn't work directly over a ring. So what we do instead now, as we say, we will kind of first generate a triple over the integers. So that means we will generate a triple which is not a secret shared modulo sum number m. But instead, we will just throw a lot of noise onto it. So if you want to, for example, share a number in Zm, then we will expand this number with security parameter many bits of noise. And if you secret share something over the integers without any modular operation, then the parties can still not learn which value was secret shared, even though you didn't perform any modular arithmetic on these values. So the first step what we do is we secret share, we use the standard approaches of semiannously generating a multiplication triple over the integers with these noise things. In the second step, we generate a triple, a multiplication triple, again, semiannously secure over a field. And what we require is that the field is so large that the multiplication triple from Zm does not overflow. So we can embed the multiplication triple from Zm into the prime field without requiring to ever do a mod p operation. And then we interpret the triple over the integers as a triple in the field. And we sacrifice the original triple in the field that we generated to check the correctness of the triple over the integers. And why is this useful? Well, the whole point of this is that now we know that the triples are correct and we can simply reduce the triple over the integers modulo m to obtain a triple in Zm. Because if it's a valid multiplication triple over the integers, then it's a valid multiplication triple in Zm. So this is the idea. And so we are at the summary, which means I am way too fast. So to recall the results, we propose a compiler where you have an n-party protocol, which has, let's say, roughly a t-squared privacy guarantee. And then you can generate an actively secure protocol, which only is secure against t-active corruptions. And this compiler also works for adaptive corruptions, if you assume that the same as the secure protocol is also secure under adaptive corruptions. The second thing that we do is we show that you can transform an actively secure protocol that is actively secure with a board into a protocol that is actively secure with complete fairness. And then the last thing that I just gave a sketch of is we also propose this three-party, one actively secure for generating triples over a ring, and then compiling it with our compiler. We get a three-party computation over rings, which tolerate one act of corruptions. And where the computation overhead is very low, because all you do is you just send values redundantly. There is no heavy computation involved there. Questions?