 Hi everyone. I'm Akshay Ram and I'm going to talk about the round complexity of Blackbox NPC. This is based on joint work with Yuval Ishay, Dakshita Kurana and Amit Sakhai. Let me start this talk by briefly recalling the notion of secure multi-party computation. Here, there are several parties and each party has its own private input. So we denote the private input of the i-th parking by xx. The parties also have a common input which is the description of some function f and the parties want to learn the output of this function applied on their private inputs. A secure multi-party computation protocol enables the parties to learn this output while hiding everything else about their private inputs. In this talk, we are interested in answering the following question. What is the round complexity of Blackbox malicious secure NPC in the plain model? By round complexity, we mean the number of sequential messages that need to be exchanged between the parties during the protocol execution. And this is a very, very important efficiency determining factor if the protocol is to be run over networks with high latency. Hence, it's important to minimize the round complexity of an NPC protocol as much as possible. By Blackbox protocols, we mean those protocols that only make input-output calls to the underlying cryptographic building blocks. And these protocols are independent of how these building blocks are implemented. Generally, Blackbox protocols tend to be much more computationally efficient than their non-Blackbox counterparts. And hence, obtaining such Blackbox protocol is viewed as a first step towards achieving computational efficiency. And by plain model, we mean a model that does not assume any form of trusted setup. This specifically means that we do not assume any common random or reference strings that is available to the parties, nor we assume any sort of correlated randomness that could be shared between the parties. So this is the basic setting in which NPC could be constructed. And it's very important to construct NPC protocols that does not assume any form of trusted setup. So before moving on, let me briefly summarize the prior work in constructing round efficient multi-party computation protocols in the plain model. The work of Gurg et al. from Eurocryp 2016 showed that four rounds are necessary in order to construct secure multi-party computation protocols in the plain model against malicious adversaries. And this lower bound holds even when considering Blackbox as well as non-Blackbox protocols. A sequence of recent exciting works have in fact shown that four rounds are sufficient for constructing multi-party computation against malicious adversaries in the plain model. Unfortunately, all these protocols make non-Blackbox use of cryptographic primitive, and hence they have a prohibitively high computational cost. On the other hand, the state of the art Blackbox protocols in the plain model have a large number of rounds. For instance, the work of Goyal from 2011 gave a Blackbox protocol whose round complexity was more than 15. So the main question we are interested in answering here is that is such a large round complexity necessary in order to construct Blackbox protocols in the plain model? We show that this is not the case. In our work, we show that for an interesting subclass of functions, we can in fact construct a round optimal that is a four round Blackbox MPC protocol. And this MPC protocol makes Blackbox use of a public key encryption scheme with pseudo-random public keys. And such an encryption scheme can be constructed based on many standard cryptographic hardness assumptions. For general functions, we give a five round Blackbox MPC protocol. And this protocol makes Blackbox use of a public key encryption with pseudo-random public keys, as well as a two round semi-malicious oblivious transfer protocol. Semi-malicious security is a strengthening of the standard semi-honest security, wherein we allow the adversarial parties to choose their own random types. Again, a two round semi-malicious oblivious transfer can be constructed based on a variety of standard cryptographic hardness assumptions. Somewhat surprisingly, we use the techniques for constructing these MPC protocols in the plain model to give better protocols in the correlated randomness setting. Specifically, assuming a special form of multi-party correlation, we construct a two round malicious secure protocol that makes Blackbox use of a two round augmented semi-malicious MPC. By augmented semi-malicious MPC, we mean a semi- malicious MPC protocol that satisfies some weak form of adaptive security with erasures. So prior protocols in the multi-party correlation model made extensive use of the protocol garbling technique and hence had a very high computational cost. On the other hand, our protocols are extremely simple. So as two interesting corollaries of this result are as follows. Firstly, we give a two round protocol for computing branching programs that has statistical security against malicious adversaries. Second, we also give a two round protocol for log depth arithmetic circuits that makes Blackbox use of the underlying field. So in the rest of the talk, I will mainly focus on our construction of a four round protocol for an interesting subclass of functions. So the functionality that we consider is what we call as the pairwise OT functionality. To understand this better, consider multiple parties and in this pairwise OT functionality for every ordered pair INJ, we compute an OT instance between INJ where J acts as the sender and I acts as the receiver. So for instance, between the first and the second party, we run an OT instance called as OT12 where the first party acts as the receiver and second party acts as the sender. Simultaneously, we also compute an OT instance between the first and the second party called OT21 where the second party acts as the receiver and the first party acts as the sender. Similarly, between the first and the fourth party, we run an instance OT41 where the fourth party acts as the receiver and the first party acts as the sender and so on. So why is this pairwise OT functionality interesting? It's interesting because it readily implies a protocol for pairwise two-party computation where you compute some two-party functionality between each ordered pair of parties where one party acts as the receiver and the other party acts as the sender and this result follows directly from the work of Ishae et al in 2011. And the main question we are interested in solving is can we construct a four-round protocol for computing this pairwise OT functionality? Before moving on to our construction, let me explain the main challenge involved in constructing such an OT protocol. A natural attempt that one could think of is to take a protocol that securely implements the OT functionality between a sender and receiver and use this protocol and run it in parallel for computing each of these OT instances in the pairwise OT functionality. So this satisfies correctness, but unfortunately this might always not be secure. So to see why this is the case, consider the setting where the adversary corrupts the second party. So this corrupted party, just the second party, acts as a receiver in one of the OT instances with the first party. So the first party acts as a sender and this corrupted party acts as a receiver in one of the OT instances. Simultaneously, this corrupted party acts as a sender with the third party acting as a receiver in another OT instance. So what this corrupted party could do is that it could take the messages that it received from the first party acting as the sender, it could maul these messages to generate new messages to be sent to the third party. A result of this mauling attack, the inputs that the adversarial party could use may depend on the inputs of the honest sender and this violates the security requirement. So in order to prevent such an attack, one needs to make use of what is called as a non-manuable OT protocol. And our approach of constructing such a non-manuable OT protocol involves the following steps. First, take a four-round oblivious transfer protocol with some special properties and transform this protocol into a four-round sender non-manuable OT protocol. By sender non-manuability, we mean a protocol where the adversarial sender inputs cannot depend on the honest party's inputs. So we take such a four-round sender non-manuable OT protocol and transform it into a four-round protocol that computes the pairwise OT functionality. So the second transformation from four-round sender non-manuable OT to four-round pairwise OT involves standard tools and techniques. Whereas the first transformation that is from a four-round OT protocol with some special properties to a four-round sender non-manuable OT involves the user's split-state non-manuable codes. And finally, we construct this four-round special oblivious transfer protocol based on any public key encryption with pseudo-random public keys. So in the rest of the talk, I'll mainly focus on constructing a four-round sender non-manuable OT protocol from a four-round OT protocol with some special properties. And before going on to that, we'll first define what is meant by a split-state non-manuable code. A split-state non-manuable code involves an encoding and a decoding scheme. The encoder takes a message M and encodes this message into two states, the left state and the right state. The decoder takes these left state and the right state and outputs the message. The non-manuability property requires that if the left and the right states are tampered with two independent functions f and g into states L tilde and R tilde. And if we run the decoder on these tampered states L tilde and R tilde to obtain the tampered message M tilde, then we are guaranteed that M tilde is independent of the original message. And for our purpose, we need a non-manuable code with a special property called a symmetric decoding. Specifically, we require the output of the decoding when given L and R to be same as the output of the decoding when given R and N. That is, even if you swap these two states, the output of the decoding remains the same. And it's easy to add the symmetric decodability property on top of any non-manuable code. So let's see how does non-manuable codes help in constructing a sender non-manuable OT protocol. So in order to construct a sender non-manuable OT, we use the same template that we discussed before. But instead of running OT protocol in parallel, we run a two-party computation protocol for computing a special function F in parallel. So we design this function in a very special way that allows us to argue the sender non-manuability property of this protocol. So let's see how this function is constructed. So this function F is a two-party function between a sender, which is on the left, and a receiver, which is on the right. So the sender inputs to this function consist of strings M0 M1 and encoding L0 R0 and another encoding L1 R1 using the non-manuable code. The receiver inputs to this function consist of a bit B and another bit C. So B is the choice bit that is to be used in OT and C is another bit. So what this function does is the following. So it first checks if decoding of L0 R0 is equal to M0. It then checks if decoding of L1 R1 is equal to M1. If both these checks pass, then it sets x comma y to be L0 comma L1. That is the set of two left states from the sender inputs. If C is equal to 0, otherwise it sets x comma y to be the two right states R0 and R1 and it outputs MB along with x comma y to the receiver. So the receiver can retrieve MB and it follows from the property of non-manuable codes which states that any non-manuable code acts as a two out of two secret sharing that given this x comma y, the other string is hidden, namely M1 minus B is hidden. And hence this function F computes the OT functionality. And we can construct a protocol for securely computing this function F based on any malicious secure OT protocol. And again, this follows from the work of Ishay et al. in 2011. So let's see how a protocol for F helps in arguing the sender non-manuability property. And before that, let's try to see what the sender non-manuability property means. So let's consider an adversary who corrupts one of these parties. And this party acts as a receiver when it is interacting with a party which is acting as a sender. And in other instance, it acts as a sender when interacting with an honest party acting as the receiver. And let's call the first interaction where the adversarial party acts as a receiver as the left interaction. And the second interaction where the adversary acts as the sender has the right interaction. So the sender non-manuability property requires the following. Namely, there exists a simulator extractor that can simulate the left interaction while extracting the implicit sender inputs used by the adversarial party in the right interaction. In order to argue sender non-manuability, it's sufficient to show the following. Let's say that the implicit receiver input used by the adversarial party on the left interaction is a choice bit B. Now the sender non-manuability property boils down to proving the following. For any two honest party's inputs on the left, namely m1-b and m'1-b, the implicit sender inputs used by the adversarial party on the right, namely m tilde 0 and m tilde 1 are computationally indistinguishable in these two settings. Namely, when the honest party uses the input m1-b, you consider the distribution of m tilde 0 and m tilde 1 on the right. Similarly, when honest party uses the input m'1-b on the left, consider the distribution of m tilde 0 and m tilde 1 on the right. And these two distributions have to be computationally indistinguishable. And in order to show this, we make use of a split state non-manuability code. So let's see how this is shown. So consider a thought experiment where the honest receiver on the right in the first experiment uses the input c tilde 0 and in the second experiment uses c tilde 1. As a result of the correctness of the two party computation protocol, this honest receiver will obtain l tilde 0 and l tilde 1 in the first experiment and it will obtain r tilde 0 and r tilde 1 in the second experiment. And using l tilde 0 and r tilde 0, you can obtain m tilde 0. And again, using l tilde 1 and r tilde 1, you should be able to obtain m tilde 1. Now, we should prove that m tilde 0 and m tilde 1 is independent of the other string, which is used by the honest party. In order to show this, let's consider the case where in the first experiment, the adversary uses the input with c equal to 0 on the left interaction. And in the second experiment, the adversary uses the input c equal to 1, that is the c tilde and c are the same. So in this case, we can use the security of the two party computation protocol to argue that the only information that the adversary learns in the first experiment is l 0, l 1. Similarly, we can again use the security of two party computation to argue that the only information that the adversary learns about the honest party's other input is r 0 comma r 1. So we noticed that l tilde 0, l tilde 1 is a function of l 0 and 1 in the first case. And r tilde 0, r tilde 1 is a function of r 0 comma r 1. Hence, this constitutes a valid split state tampering of the non-malibule code. And hence, we should be able to use the security of the non-malibule code in order to argue that m tilde 0, m tilde 1 is independent of the sender's string, m 1 minus however, in the first case, we considered the setting where c is same as c tilde, but this need not always be the case. So let's consider the case where c equal to 1 in the first experiment and c equal to 0 in the second experiment. Again, via the security of the two party computation protocol, we can argue that the only information that the adversary learns is r 0 comma r 1 and the only information adversary learns in the second experiment is l 0 comma l 1. So what we infer is that l tilde 0, l tilde 1 is a function of only r 0, r 1. And similarly, r tilde 0, r tilde 1 is only a function of l 0 and l 1. So now we should be able, we can use the symmetric decoding property of the non-malibule code to again show that this constitutes a valid split state tampering attack. And now we can use the security of the non-malibule code to show that m tilde 0, m tilde 1 is independent of sender's input m 1 minus. And of course, I have swept a lot of details under this graph. And in order for this protocol to work, we need the underlying two party computation for computing this function F to have something called as one reviving sender's security. And we construct a one reviving sender's secure two party computation protocol, making black box use of any public key encryption with pseudo random public keys. So this is the main ideas underlying the construction of a sender non-malibule OT. And as I mentioned before, we can transform a sender non-malibule OT to a pairwise OT protocol using standard tools and techniques. So finally, I would like to give a brief idea about our five round protocol for computing general functions. So in order to construct a five round protocol, we make use of the IPS compiler that was introduced by Ishai Prabhakaran and Sahai in crypto 2008. In order to instantiate this IPS compiler, one needs a outer protocol and inner protocol and a watchlist protocol. We instantiate the outer MPC protocol using the two round client server protocol from the work of Ishai Kusilowitz and Paskin in 2010. In order to instantiate the inner protocol in this compiler, we give a new construction based on the protocol garbling technique. And to instantiate the watchlist protocol, we make use of the pairwise OT protocol that we just discussed. A careful combination of these protocols will give rise to a final protocol for computing general functions. To conclude, we gave a round optimal Blackbox protocol for computing the pairwise OT functionality. And this implies a Blackbox protocol for computing the pairwise two-party functionality. Using the IPS compiler, we also gave a five round Blackbox protocol for computing general functions. As mentioned before, using these techniques, we give a two-round Blackbox protocol in the correlated randomness setting. And I encourage you to look into our paper for the details. So there are plenty of interesting open problems from our work. So the first is, are there other applications of our techniques? Specifically, can we combine the use of non-malleable codes with other secure computation protocols to obtain non-malleable versions of other interesting cryptographic parameters? The second question is to find other applications of pairwise OT protocol. So one of the applications that we used in this work is to use this pairwise OT in order to implement the watchlist functionality in the IPS compiler. But are there other applications? And finally, can we construct a four-round protocol using our techniques? We discussed some barriers in the paper of obtaining such a four-round protocol. And that's it. Thank you for your attention.