 So the last talk is round optimal black box protocol compilers by Uali Shahi, Dakshita Kuran, Amitsa Hai and Dakshai Srinivasan and Dakshai is here in the talk. So thanks for the introduction. So I'm here to present one more talk with the title round optimality. So I'm going to present about round optimal black box protocol compilers. This is based on joint work with Uali Shahi, Dakshita Kuran and Amitsa Hai. So let me start with the customary slide introducing secure multi-party computation. So we have several parties, each party has its own private input. And the parties also have as a common input some description of some function F and they wish to compute the output of this function applied on their private inputs. So for this purpose, the parties run a distributed protocol and we want this protocol to satisfy two properties. The first is of course the correctness which states that at the end of the protocol, we want all the parties to be able to compute the output of this function applied on their private inputs. The second property is of course the security requirement which states that even if a subset of these parties get corrupted by a centralized adversary, we want these corrupted parties jointly not to learn anything about the honest party's inputs except what is leaked by the output of this functionality. So typically there are two types of adversaries that have been considered in the cryptographic literature. So the first adversarial model is the semi-honest adversary where the corrupted parties follow the protocol specification but try to learn additional information by examining the transcript. And generally speaking, semi-honest adversaries are easier to protect against and protocols that are secure against semi-honest adversaries are much more efficient. The more stronger adversarial model is the malicious adversary where the corrupted parties could deviate arbitrarily from the protocol specification and try to break the security. And malicious adversaries are harder to protect against and protocols that are secure against malicious adversaries tend to use sophisticated cryptographic tools and techniques. So in this work, we are interested in building a protocol compiler. So let me explain what that is. So the role of a protocol compiler is to take a protocol which is semi-honest secure and compute some functionality f prime and transform it into another protocol for computing a function f that is secure against malicious adversaries. So how are f and f prime related? So typically for every f that we want to securely compute against malicious adversaries, there is a related functionality f prime for which it's sufficient to construct a protocol against semi-honest adversaries. In certain special cases, this f and f prime will coincide but in general, they need not coincide. So as protocol designers, our task is much simplified because we only need to construct a semi-honest protocol, which is usually an easier task for computing this function f prime. And the protocol compiler does most of the heavy lifting in order to protect against the much stronger malicious adversaries. So in this work, we are interested in constructing an efficient protocol compiler and let me explain what I mean by efficiency in this context. So in this work, we are interested in optimizing three main parameters. So the first parameter is to preserve the round complexity, meaning that the compile protocol must have the same number of rounds as that of the initial protocol. In other words, in order to achieve malicious security, the compiler should not add additional rounds. The second requirement is that of black box use, meaning that the compile protocol must make black box use of the initial protocol. That is it uses the algorithms that implement the initial protocol as oracles. It can give inputs, get outputs, but is otherwise agnostic to how the initial protocol is implemented. And finally, we want the compiler to make use of simple cryptographic tools and avoid sophisticated and less efficient primitives. Okay, so these are the three requirements that we strive to achieve in this work. Before we move on, let me explain a couple of prior approaches in constructing this protocol compiler starting with the seminal work of gold rig McCallion-Victorsen. So at a very high level, it takes a semi-honest secure protocol and it attaches a non-interactive zero-knowledge proof showing that each of these messages are correctly computed. So this prevents a malicious adversary from deviating in the protocol specification, and hence you can show that this compiler is secure against malicious adversaries. Of course, I'm sweeping a lot of details under the rug, but this is the high level idea. So a nice feature of this compiler is that it is around preserving, but of course it is not black box because in order to generate this zero-knowledge proof, one requires the code of the underlying initial protocol. Another popular compiler was proposed by Ishae Prabhakaran and Sahai in crypto 2008 and it's called as the IPS compiler. And unlike the GMW compiler, this compiler is a black box protocol compiler, that is it makes the black box use of the initial protocol. But unfortunately it resulted in an increase in the round complexity and it requires stronger cryptographic tools, namely in order to instantiate this compiler, one requires a malicious secure oblivious transfer. So for instance, if your goal is to construct a malicious secure oblivious transfer, then this compiler is not so useful because it requires a malicious secure oblivious transfer as its building block. And finally, a technical issue about this compiler is that it requires the semi-honest secure protocol to satisfy a stronger security property, namely it requires it to satisfy adaptive security with erasures. Okay, so given the state of the art, let me give you our results. So we give a protocol compiler that is round optimal, that is if you give a round optimal semi-honest secure protocol, it compiles it into a round optimal malicious secure protocol. It is black box and it makes use of simple cryptographic tools or setup. That is it either works in the random oracle model or it works in the one out of two random OT correlation setup where we now have many efficient tools for generating such OT correlation setup without much communication using the machinery of PCGs. Okay, so using our compiler, we obtain several interesting applications and I'll give you the applications in the two-party and the multi-party settings starting with the two-party setting. So starting with the two round semi-honest two-party computation protocol, we get the following results in the random oracle model. So firstly, we get a two round malicious OT. So all these results make black box use of this underlying semi-honest two PC. We get a two round non-interactive secure computation where it's a two-party protocol where only one party receives the output at the end. And we also get a two round two-sided non-interactive secure computation protocol where both the parties at the end of the protocol get the output. Okay, so we get all these results by making black box use of a two round semi-honest two PC in the random oracle model. So prior to our work, you needed some stronger security properties from the underlying semi-honest two PC such as pseudo randomness of the first round message. Whereas our work does not require such additional properties from the semi-honest protocol and it can start with any semi-honest protocol. And one more observation is that we can actually replace the random oracle model with a fixed polynomial sized random OT correlation setup. And the only caveat is that we need to start with a semi-malicious two PC instead of a semi-honest two PC. So a semi-malicious two PC is one where the adversary still follows the protocol but could choose an arbitrary random tape. And there is actually a very simple transformation where you can actually construct a semi-malicious two PC in the random oracle model based on semi-honest two PC. So this is how we can start with a semi-honest two PC in the random oracle setting. But if you don't have a random oracle, we need to start with the semi-malicious two piece. So these are the results in the two party setting. In the multi-party setting, we get the following results. So starting with the two round semi-honest OT protocol in the random oracle model, we get a three round malicious secure MPC protocol for computing arbitrary functions and for arbitrary number of parties. And the round optimality of this construction follows from an earlier work of Applebom et al. Who showed that one cannot use two round semi-honest OT in a black box manner to construct a two round MPC, even semi-honest MPC. So this lower bound also extends in the random oracle model. So even in the random oracle model, you cannot use a two round semi-honest OT to construct a two round semi-honest MPC in a black box fashion. Whereas in this work, we get a three round malicious MPC from a two round semi-honest OT. However, this lower bound doesn't work in the OT correlations model. So starting with the two round semi-malicious MPC protocol that satisfies certain natural properties that I wouldn't go too much into the details. In the OT correlations model, we get a two round malicious MPC. Okay. So the prior work of Ishay et al. from crypto 2021 required complex multi-party correlations, whereas we remove the need for this complex correlations and just require standard OT correlations. Okay. So, but in this talk, I'll focus on one such application that is to construct a two round malicious OT in the random oracle model, making black box use of a two round semi-honest two piece. This is what we'll be seeing. But as you might already have inferred, two round semi-honest two PC for arbitrary functions can be constructed in a black box manner using Yavo's garbled circuits from a two round semi-honest OT protocol. So this gives a black box transformation from two round semi-honest OT to two round malicious OT in the random oracle model. So this was not known before. Okay. So before we move on, let me quickly give you a brief recap of the IPS compiler, which is the starting point of our work as well. So the IPS compiler consists of the following components. So it makes use of an outer protocol. And for this purpose, let's fix an outer protocol where there are two clients, M servers, and we require a two round client server outer protocol. So for the purpose of constructing an oblivious transfer, it's sufficient for this outer protocol to compute the OT functionality. Specifically, the receiver client has a choice with B, let me denote it by X, and the sender client has two strings M0, M1 jointly denoted by Y. So in this two round client server outer protocol, we have the following interaction pattern. In the first round, the receiver client and the sender client secret shares its private inputs using a specialized secret sharing scheme and sends the corresponding shares to the servers. In the second round, the servers applies certain function. Let me denote the computation done by the IH server by SI on the shares received from the clients to compute these ZIs. And the servers send these ZIs to the receiver client. This happens in the second round. And after this, the receiver applies a decoding functionality on the ZIs to get MB, which is the output of the OT functionality. So we want this outer protocol to satisfy malicious security against any adversary that corrupts either one of these two clients and a constant fraction of these servers. So let's say that this fraction is one-third, so it should remind secure against a malicious adversary that corrupts one-third of the servers and either one of these clients. And such a protocol was constructed in the work of Ishae Kusilowicz and Paskin in 2010, and this is in the information theoretic setting. It does not involve any cryptographic operations. So this is the first component. The second component of the IPS compiler is an inner protocol, which for this purpose, let's just keep it as a two-round semi-harness protocol. Actually, it requires some certain additional properties. We'll come to that towards the end. So it's a two-round semi-harness protocol where the functionality that is computed by this protocol is the server computation of the outer protocol. So that is you have M instances of these inner protocol where the IH instance computes SI. And final component is what is called as the watchlist protocol, and I will explain the role of the watchlist in the next few slides. So given these components, let's take a look at how does the IPS compiled protocol look like. So you have the two clients, receiver and the sender. The clients first secret share their private inputs to X1 to XM and Y1 to YM respectively using the secret sharing scheme that was used in the outer protocol. Now the outer protocol had the help of these servers, which could help in the computation. But without the servers, how do the clients emulate the outer protocol? And this is where the inner protocol comes into picture. So for each one of these servers in the outer protocol, the parties, namely the receiver and the sender client, run the corresponding instance of the inner protocol, where the private inputs to this instance correspond to the shares that the parties send to the servers. So at the end of this emulation, the receiver client obtains the ZIs from the inner protocol and it can compute the output. But this satisfies correctness, but what about security? So let's consider a malicious adversary that corrupts the receiver. Notice that these inner protocols are only guaranteed to be secure against semi-honest adversaries, whereas a malicious receiver could deviate in each one of these inner protocol instances and break the security of this inner protocol instance. And recall that the outer protocol was guaranteed to only be secure as long as a constant fraction of the servers were corrupted. But here all the servers are corrupted, therefore the malicious receiver can trivially break the sender security. So in order to make this compiler secure, we somehow need to ensure that a malicious adversary can only cheat in a constant fraction of these server emulations. And this is where the watchlist protocol comes into picture. So in parallel to this emulation, the receiver and the sender run a specialized watchlist protocol that is computing the following functionality. So in this functionality, the receiver sends XI, RI, where RI is the randomness used for generating the messages in the ith instance of the inner protocol. And XI is of course its private input that it uses in the ith instance. And the sender on the other hand chooses a random subset K of certain size. Let's ignore the size for a moment. It's some subset K and the watchlist protocol delivers XI, RI for each I in K to the sender. Now given this information, the sender checks for each I in K whether XI, RI is a valid input, randomness pair that explains the transcript that was obtained from the malicious receiver. If any of these checks fail, then the sender aborts. So let's see how this watchlist protocol prevents a malicious adversary in cheating in more than a constant fraction of these server executions. So let's consider this malicious adversary which is cheating, which is corrupting the receiver. So if this adversary cheats in many executions, then since this K is randomly chosen, it has a non-zero intersection with the cheating executions with overwhelming probability. Therefore, this cheating will be deducted by the sender and hence it will abort. On the other hand, if this malicious receiver is cheating only in a small number of these executions, then we can rely on the security of the outer protocol, which is anyway secure against a constant fraction of server corruptions. So this is the main idea behind the IPS compiler and the watchlist protocol is used to prevent a malicious adversary in cheating in many inner protocol executions. But unfortunately, the watchlist protocol's construction requires use of malicious OT. Whereas our goal was to construct a malicious OT whereas this watchlist protocol requires use of malicious OT. So in our work, we give a new watchlist protocol where you don't require use of malicious OT. So this is the key technical contribution. So our solution relies on the following crucial observation. It relies on this observation that this subset K, which was chosen by the sender, need not be kept secret. And in fact, it needs to be randomly chosen after the receiver's message. So this K can be revealed in the clear to the other party. So this is the main observation. So with this observation, let me give you a bare bones version of the watchlist, which doesn't satisfy all the required properties and tell you how to compile it to whatever the required solution. Okay, so let's see a minimalistic implementation of the watchlist protocol. So we have the receiver and the sender. So once the receiver generates its first round message in the inner protocol, it also generates a commitment to all x i comma r i. Recall that x i was the private input and r i was the randomness that was used to generate the inner protocol messages. So it generates these M commitments and sends these commitments over to the sender. The sender now chooses this random subset K and sends it in the clear to the other party. Now the receiver opens these indices corresponding to this set K and the sender again performs the same check. Now again notice that if a malicious receiver is cheating in many inner protocol executions, then since this case chosen after it has committed to all the inner protocol messages, it will again have a non-zero intersection with overwhelming probability and we can again catch cheating adversely. But this works, but what is the problem with this approach that it results in an increase in round complexity. That is in order to check the receiver's message, we need three rounds. And in order to check the sender's message, we need another three rounds of this watchlist protocol run in the opposite direction. So even if you have a two round semi-honest two-PC protocol, this protocol results in a six round malicious two-PC. So how do we reduce the number of rounds? And here the main observation is that K is random and it's in fact public coin. So in the random oracle model, we can apply the Fiat Shamir paradigm. That is the receiver, once it has generated its commitments, hashes these commitments using an appropriate hash function H to obtain the set K. And it opens these commitments corresponding to this K and this can all be done in pair. So it need not wait for any messages from the other party. And so this results in a one round watchlist protocol in the random oracle model. So in parallel to the first round receiver message, you also send this messages in the one round watchlist. Similarly, the sender does the same thing and we have a two round malicious two-PC in the random oracle model starting with any two round semi-honest two-PC. So this is the key idea behind our work. So if H is modeled as a random oracle, then you can actually show that this is secure. Of course, as I had mentioned earlier, this IPS compiler required the semi-honest protocol to satisfy additional security property, namely adaptive security with erasures. And let me tell you why this is needed first and tell you how we remove the need for this adaptive security towards the end. Okay, so let's say that there is a malicious adversary that is corrupting the sender. And say that this malicious adversary deviates only in the first inner protocol execution. So since this deviates only in the first inner protocol execution, this deviation will not be detected by the watchlist with non-negligible probability. So here we are still fine because since the number of executions where the adversary has cheated is small and our outer protocol is secure against a constant fraction of these executions, so we must be able to rely on the security of the outer protocol. But a technical issue that comes up here is that in order to use the security of the outer protocol, we require the output that a honest receiver obtains from this execution where the adversary has cheated. And for this purpose, the IPS compiler required the adaptive security with erasures from this inner protocol so that they could compute the output that an honest receiver obtains from any execution where the adversary has cheated. So once they detect a cheating, they corrupt this and they get the input and the randomness that was used in that particular execution so that that enables them to compute the output. But here we are required to use only inner protocol which is only semi-honest secure. In order to do this, we actually consider a stronger outer protocol. So what is the property that is required from the stronger outer protocol? So recall that this, let's consider some constant fraction of these server corruptions and these corrupted servers could send an arbitrary second round message to the receiver. So we want a stronger outer protocol to satisfy the following error correction property, namely whatever be the messages that a malicious server sends in the second round, the output of the decoder should be the same when we replace these corrupted server messages with some default symbol, let's say the bot symbol. So if the outer protocol satisfies the stronger error correction property, then we don't need the inner protocol to satisfy adaptive security. Because whatever be the value that malicious server sends in the second round, you can obtain the same output by just replacing that with the bot symbol. So this allows us to rely only on a semi-honest secure inner protocol. And in our work, we can give a construction of such a stronger outer protocol that is secure against a slightly weaker form of adversaries called as pairwise verifiable adversaries. And we show that this pairwise verifiable security is sufficient to instantiate the IPS compiler. And we give a construction of this protocol based on bivariate polynomials. I wouldn't have time to go into the details. I encourage you to look into the paper for the details of this construction and the definition of pairwise verifiable adversaries. Okay, so to conclude, we gave a round optimal construction of two-party and multi-party protocols in the random oracle or in the OT correlations model that made black box use of a semi-honest or semi-malicious protocols. And our construction can be viewed as a normal twist to the IPS compiler wherein we strengthen the requirements of the outer protocol in order to weaken the security requirements of the inner protocol. And some of the open questions are to remove the need for random oracle and give a construction in the CRS model. And are there other applications of the outer protocol? It seems to us that the notion of pairwise verifiable adversaries is a very natural one and it's likely that there are other applications. And we believe that there is huge potential to optimize the concrete efficiency of our compiler for certain applications. And it would be good to investigate those applications and use our compiler in order to get concretely efficient malicious secure MPC protocols. And that's it. Thank you for your attention. Thank you. Are there any questions? So thanks a lot. So I mean, you mentioned like the removing the needs of random oracle. So I was just wondering how strongly you use it like in the programming. So we use both programmability as well as the correlation interact ability. Right. So what is the whole I mean, like for example, okay, maybe isn't it easier to think to relax the correlation of the functionality, for example, because the same results you have also in the correlation of the right. Sorry. So you have the same result assuming correlation oblivious transfer and not random oracle. Can you do the same? Yeah, exactly. So we have the same result from starting with a pseudo random oblivious transfer. The first round message is pseudo random. Is that what you're? No, I was wondering if the setup instead is like correlated like a bunch of outputs of a duty functional. Oh, you mean in the OT correlations? Yeah, yeah, yeah, we have this result in the OT correlations more. Right. I was wondering like, if you thought about considering a simplified function, OT functionality, for example, because removing the random oracle looks. Yeah, it seems like a hard. Yeah, but we haven't thought about relaxing the need for OT correlations, but that's, but that's an interesting direction to think about. Thank you. Any other questions? Okay, so let's thank Akasha again and the speaker. Thank you.