 So the next talk is round optimal multi-party computation with identifiable abort by Michele Ciampi, Diva Ravi, Luisa Siniskalki, and Hendrik Wardner, and Michele is presenting. Okay, thank you very much for the introduction, Manuela. Yeah, so multi-party competition. We are at fifth session, not going to say what it is. But there are many models in which you can study multi-party competition. In particular, the model we consider in this work has dishonest majority. We assume no setup. We assume that parties are fully corrupted and they behave in a rushing way. It means that in each round, the adversarial parties will wait to receive the messages of the honest parties, and then they will speak. Then all our protocols will rely on standard assumptions. In particular, our protocols are based on trapster permutations, and we only deal with the black box simulation. So what we know is that in the case of dishonest majority, there are functionalities that cannot be realized. That's a bad news. So we cannot realize some functionalities with fairness. However, if we don't care about fairness, we know that we still need four rounds of communication to compute some meaningful functionality, and we know that four rounds are also sufficient. And some recent works show that you can do that from some number-threatic assumptions or from a malicious secure notion of obvious transfers. However, if you look at all these protocols, you will notice that they are under a notion of security that is called security with unanimous abort. In this security notion, what you have is that honest parties might abort or might get the output of the computation. But if they do abort, I mean it's not like one party will abort and the other no, like all the honest parties will agree that that's an abort. With unanimous, with the identified abort instead, what you have is that in the case that honest parties abort, they will also identify one of the corrupted party. And another question is whether we can still construct a secure protocol in this setting in four rounds, which is, as I mentioned, the optimal, the best you can do. And in this work, we answer to this question to the positive. And the way we tackle this question is by providing a compiler that takes an MPC protocol that is secure with unanimous abort and turns it into a protocol that is secure with the identifiable abort. And like one moreover, like the communication channel we use here is a broadcast channel where, like in each round, all the parties speak at the same time. And so focusing on the messages of this purple party on the left, each message will go in this broadcast channel, so every party will receive this message. So let's say that those are messages of an MPC protocol with unanimous abort. So one way that you can use to achieve, I think, favorable abort would be to attach to each of these messages non-interactive zero-knowledge proof. Because in this way, every party that receives a message that sees a message on the broadcast channel, even if this message is not directed to this party, the party can still check that the message is correct, because if the zero-knowledge proof verifies. Here, I'm lying a bit because, like, you need some special properties on the MPC protocol to apply this type of compilers, because you need perfect correctness, otherwise, of course, this doesn't work. But the big problem is that non-interactive zero-knowledge requires setup. As I mentioned, we don't want to use a random protocol, we want to rely on standard assumptions. So the trivial idea would be, okay, let's use then mostly around zero-knowledge, because we know that we can actually do zero-knowledge in four rounds. And so if you now look at the protocol, or at least at the messages that one party sends and receives, the view of this party is the following. There is an outgoing message and an ingoing message. And what you can do now is that for each outgoing message, you ask this party to provide the zero-knowledge proof, which we know we can do in four rounds. And the theorem of this zero-knowledge proof is this course that the MPC message, the outgoing MPC message is well-formed, that I've been following the protocol. And you do this for all the messages. This works, but you need that the zero-knowledge protocol is publicly verifiable in the sense that in this case, you need to provide the zero-knowledge proof to convince any of the parties that are involved in the protocol. And now, of course, that might be an abort in the zero-knowledge. And you want that even the parties that are not involved in the generation of the transcript of the zero-knowledge can identify whether the abort was triggered due to an incorrect behavior of the prover or due to an incorrect behavior of the verifier. And these zero-knowledge proofs are easy to achieve. So let's assume this is not a concern. What is a concern, though, is that this protocol is far from being optimal. I mean, those are not four rounds. Good. So then the next step to solve this issue would be to say, let's just run one big zero-knowledge where we prove that everything is fine. Of course, if you want to do that, so if you want to run a zero-knowledge proof in parallel of your MPC protocol and prove at the end that all your messages were computed correctly, you need this zero-knowledge to be delayed input in the statement because your statement, which is the set of messages you computed, will be fully determined only in the last round. So now if you have this protocol, the way an execution of this protocol would be, it should look like something like this. So this powerful party will compute the MPC messages and at the same time will start generating this zero-knowledge proof. And at some point it might be that the MPC fails. But we don't know the reason why the MPC fails. However, this powerful party here will keep generating the messages for the zero-knowledge until the end, proving that the messages that she has generated were well-formed. And now given that the zero-knowledge proof is publicly verifiable, the only reason why this powerful party would not be able to complete this zero-knowledge proof is because she was behaving maliciously. And so all the parties can identify this specific powerful party as being the corrupted party. So actually zero-knowledge in this setting is not really what you need something stronger. You need a form of normal ability on the zero-knowledge, which is something that we show how to achieve in the paper. But what is more interesting and what I wanted to talk in the last part of the talk is that so here we are running in parallel an MPC protocol and a zero-knowledge proof. But why would they compose? There is no reason why they would compose in parallel. And actually they don't, or at least we don't know, to be precise, we don't know how to prove that they compose nicely in parallel. So the main reason why the proof failed is because consider this is the real experiment where it's the protocol I described to you. And when you want to prove the security of this protocol, ideally you want to rely on the security of the zero-knowledge and on the security of the MPC protocol in distinct steps. So what we usually do is that we do hybrid experiments, where in the first experiment you run the zero-knowledge simulator, of course, and then you prove that this hybrid is indistinguishable from the real experiment due to well, the zero-knowledge property of the protocol. And then you say, okay, good, now we run the MPC simulator and that's all. The proof is done. Unfortunately, we got an error. So unfortunately, the last step of the proof doesn't really work. And because what do you want to do in the last step of the proof? You want to reduce the security of the protocol to the security of the MPC. And so it means that you are in this game. Like you want to say, now I'm able to construct an adversity that breaks the security of the MPC with unanimous abort. And the security game works in this way. You have a challenger and this challenger might generate messages for the MPC protocol in an honest way or in a simulated way. And we want to show a distinguisher to reach a contradiction. And so the way we construct the distinguisher is by creating an adversity that internally runs the adversary for our protocol, for the identifiable protocol, and just acts as a proxy between the Brutus channel and the challenger of MPC for the black MPC messages, which are the messages of the unanimous abort protocol. So okay, I mean, you can do that. Fine. The problem is that we are in the playing model. We don't have random oracle. So the way simulators usually work in this context is by resetting the adversity by doing some what we call rewinds. So it means that the simulator of the knowledge protocol might say, okay, here you are another second round. And I want to see a reply because I need to extract some secret for you from you to perform the simulation. But remember the adversity is rushing here. So the adversity upon resuming the second round, he could change the second round of the MPC as well. And now the adversity will never give you the third round of the zero knowledge, unless he receives a new MPC message with respect to the third round. So he wants a reply that is consistent with this green MPC message. But the thing is that the challenger, you cannot rewind the challenger. I mean, that's not how this experiment is defined. And that's problematic. So it looks like we need the stronger security notion. And what would be suitable in this context would be a notion of a multi-particle computation that allows for this type of rewinds. So the first thing we do is to define this security notion. And then we show how to achieve it. In this security notion, basically, you have your adversity. And again, the challenger, which does the same either he provides honesty, generated messages, or simulated messages. But now the adversity can say, okay, now give me a reply to this new and fresh second round, which is this green message. And the MPC challenger interacts with the adversity, but stops at the third round. And now the adversity can actually do this process many times. But he can do this only a bounded number of times where this bound is known at the beginning. And after this, only one of those sessions will be completed, let's say. And you can see that if you have such an adversity, then the previous reduction would work, because the rewinds made by the zero knowledge simulator would not be a problem in the reduction, because the MPC challenger is happy to give you more replies to multiple second rounds. Good. So now what it remains to show is how you obtain a protocol that is secure under this security definition. So consider for now just the two-party case for simplicity. We have this yellow party and the purple party. And they start running an MPC protocol, a normal MPC protocol with no special properties at all. So what is the problem of dealing with the Rewindable Security in general? So the problem is that if you just take an MPC protocol and you can see multiple third rounds as a reply to multiple second rounds, the problem is that this could break the security of the MPC protocol because you might be able to extract some secrets. I mean, after all, that's also how a simulator would work. I mean, the simulator does rewind. So it's pretty clear that you are breaking something by doing the rewind. A high-level idea of our protocol is to not then send the third message of the multi-party competition protocol in the clear, but we will encrypt this message. And how do we encrypt this? So upon receiving the second round, each party, and in this case, I will be focusing just on the orange party, creates a garbage circuit. So the garbage circuit will contain the transcripts generated so far and the randomness of the orange party. And moreover, this garbage circuit is parameterized by a next message function. This is the next message function of the MPC protocol. So with this garbage circuit, basically you can, upon receiving a third round message, the garbage circuit can generate the third round on the behalf of the orange party and compute the last round of the MPC protocol. So it's basically what I'm saying here is that the garbage circuit will do what the orange party will do in the protocol. And now, what do I mean when I say that the third message of the protocol will be encrypted? I mean, we have a garbage circuit and the party, now the purple party, in order to run it, he needs to get the labels. And the way you get the labels is you by running an abuse transfer protocol, where the orange party will act as a sender using as input to the keys of this garbage circuit. And instead, the purple party will act as a receiver. And his input will be a bit string that represents the third round message of the MPC protocol. So the security of the T now tells you that this input, which is the third round message, is kind of secure. The sender should have no clue about what is the input of receiver in an abuse transfer protocol. And that's basically how we make sure that the third round is encrypted. But however, we want to encrypt, but we want to compute the output of this MPC protocol. So what happens here is that then the purple party will receive the labels that are consistent with this third round message. He will also receive this garbage circuit, but now he has the labels, he has the garbage circuit, and he can compute the last round of the protocol. And he can basically now just run, just compute the output for this MPC protocol. And this is done in a symmetric way. So the orange party will do exactly the same to get the output. Now, of course, it seems like we are saying, okay, now we need to run actually two primitives kind of in parallel. Now we have this abuse transfer, but what happens if you rewind, you believe it's transferred during the reduction? Okay, that's okay, because we know from a previous result that we want to construct a reliable secure abuse transfer protocol. So that's not a problem. So I should say that to go from the two-party gaze to the multi-party gaze, it's not straightforward. At least a two-party primitive. So as you can imagine, there are some problems when you go to the multi-party gaze, but the very high level, that's the very high level idea more or less. And so what we also think is that this approach might be helpful in any situation where you want, for example, combining parallel in multiple interactive primitives. This means that you could prove secure also two MPC protocols that are running in parallel. And this might yield, for example, to constructions like multi-party computation combiners that are around preserving and similar things. And yeah, we show that this notion is actually great when you want to achieve multi-party computation with the identifiable abort. And what we show is that all our primitives can be based on traptor primitations, but yeah, we think it's not hard to extend it and to realize everything from just oblivious transfer. Yeah, but we can discuss this maybe afterwards. And that's all. Thank you very much. So thank you, Michaela. We have time for questions. So the number of revinings in zero knowledge would be expected polynomial time, right? So what do you say B to B? Yeah, that's fantastic. That's a good question. So the point is that when you do the reduction, so our zero knowledge is not any zero knowledge. It's a zero knowledge protocol that we construct that basically we prove that if you get, let's say two accepting transcripts during the rewind, this simulation would work fine. Then what we argue is that in the proof, you will get these two accepting transcripts with some non-negligible probability and the reduction will go through. So in the reduction, we do not run and expect the polynomial time, but we cut the running time of the simulator such that the reduction remains polynomial time. Yeah, that's a reasonable question. And another thing is, did you also think about using non-blackbox zero knowledge? Yeah, so I was thinking about that actually this morning to use, to try to use non-blackbox zero knowledge in the reduction, right? And then the final simulator could still be let's say blackbox, but I mean, yeah, it depends. I would say it's not that trivial because if you're still, I think it would be easy if you just want the final simulator to be non-blackbox. I think it's fine, but if you just want to use the power of a non-blackbox simulator in the hybrid and leverage on these, it's an idea, yeah. Okay, so let's thank Mikael again. Thank you.