 asset to active security via secure SMID circuits. The authors are Daniel Genkin, Yuval Ishai, and Antigone Policron Niadu. And Daniel will be giving the talk. Okay, so thanks for the introduction. My name is Daniel Genkin, and the title of my talk is Efficient Multiparty Computation from Passive to Active Security via Secure SMD Circuits. And this is joint work with Yuval Ishai and Antigone Policron Niadu. Okay, so MPC, as we already heard in this session, allows a set of mutually distressing parties to compute a function of their inputs without violating the privacy of the inputs. Now, typically we distinguish between two types of adversaries, a passive adversary which tries to learn additional information by just looking at the protocol communication and an active adversary which might send arbitrary junk to the protocol in order to gain some more information. Now, in the literature there is a variety of techniques on how one would obtain protocols which are actively secure. And this is, we have generic compilers, we can use BGW and CCD style protocols. We have cut and choose techniques, we can use low threshold protocols and MPC and the head techniques. But what all of this has in common is that the overhead that they require is quite considerable, and this is both asymptotic and concrete. Now, recently a new paradigm was proposed and the main observation is that for many natural passively secure protocols, the effect of any active adversary attacking a protocol is equivalent to an additive attack on the circuit that the parties are trying to evaluate. So what's an additive attack? So here we have a circuit, and an additive attack is allowing an adversary, this monster here, to pick arbitrary constants to add on to wire values inside the circuit. Now, the crucial observation is that these values are selected before the adversary knows what values will be on the circuit. So this additive attack, for example, this constant five modifies this wire by whatever is going out from the output of this multiplication gate. Five is being added to it before it enters this abstraction gate. So with this methodology, what we proved in our previous work is that indeed, for many natural protocols, whatever an active adversary can do to a passively secure protocol can be simulated by an additive attack on the underlying circuit. So that was this bad evil monster is replaced by this arguably cuter guy here. So now, by replacing this circuit with a circuit that actually resists additive attacks, we were able to construct actively secure PC. So one example of an application of the previous work is a very nice protocol in the onus majority setting by Dumbled Nielsen. And the nice thing about this protocol is that the leading term in the communication complexity depends linearly both on the circuit size and of the number of parties participating in the protocol. Compiling this protocol using the previous compiler, we were able to achieve an actively secure protocol with the exact same communication complexity. So this is nice. However, the best protocols, the best passively secure protocols use what's called pack secret sharing. So by using pack secret sharing, we can sacrifice 1% of the security threshold so we no longer have this point, point five here. We have a bit less. But in return, what we gain is a protocol where the leading term in the communication complexity only depends on the size of the circuit being evaluated and not on the number of parties participating in the protocol. Now, when we take those protocols and we try to compile them using the previous compiler, we immediately hit a problem. So let me first recap on what pack secret sharing is, and then I'll try to illustrate the problem. So standard secret sharing is if we want to share one secret, we put it in the zeroes point of a low degree polynomial. And then the parties hold evaluation of this random low degree polynomial in specific evaluation points. We can generalize this by sharing many secrets using a single sharing. And this is done by simply adding more secrets to various locations in the polynomial and still the parties hold an evaluation of this random low degree polynomial at various evaluation points. So most Shamir-based NPC protocols actually naturally generalize to this setting of pack secret sharing, but we need to slightly modify the underlying circuit model. So what do I mean by that? Standard NPC protocols operate over arithmetic circuits. And in arithmetic circuits, we have gates, multiplication and addition. Each gate typically gets two inputs and produces a single output. Pack secret sharing protocols operate on what we call SMD circuits. And in SMD circuit, we still have two types of gates. And each gate still gets two inputs, but these are now wire bundles. So here's an example for wire bundles that contain three elements. And operations are done point-wise on these wire bundles, point-wise addition and point-wise multiplication. We also sometimes allow for an additional type of gate, which only gets one input bundle. And what it does is it rearranges the values inside the bundle. So this is the way, so we have SMD circuit evaluates many copies of itself on different data. Here is how we share information between different copies. So let's see what happens when we take a protocol which is based on pack secret sharing and try to introduce an active adversary. So here's a toy example of a protocol. We have two input bundles, A and B. The way that those protocols work is they secret share those into two sets of shares, B and A. So here we have A, I, and B, I. Multiplication is done point-wise. So now we have C, I, which is A, I times B, I. And output recovery is a linear function. So by taking some linear combination of those shares, we get back the output block, which is indeed A point-wise multiplication, B. So this is nice. This is a toy example of a protocol. Let's see how this holds when I introduce an active adversary. So here's an active adversary. And this guy decided to add those constants delta 1 to delta n to the shares of B. We still take, during the protocol, a point-wise multiplication. So now those deltas multiply A's. And the result going through the linear function is basically that the adversary can make the output bundle add to it any linear functions of the shares of A. Now, since this is a linear secret sharing scheme, any linear functions of the shares of A means any linear functions of the secrets encoded in the A block. In particular, the linear function which somehow permutes those secrets. So it is no longer true. So the techniques of the previous compiler do not capture protocols which are based on pact secret sharing. And this is inherent because the main underlying assumption that any active adversary can be simulated by an additive attack is no longer true. The true statement for SMB circuits is what we call linear attacks and I'll show them later. The other problem is that the critical reduction between active adversaries and additive attacks is done ad hocly per protocol. So what that means is that if we were to try to add a new protocol and we basically have to start from scratch and improve all the relevant theorems. So coming up to our contributions, what we extend the treatment to protocol that use pact secret sharing and evaluate SMB circuits. And the main observation is that for such protocols, any active adversary can be modeled as a linear attack on the underlying circuit. So what's a linear attack? Here we have a multiplication SMD gate. It gates to input bundles and performs a point-wise product. A linear attack is allowing the adversary to add to this output bundle any linear function of the input bundles. And now the corrupted gate still computes a point-wise product B but adds a linear function of A and B. So the crucial observation is we only allow those attacks for multiplication gates and not on any other gate, but this suffices for our MPC applications. So the way that we actually go ahead and prove this main observation is that we provide a modular framework where one can go and reduce an active adversary to a linear attack on the underlying circuit. With this framework, we basically reprove the results of the previous work as well as apply it to protocols which are based on pact secret sharing for evaluating SMD circuits. Now, with this observation in hand, we actually go ahead and construct those SMD circuits which resist linear attacks and the blow-up in circuit size is linear in the original circuit and actually the constant here which is hiding inside this O is quite small. So coming up to applications, we basically close the gap in efficiency between protocols between passive and active security for protocols which are based on pact secret sharing. So to give you two examples, there is a protocol in the literature that if you want to evaluate many copies of the same arithmetic circuit, you can do it in time which is O of C plus N and this is amortized time per copy that you're evaluating. Compiling this protocol using our compiler, we get an active protocol with the exact same communication complex. The next application is that if you, let's say you want to evaluate a single circuit as fast as you can. So there is a protocol by Dungard et al that will do it in time where the leading term does not depend on the number of parties that participate in the protocol. Again, compiling this using our compiler, we get the exact same communication complexity but against active security. Okay, so let me illustrate this last point a bit more concretely. We basically improve compared to what previously known the parallel overhead of the protocol from being O of N squared to O of N. So when is this useful? Consider a circuit which is very deep whose depth is roughly its size. This is true for a lot of circuits. For example, exponentiation is like this. Previous protocols had this term here which is quadratic in the number of parties when it comes to depth. And if depth is roughly size, this means that previous protocols were quadratic in the size. Our protocol is linear in the size. So for deep circuits, we significantly improve complexity. Another nice feature is that we nearly achieve near-optim, natively achieve near-optim security threshold. This is T less than 0.49 N without using expensive security application techniques such as BRCA committees. So this just improves concrete efficiency. Okay, so for the technical part of the talk, I'm gonna focus on, mostly focus on our framework and I'm gonna show you how it works and what you need to do in order to apply it on your favorite protocol. So the claim that we are trying to prove is that whatever an active adversary controlling the set of corrupted parties T can achieve interacting with a passively secure protocol can be simulated by a linear attack on the circuit that the parties are trying to evaluate. So our framework consists of three steps. The first is what we call T randomization. It's basically a way to take a protocol and canonicalize it into a form which we can work with. We then prove that if you have an active adversary attacking this canonical protocol, whatever it can do is an additive attack but not on the circuit that the parties are evaluating but on the circuit representation of the protocol. So what's a circuit representation of an MPC protocol? Take the protocol as specified by the code and write it out as an arithmetic circuit. So whatever the adversary can do against the protocol, it can be simulated as an additive attack on the protocol circuit representation. We then have the last step where we transfer an additive attack on the protocol's circuit representation to a linear attack on the actual circuit that the parties evaluate. Now once we have completed those three steps, all that one really needs to do in order to obtain an actively secure protocol is basically take the circuit that you would like to evaluate, compile it into a secure circuit and then use your original passively secure protocol but not on the circuit you started with but on the secure circuit. This will give you active security. Okay, so the first thing we need to do since we have a few steps here is to write out this equation a bit more expanded and now let me go over step by step. So the first step is what we call t-rendomization. T-rendomization syntactically requires that the messages M from T bar, the onus parties to T, the corrupted parties only syntactically depend on the randomness of the protocol and not on the input of the onus parties. So a protocol is t-rendomized if it has this feature and this is of course accept during the last round because if you send only randomness to the corrupted parties you just cannot compute the function. There is no correlation with your input. So let me give you an example of a bad protocol which is not randomized. So in many cases for MPC protocols we need to compute an additive secret sharing of the input of the parties. The way that we do it is we generate a bunch of shares at random and we then set the last share to be the XOR of the input and of the randomness. And the reason why this protocol is bad for us is because this last share which syntactically depends both on the input and the randomness is happened to be given to a corrupted party. So this what makes this protocol non-randomized and the way that we go ahead and fix it is basically by flipping the secret sharing and first generating the shares for the corrupted parties completely at random and then making sure that the share which is actually, that the sensitive share which depends on the input is given to an honest party. So this is a toy example of how would one go ahead and randomize the protocol. The reason you can go ahead and actually do it is because T, the corrupted parties were fixed way in advance. So you know which parties will be corrupted so you can go ahead and do these flippings. It's actually a bit more complicated than this. I'm hiding some details here but this is a rough idea of what needs to be done. So you need to design those T randomized protocols, Pi T, and then this needs to be done while maintaining T equivalence. And what T equivalence means is that whatever the adversary can achieve by attacking the protocol Pi, he can also achieve by attacking the protocol Pi T. And this is our first step. The second step actually will happen automatically and what I claim is that any active adversary attacking this randomized protocol Pi T is equivalent to an additive attack on the circuit representation of Pi T, namely C Pi T. So why is this true? So let me actually give you the simulator. So here's how a randomized protocol looks like. And we have here the set of honest parties and since the protocol is randomized, all that those parties can do, again I'm ignoring the last round, is send some randomness to the adversary. And the adversary responds with messages M tilde which are given to the honest parties back. Now in the ID world, what do we have? We have a trusted party which is willing to compute C Pi T for us under some additive attack A. This trusted party gets his input, the inputs of all the parties. And now the ID word adversary, namely the simulator, somehow needs to provide an additive attack that will make those two words be the same. And how would one go ahead and do it? So the first thing that we do is we honestly simulate the corrupted parties. Well, the specification, what they should be doing is given in the protocol. So we can just go ahead and run them, providing them with suitable randomness and we'll respond with messages. We can then go ahead and talk to the adversary, invoke it, again on the same randomness and it will reply with the messages M tilde which are the same as it was given here. Taking the difference between these two, we get exactly the additive attack A which needs to be supplied to the trusted party. And in the paper, we indeed prove that those two words are the same, the three words equals ID. Okay, so that's our second step. The third step is that we need to transfer this additive attack on C Pi T to a linear attack on the circuit that the parties actually try to evaluate. And in the paper we have a notion of a circuit homomorphism and what it states is that if a circuit C prime is T homomorphic to a circuit C, then any additive attack on C prime is equivalent to a linear attack on the circuit C. And what actually holds for most natural protocols is that indeed C Pi T is T homomorphic to C. And we give a very simple criterion when this happens and it's just a matter of checking that indeed the C Pi T after you wrote it out is homomorphic to C. And let me give you an intuition why is this like this. So here's an example of C Pi. And C Pi T usually is a junkie version of C. What it does? It basically needs to compute C because that's what the protocol does. But it's a circuit representation of a protocol. And in the protocol we have a lot of unneeded details just because we need to maintain user privacy. And this blows up the circuit C Pi. But inside it deep, deep inside it actually computes C with some additive attacks on it. So if you have some additive attacks on C Pi we can basically transfer them as an additive attack on C. Okay, so this is our last step. And once we have completed this as I stated previously all that you really need to do is that you need to once you know that the main observation holds namely that any active adversary can be simulated by a linear attack is basically take the circuit that you wanna compute compile it into a secure circuit and then you use the passively secure protocol to evaluate the secure circuit. This will give you active security. So now let me show you what would you need to do if you were to take, if you have your own favorite protocol and you would like to make it actively secure. So this is a protocol I know nothing about. What do we need to do? So first you need to design this T randomized you need to take your protocol Pi and design this T randomized protocol Pi T and you need to do it while maintaining T equivalent to the original protocol. So that the adversary cannot distinguish if he's attacking Pi or Pi T. This is the only step which requires some creativity. Once this is done or the third step is very easy. Take C Pi T, write it out and verify that it is T homomorphic to C. If usually it will. It's a very easy check that just needs to be made. It's a housekeeping task. Once this is done you guys basically got your actively secure protocol. And this is how you construct it. Compile the circuit and evaluate your possibly secure protocol on the secure circuit. Okay, so some open problems. Right now all of our constructions only consider large finite fields. They operate for protocols that evaluate arithmetic circuits on large finite fields. The binary case or small fields are not covered by our constructions. And we actually have ongoing work on trying to make it work for binary fields. But this will be useful for protocols such as the GMW protocol in the OT hybrid model where you really work on bits, not on field elements. Another open problem is getting better efficiency of our constructions. So we have this compilation of the protocol of the circuit to secure circuit and this inevitably blows up circuit sites. It's a small constant that is hidden there and therefore the concrete efficiency is quite good but one can always try to get something better. The last open problem is to consider more general models of attack. So we consider those linear attacks which suffices for our MPC application but maybe there are the natural family of attack models where you can get fault-tolerant circuits. So for open problems regarding MPC applications, what we have not considered is computationally secure protocols. Maybe there is some natural family of passively secure protocols that when you run them in the presence of an active adversary, whatever happens, those protocols will fail but they will fail in some way which is meaningful on the underlying circuit. So if you identify such a family, you can then go ahead and try to construct circuits which resists those attacks which are due to this family. Okay, thanks and now I'll take questions.