 Hey everyone, today I'll be talking about round optimal MPC from minimal assumptions. This is joint work with Mikaela Shampi, Vipul Goyal, Abhishek Jain, and Ravlias Toski. So let's jump right in, multi-party computation or MPC is a mechanism that allows parties to compute a joint function over their private inputs by executing a protocol. This involves parties sending messages to one another at the end of which parties are in possession of the output. Since the focus of the talk is on complexity, what is around? A lot of interaction constitute of every party sending a message to every other party. For efficiency purposes, our goal is to minimize the number of rounds. Obviously, without any security guarantees, this can be trivially done in a single round of communication by parties simply sending their private inputs to one another. So what is the security property that we want? Internatively, we want to say that a misbehaving party doesn't learn anything more than just the output of the function. So how is this formalized? We contrast the real world where the protocol is being executed with an ideal world where all the parties simply send their inputs to some trusted functionality, which computes the output and sends the output back to all of the parties. And we say a protocol is secure if for every adversary in the real world corrupting some set of parties, there exists an adversary in the ideal world corrupting the same set of parties. This only formalizes this notion that the parties learn nothing but the outputs because in the ideal world, clearly just by definition, the parties learn nothing but the output. So there are various settings one could consider for MPC protocols. We consider the following setting. We consider computational security, where we require security only against computationally bounded adversaries. We make no assumptions on the number of parties that an adversary can corrupt and these parties can behave arbitrarily. We focus on black box simulation, where the simulator uses the adversary only in a black box manner without looking at the internal workings of the adversary. And we assume no trusted set of. So the question we really focus on is two part in the sense can we construct round optimal MPC from minimal assumptions. So the two parts are round optimality and the assumptions have to be minimal. So what do we know for both of these axes? So this work started with this wonderful work of Yao and Colerai Mikhaili and Richardson, establishing MPC. And there has been subsequently lots of work done there. Beaver, Mikhaili, and Roger Wei introduced a constant on protocol. These were further improved. And the first sort of lower bound or impossibility result in this domain was by Katz and Ostrowski who showed that four message protocols are impossible for two-party computation. This is in contrast to rounds where in two parties we think of a message as, say, Alice sending a message to Bob or Bob sending a message to Alice. And Katz and Ostrowski wrote out such protocols. And then there was a bunch of work improving on the round complexity. And then there's this wonderful work by Gaurav Mukherjee Pandey and Polypronato who showed that three rounds are actually impossible for MPC for general functionalities. And they also gave a positive result, constructing a five round protocol, assuming obfuscation. This left a gap which was then resolved under strong sub-exponential assumptions which again were improved to strong number theoretic assumptions but only polynomial time assumptions. So clearly we have now in terms of total number of rounds, clearly we have round optimum protocols under polynomial time assumptions. So we want minimal assumptions. So what is the minimality for constructing MPC? It turns out in this wonderful work by Kylian and subsequently by others that oblivious transfer is a necessary and sufficient condition for MPC. And this tightness was sort of observed to a large extent by Banhamuta and Lin who showed that K-round OT protocols imply K-round MPC. And the only caveat being K has to be at least five. So this left the gap of what about four round protocols. And our result finally closes this long line of work which I seen some recent exciting development by showing that four round oblivious transfer protocols imply four round MPC. So what kind of security properties do we require from this oblivious transfer protocol? We require indistinguishability security against a malicious thunder and extraction of a receiver bay. So the security properties are actually quite mild. So what makes this a hard problem? We illustrate one such problem below which we call protecting the fourth round MPC. Consider any four round protocol computing of function f that's run between Alice and Bob. So let's now say that Alice is a malicious adversity. In fact Alice is a malicious rushing adversity. So what is the rushing adversity? Alice may decide to not send its message after it sees Bob's message. So for instance in the fourth round Bob sends his message. Alice looks at Bob's message and decides not to send her message. Alice at this point has all the information to compute the output. And in this manner only Alice learns the output while Bob perhaps doesn't have enough information to compute the output. By itself this is a denial of service attack which doesn't seem too bad. We said Alice can behave maliciously. In fact in the first three rounds she could have behaved maliciously and forced the function being computed instead of the function f to the identity function. And in this case Alice learning the output means Bob's input is revealed because the identity function on Bob's input is Bob's input itself. So to protect against this Bob really wants to not send his fourth round message unless Alice can prove her honest behavior. So how this is typically done is that Alice convinces Bob of her honest behavior via zero knowledge proofs before Bob sends his fourth round message. Given that Alice needs to convince Bob before he sends his fourth round message we require three rounds zero knowledge proofs. Unfortunately in this seminal work by Goldreich and Kroschik they showed that it's impossible to have three round zero knowledge proof with blackboxing which is the setting that we are in. So I want to say that there are many many challenges in constructing four round protocols but in this talk we'll focus on solving this challenge mainly. So to do so we're going to construct what are known as multi-party condition with disclosure of secrets. So what is a conditional disclosure of secrets? So given a message it's a mechanism which allows us to encrypt the message such that given a witness that satisfies the condition you can actually decrypt the message. So the witness in some sense actually decrypt it. So conditional disclosure secrets or CDS has the long and story first starting with these works of Gertner, Ishaakifilo with some marking and it's a spawned an area of itself. So how do we use CDS as a safety net to attempt to solve the problem that I illustrated earlier. So here what Bob does is Bob encrypts his fourth round message using the CDS and sends it to Alice and the condition is that it will only decrypt as long as Alice can prove that she behaved honestly. So how does Alice prove honest behavior? She says, oh here's my input and randomness explaining honest behavior in these first three rounds. Great, this seems to work for two parties but does it work for more than two parties. Now consider the setting that Kall sends her fourth round message to both Alice and Bob and consider the setting specifically where Alice and Bob were colluding. Bob behaved maliciously. Alice behaved honestly even though she's a malicious party. So Alice does have a witness for her honest behavior in the first three rounds while Bob does. So what Alice can do is Alice because she has a valid witness can actually decrypt the message that Kall sends and send across to Bob. So now Bob learns Kall's fourth round message even though he behaved maliciously. This is something that we really want to avoid. So instead of locally proving that you behave honestly, we want it to be the case that the witness is that everyone behaved honestly. And obviously for privacy reasons we can't allow everyone's input and randomness to be the witness so instead what we really want is a public witness that's present at the end of the fourth round because the decryption only needs to be done after the fourth round. So this really gets this four round zero knowledge group back into question because oh so what Alice and Bob can do is they can complete the four round zero knowledge proof and send the fourth round to one another at the end of the protocol and then both Alice and Bob collect all the proofs not just from the two parties but in the multi-party setting from all other parties and the witness is going to correspond to everyone's proof and Kall's message is only going to be decrypted if all of the proofs are verified. Okay so this seems to work but we really care about the actual assumptions that are required to build CDS because we said you know our goal is too long that we want to minimize the number of rounds but also want to minimize the assumptions that we need. So how do we implement CDS? Unfortunately for non-interactive realization of CDS the only way we know how to do it is by witness encryption which is known only as human indistinguishability obfuscation which is a far cry from oblivious transfer so this while this does solve one aspect of our goal this doesn't give us the minimalization. So the main point to note is that we said our non-interactive realization which is encryption but we have a few rounds to work with specifically we have four rounds to work with so can we have an interactive version of the CDS and we'll actually construct an interactive version of the CDS assuming two primitives which are oblivious transfer and gobbled circuit. So I've talked about oblivious transfer a lot so what is oblivious transfer? Oblivious transfer allows the sender that has two inputs x0 and x1 just think of them as single bits for now and the receiver has a single bit b so the sender and the receiver learn a protocol at the end of ways the receiver has xb and she learns nothing about x1-b and the sender in turn learns nothing about the bit b and this can actually be done in four rounds and the second component that we're going to require is gobbled circuits which takes in an input and a circuit and performs this gobbling procedure which gives you a gobbled input and a gobbled circuit. Why is gobbling useful? It's nice in the sense that if the circuit has some secret information then the gobbling sort of hides this secret information. So how do we use oblivious transfer in gobbled circuit to actually compute the interactive CDS? For now think of the witness as a single bit it can easily extend to multiple bits so the sender wants to send this message or encrypt this message and send it along to the receiver. So what the sender does is it creates a circuit which takes in an input witness and if the witness satisfies some condition it outputs the message otherwise it does. So the sender gobbles the circuit but in the gobbling procedure we show that the input is gobbled to unfortunately the sender doesn't know what the receiver's input is and we don't want the receiver to send the input directly to the sender. So what they do is essentially agree on running an oblivious transfer protocol where the sender first computes the gobbled input for both bits say both gobbled input 0 and gobbled input for 1 and uses that as his input to the oblivious transfer protocol. So at the end of the oblivious transfer protocol where the receiver uses her witness as the input she learns the corresponding gobbled input to the witness and then Bob can send over the gobbled circuit and then receiver can evaluate this gobbled circuit and as long as the witness satisfies this condition she'll actually learn the message. Okay so how do we use the interactive CDS to protect the fourth round in the MPC? So here is what we have Alice has as witness all the collected proofs and Bob wants to protect his fourth round so he's going to put the fourth round inside of the gobbled circuit and then they run an OT protocol. So the problem here is if you actually look at the direction of the OT protocol messages it turns out that Alice actually needs to decide her receiver input by the third round of the OT because that's the last round that she sends the message. So now this goes back to us requiring three round zero knowledge proofs because as you said the witness has to be a public witness and we said we want to work with zero knowledge proofs and unfortunately we reached this point where Alice seems to require the proofs in the third round meaning all the zero knowledge proofs must complete at the third round. Okay so this seems to be a problem we seem to have done a whole lot of work to come back to this point where we require three round zero knowledge proofs but there are a few points to know. One is that we require zero knowledge in the simultaneous message model which is to say that you know three message zero knowledge is ruled out by code right and caution but three round zero knowledge where in each round both parties send the messages to conceivably something we could work with and the second property that we require or we observe is that the third round of the zero knowledge proof is actually hidden inside of the OT message and in fact is not even revealed until the fourth round of the NPC. So if Bob actually were to abort and not say for instance send his fourth round of the message then the fourth round then the third round of the zero knowledge is completely hidden. So we're essentially taking the three round protocol and repurposing it to work in four rounds. So okay so we seem like relaxed requirements that we want from a zero knowledge proof that we actually have a zero knowledge proof that satisfies this construction and it turns out it does. So this wonderful work by Badri Narayan, Goyal, Jain, Kalai, Khurana and Sahay showed that assuming just oblivious transfer that exists three round zero knowledge protocols that exist in the simultaneous message model that are secure against verifiers who do not work. This is exactly what we need because as long as you know the verifier abort we actually don't need to reveal the third round of the message of the zero knowledge protocol. So this is great. So what we can do essentially is now have an interactive CDS where Alice uses as her input the promise ZK which it goes into the third round and Bob uses as his input the fourth round of the message and then Alice only learns Bob's message as long as the CDS verifies. So we've seen issues in the multi-party set going from the two-party to multi-party setting before. So how does it all work in the multi-party setting? It's essentially the same thing. So Carol here on the left puts in her input as the fourth round message. Alice and Bob both separately can actually put in their promise ZK proofs and everyone gets the Carol's fourth round message as long as all the proofs and this can be actually extended quite simply from the two-party protocol. Okay so what about the full protocol? I've shown you sort of one issue and one component and how we solve this and this already had multiple components. So our full protocol actually has lots of many moving components. There are several non-malability challenges. So these are typically challenges when you want to construct protocols in a few rounds. You want to ensure that on this party's input is not somehow mauled to get the adversarial input, especially you want the on this party inputs to be independent of the adversarial inputs and since we're talking about black box simulation here the simulator gains an advantage over other parties by being able to rewind the adverse. So this is typically used when extracting the adversity's input and to allow for the simulator to rewind the adversity we need to have primitives that are secure in the presence of rewind. Specifically we construct an OT protocol that retain security in the presence of the bounded number of rewinds and this is a new construction and this is done assuming only regular OT. Let me just give you a high level idea of what this is of what a bounded rewind secure is. So what is even a bounded rewind secure primitive? So in a typical challenger adversary game the challenger adversaries play this game where they exchange messages after which the challenger the adversary outputs something and there is a win condition. In the bounded rewind challenger adversary game the adversary is allowed to send say here the third round messages multiple times and the challenger has to respond to each of these third round messages and we say it's k bounded if the challenger is allowed to if the adversity is allowed to make k different queries to which the challenger has to respond and we want the same security property to hold even if the adversity is allowed to query k different times. So let's consider the simple case of a four round one rewind secure OT so the adversity is allowed to ask make two queries to the challenger. So here we have the receiver with bit B and send it with XEO and X1 and the property we want is that the receiver input should be hidden even if an adversarial sender is allowed to rewind once. So the adversarial sender is allowed to see essentially two separate executions and we want it to be the case that the receiver security still holds. So the main intuition is that we run sort of two parallel copies of the OT and the receiver picks a random OT in the third round to proceed with and the other OT is never executed. So the first two rounds of both OTs are executed and the receiver in the third round picks k I'm going to pick the left OT and she does this randomly and continues with the left OT while the right OT is never completed. So how is this sort of useful to the challenger? What the challenger can do is that in the two different instances it can say for in the first instance it runs the left OT and in the second instance it runs the right OT. So then therefore each OT is run only a single time and you can rely on the security of your OT. The problem with this approach even though it seems to work is that it leads to bias transfer and why is that because the challenger's choice in one execution determines the choice of the other. What we really wanted to be the case is that the challenger can randomly pick for each execution which OT she wants to do. So how do we actually get that? The high-level idea is to secret share the receiver's input. So what Alice does is her input B, she secret shares into two shares or N shares in general. Let's think of it simply for two shares. She uses her input B1, shared B1 in the first execution and the input B2 in the second and each of these executions that as you saw before Alice in the first index let's say first index runs two parallel executions of the OT and the third one decides hey I'm going to pick the left one and in the second index which corresponds to B2 she again runs two parallel executions and this one she's randomly decides to pick the right execution. And why is this nice? Because in the challenger cannot independently sample which instance to use for each of them. So for the first index she randomly samples one of them and the second index randomly samples one and she does this independently for each execution. So the biasness is sort of gone and the security holds as long as there's one index that results in two different executions. So as long as there's one index that results into different executions you can rely on the OT security in that index and secret sharing guarantees as long as one index or one share is secure the overall input is secure. Of course this is only a high level idea there are lots of details missing how do you reconstruct and so on and so forth and we defer all the details to the paper. So to summarize we actually construct the full on MPC protocol assuming just to hold on OT and this is optimal in both the number of rounds and assumptions. So thanks a lot for listening if you have any questions please feel free to send me an email the link for the e-print is here you can always find me anytime on chat during the live talk at TCC and ask me questions there too. Thanks a lot.