 Good morning, everyone. I'm Aarushi, and I'm going to talk about our result on round-optimal secure multi-party computation with honest majority. This is joint work with my co-authors, Prabhanjan Anant, RK Rai Chaudhary, and Abhishek Jain. So first, let me start by describing the setting of a multi-party competition. So we have a group of parties, each with their private individual inputs. And they wish to securely compute a joint function over these inputs. And what do we mean by securely computing a function? It essentially means that an adversary who can corrupt a subset of these parties should not be able to learn anything about the inputs of the honest parties beyond what is already revealed by the output of the function. Our focus here is mainly on the honest majority setting, where the adversary is allowed to corrupt up to T less than n by 2 parties. Honest majority MPC has been studied since the 80s, and there are a couple of reasons that make it an interesting area of study. So firstly, oblivious transfer is not necessary for achieving honest majority MPC. Also, it allows for stronger security notions, such as fairness and guaranteed output delivery, which are impossible to achieve in the dishonest majority setting. I will talk about these security notions in more detail in a while. Also, UC security is achievable in the honest majority setting without any additional trusted setups. One of the primary focuses of this talk is on the round complexity. And interestingly enough, the round complexity lower bounds of the dishonest majority setting do not apply here. So what is the question that we are interested in? We are interested in the exact round complexity of honest majority MPC in the plain model. And to make this question a little more concrete, let me start by talking about this various security notions that we have in this setting. So first, we have security with a bot, which is the most well-studied notion where the adversary can learn the output, but it can prevent the honest parties from learning the output by aborting prematurely. Next, we have the strongest security notion called guaranteed output delivery, where no matter what, the adversary cannot prevent the honest parties from learning the output. A relaxation of this notion called fairness guarantees that either all parties learn the output or nobody learns the output. And clearly guaranteed output delivery implies fairness. So our goal here is to develop round optimal protocols in the honest majority settings for each of these security notions. And we'll consider both semi-honest and malicious adversaries. So let me start by giving an overview of what is already known in this area. So feasibility results for security with abort were already established in the 80s. And these protocols gave us polynomial round protocols. Then later, in 1990, Beaver, Macaulay, and Rogaway initiated the study of constant round protocols. And since then, there have been several works improving over these results. But due to lack of time, I'll skip over to just two round protocols. So in two round protocols, Ishai et al. constructed two round unconditionally secure protocol for T less than n by 3 corruptions. And more recently, in Eurocrypt 2017, Beno Modalin and Garg Srinivasan constructed two round dishonest majority protocols. Their semi-honest protocols were based on OT. And the malicious protocols were in the CRS model. And so based on these state-of-the-art results, we ask the following question. Does there exist a two-round MPC protocol in the honest majority setting for malicious corruptions in the plain model? Things to note here are that this question was open regardless of assumptions. Moreover, we know that two-round protocols in the dishonest majority setting are impossible to achieve. And in fact, this question was open in the semi-honest case if we seek assumptions weaker than OT. So moving on to what is known for guaranteed output delivery. Again, for guaranteed output delivery, the feasibility results were already established in the 80s. And I'm going to skip over a large body of intermediate results and move on through the results that consider exact round complexity. So starting with the work of Ishai et al. who constructed two-round protocols for guaranteed output delivery for a single malicious corruption. And more recently, Gordon et al. constructed three-round maliciously secure protocols that achieved guaranteed output delivery in the CRS setting from LWE and NISIX. For lower bounds, Gennaro et al. showed that two-round protocols with T greater than two malicious corruptions are impossible in two rounds. And again, more recently, Gordon et al. extended their result to show that two-round broadcast channel protocols with guaranteed output delivery are impossible to achieve even against fail-stop adversaries. So given these works, we ask the following natural questions. First, does there exist a two-round NPC for T less than n by 2 fail-stop corruptions in the plain model? And in the malicious setting, we ask if there exists a three-round protocol that is secure against T less than n by 2 malicious corruptions in the plain model. And know that both these questions are open regardless of assumptions. And moreover, from the previous results, we know that if there exists a two-round protocol that is secure against fail-stop corruptions, that protocol must use both private channels and broadcast channels. OK, so I'm going to proceed to our results now. For security with abort, we show that there exists a two-round protocol for general functionalities in the plain model, assuming only one-way functions. And all known constant-round approaches, including ours, is based on randomized encodings. And currently, information theoretic randomized encodings are only known for NC1 circuits. So based on our current understanding of randomized encodings, it seems like for general functionalities, this might be the best that we can hope for. For guaranteed output delivery, we get the following two-round protocols for general functionalities again. So we get a broadcast channel protocol in the bare public key model. And this is assuming public key encryption. And in the point-to-point channel case, we get a two-round protocol in the plain model assuming OT. If we allow an extra round, we can in fact get a three-round protocol, secure against fail-stop corruptions, in the plain model, assuming only one-way functions. For malicious corruptions, we get a three-round protocol in the broadcast channel, using broadcast channels in the plain model, assuming zaps and public key encryption. So let me now give an overview of our techniques, starting with our two-round maliciously secure protocol that achieves security with a bond. So our starting point is the recent work of Garg Srinivasan, who gave a compiler to obtain a two-round protocol from any polynomial round protocol using two-round OT. And our starting idea here is to try and leverage the fact that we are in the honest majority setting and get rid of OT. So to proceed with this approach, let me first start by listing where OT is used in their protocol. So they start with a two-round, sorry, a polynomial round dishonest majority protocol over broadcast channels. And note that in the dishonest majority setting, such protocols are only known from OT. And then they use OT and garble circuits to compress the round complexity of this protocol to obtain a two-round protocol. Okay, so our strategy here is to first start with an unconditionally secure honest majority protocol. And note that such honest majority protocols from assumptions weaker than public key encryption require the use of private channels. But unfortunately, the JS compiler only gives us a way to compile or compress the round complexity of broadcast channel protocols. Therefore, our first challenge here is to try and modify the JS compiler in order to obtain, in order to enable a compression of private channel protocols. And our second challenge here is to leverage honest majority and achieve OT functionality without actually using OT. Okay, so let me first give a recap of their work. So they start with a polynomial round dishonest majority protocol over broadcast channels and transform it into a conforming protocol that has a very specific syntactic structure. It consists of a pre-processing phase and a computation phase. Okay, so in the computation phase, only a single party is allowed to speak in each round. This particular party acts as the speaker for the round and all other parties act as listener parties and only a single bit can be communicated in each round of this computation phase. Finally, they use OT and garble circuits to compress the round complexity of this conforming protocol to get a two round protocol. And in the first round of this compressed two round protocol, parties send their messages that they send in the pre-processing phase along with OT1 receiver messages. So each speaker party from the computation phase sends OT receiver messages in the first round and these OT receiver messages somehow commit to all their subsequent actions in the first round itself. Then in the second round, each party sends a series of garble circuits, one for each round of the computation phase. And these garble circuits output OT sender messages and these OT sender messages are used to deliver wire labels for the next garble circuit. Okay, so now let's try to solve our second challenge first, which is on achieving OT functionality without actually using OT, for which we devised this new gadget that we call multi-party OT. As the name suggests, this is a multi-party protocol where only two parties have inputs and all other parties have no inputs, but all parties learn the output. And an OT functionality with sender inputs N0, M1 and the receiver input B can be viewed as a degree two polynomial of the following form. Okay, I will talk about how we can construct such a protocol and its security later, but for now let's try to use this new gadget to solve our first challenge, which is on compressing private channel protocols. So in order to compress a protocol that uses both broadcast and private channels, we add an additional setup phase where the parties exchange one-time patch to emulate private channel protocols in subsequent rounds. And so now all the remaining rounds can be executed over broadcast channels. We now use the GS compiler to transform this into a conforming protocol with the pre-processing phase and the computation phase. The only difference here is that we have an additional setup phase. And now we finally want to compress the round complexity of this protocol to get a two round protocol in the plane model. But unfortunately the GS compiler only gives us a way to compress the pre-processing phase and the computation phase. The setup phase still remains intact. So our natural next step is to somehow try and parallelize the setup phase and the first round of this protocol. So let's see if we can do that with our new gadget. So in the conforming protocol with setup, let's say the list of round T from the computation phase chooses a random pad R and sends it across to the speaker of that round. Then later in round T of the computation phase, this particular the speaker encrypts the message using this random pad and broadcast it over a broadcast channel. Now when we transform this into a two round protocol with setup, the speaker party of round T is expected to broadcast its OT receiver message in the first round. And recall that in the GS compiler, this OT message is somehow supposed to commit to all its actions in the subsequent rounds. And now that this action in round T depends on R, this OT one message must also depend on the random pad R. But unfortunately this random pad R is unknown to the speaker before the setup phase. So clearly this strategy doesn't work here. But what if we try to work it the other way round and have the speaker exchange the random pad? Now note that the listener of round T will act as a speaker in some future rounds. And there it might have to decrypt this message that it received in the Tth round using this message R, which means that its action in that particular round will depend on this random pad R. And since this particular listener is also expected to commit to all its actions in the first round itself, the same problem arises. The listener doesn't know what this value of R is before the setup phase. So we've essentially just transferred this problem to another round and not managed to solve it yet. So these approaches clearly don't work. We potentially need a stronger property from our OT primitive, which is why we devise this new primitive that we call multi-party homomorphic OT. This is also a multi-party primitive with the only difference that instead of just two parties, three parties have inputs here. So apart from the sender and the receiver, there is a designated sender with an input R and the output of this multi-party homomorphic OT is the bit MB plus R. And similar to our regular OT functionality, the multi-party OT functionality can also be viewed as a degree two polynomial in F2 of the following form. Okay, so now I will again talk about how we can construct this particular primitive and its security in more detail later. But for now, let's see if this helps us in parallelizing the setup phase and the first round. Okay, so in the first round, the speaker of round T is expected to broadcast an OT message, OT receiver message to be specific. And we can actually now use the homomorphic property of our multi-party homomorphic OT and split the OT receiver message. The listener of round T also broadcasts an OT message using its input R, which is already known to him at the time of the setup phase. And so now the message that the speaker of round T has to send in the first round does not depend on the random pad R. And this message only depends on the information that it already has before the setup phase. Therefore, we are able to parallelize the setup phase and the first round of this protocol and we get a two round protocol in the plane model. Okay, so now moving on to how we can instantiate this particular primitive. So Ishai, Kusulowitz and Paskin in 2010 gave a construction to construct such two round protocols for these degree two polynomial computations. The only issue is that their protocol only satisfies privacy with knowledge of outputs. Privacy with knowledge of outputs is a weaker variant of security with a bot. So the ideal world for privacy with knowledge of outputs looks something like this. So each party sends its private inputs to the trusted party. The trusted party then computes the function over these inputs and sends it to the adversary. The adversary can then arbitrarily choose what output it wants to force onto the honest parties and sends it to the trusted party. The trusted party then forwards this output to the honest parties. And clearly this is a weaker variant than security with a bot since correctness of output for the honest parties is not guaranteed anymore. But since we want to obtain or achieve security with a bot, how do we ensure correctness of outputs for the honest parties? So going back to the ideal world for privacy with knowledge of outputs, if we look at our OT functionality, the output that the adversary receives in this case is one of the input bits of the sender, while the other input bit remains completely hidden. Therefore, the message Y prime, that's the output that it wants to force onto the honest parties, is completely independent of the other sender input bit. Again, recall that the OT functionality in this protocol is used only for transmitting the Gabel circuit wire labels. And from the security of Gabel circuits, we know that unless valid wire labels are used, Gabel circuits cannot be evaluated. So this means that either the honest parties learn the correct output or they don't receive any output at all, which is security with a bot and it's essentially what we wanted to achieve in the first place. Unfortunately, I won't have time to go over our protocols for the guaranteed output delivery, but you can take a look at our e-print version for more details on this construction and our other protocols for guaranteed output delivery. Thank you.