 Hello everyone, I'm Pei Han. I'm going to talk about two-round secure multi-party computation, minimizing public key operations. It is joined to work with Sandram Garg and Akshay Shuinimasa. The first question you want to ask, what did you achieve in this work? And this is exactly what we did. Next, I'm going to explain each of these terms in more detail. What is secure multi-party computation? What does two-round mean? What is public key operations? And why do we want to minimize it? So let's get started. Secure multi-party computation, NPC. Once again, it is a protocol among multiple parties. Every party has a private input, and they want to jointly compute some function f on their private inputs. So they can run such an NPC protocol. At the end of the protocol, everyone learns the output. The security guarantee is, again, the output y is the only thing that they can learn from this computation. Even if up to m minus 1 parties are corrupted and colluding, they cannot learn anything more about this party's input to x3. So this is the definition of NPC. What does two-round mean? Well, it means the NPC protocol has two rounds. Here is what a two-round NPC protocol looks like. We assume there is a broadcast channel, and the protocol has two rounds. In the first round, every party broadcasts one message to all the other parties, which depends on their private input. End of the first round. In the second round, every party broadcasts another message to all the other parties, which depends on their private input and the first-round messages that they have received. End of the second round, and then everyone can figure out the output. Now you may be asking, why do we care about round complexity? Why is it important to minimize the number of rounds? Why do we consider two rounds? Consider a protocol, let's say, between two parties. And if the round complexity is too high, then probably most of the work has to be done just in the communication, especially if these two parties are the me and my mom who sits in China, which means the network latency between us becomes a few hundred milliseconds. So maybe most of the work of this protocol has to be spent on the network latency. So it's usually very important in NPC to minimize the round complexity. Why don't we consider the minimum number of rounds, which is one round, or because it's impossible to compute certain functions in one round in NPC. So two rounds is the minimum number of rounds that we can hope for. Can we do two round NPC then? Let's briefly look at the literature. Back in the 80s, Goldberg, Mikhaili, and Weiderson gave a NPC protocol that can compute any function. And the round complexity is the depth of the circuit that computes this function. So the number of rounds grows with the depth of the circuit. And later, Biber, Mikhaili, and Rogeway gave a constant round NPC protocol, which is independent of the depth of the circuit. OK, great. And then in terms of two round NPC, now we know constructions from various assumptions, especially the recent work by Ben Hamoda and Lin and Gaogen Shui-Nivasa, which constructs two round NPC from this primitive called two round oblivious transfer. Since we also know two round NPC implies two round OT, so now they imply each other. So this is also kind of the minimal assumption that we can hope for. OK, now we can construct two round NPC from the minimal assumption. What's next? Can we implement? Well, you can, but it's just too slow. One of the reasons is that there are too many public key operations. Why is that a bad thing? Because public key operations are very slow. To give you a better sense how slow it is, compared to symmetric key operations like AES, it can be done like hundreds of millions of operations per second. But in contrast, public key operations or asymmetric key operations can only be done tens of thousands per second. This number may vary for different implementations or different machines. But this is just to give you a high level idea why public key operations are very slow. OK, so it's very important to minimize public key operations. And here comes our main result. We constructed two round NPC from two round OT, which is a minimal assumption. And the state of the art uses this many OT's, which is essentially this many public key operations. And we improve it to this many OT's and essentially this many public key operations, plus polynomial number of symmetric key operations. Where n is the number of parties, lambda is the security parameter, and c is the size of the circuit, namely the number of gates in the circuit. So before, the number of public key operations is a polynomial in the number of parties, security parameter, and size of the circuit. Now we improve it to be independent of the size of the circuit that computes the function. The rest of the result is the same as before, semi-honest two round NPC from two round semi-honest OT, and malicious NPC from two round malicious OT in the CRS model. OK, so this is our main result. Next question, how did we achieve it? If you think about it, now we have two round NPC which uses this many OT's. How can we reduce the number of OT's or the number of public key operations? A natural idea is to use OT extension. What is OT extension? It is intended to do the same number of OT's, but with much fewer public key operations. This seems to be exactly what we want. Can we just combine these two primitives to minimize the public key operations NPC? The first question you need to ask is that since we still want a two round protocol, is there a two round OT extension? The answer is yes, B-verse OT extension is two rounds. This seems even more perfect. Can we just combine two round NPC with two round OT extension to minimize the public key operations NPC? Unfortunately, the answer is no. Trivially combining these two primitives doesn't work. Why? At a very, very high level, the reason is the following. You look at this puzzle, this two round NPC, and we want to minimize the public key operations, and there is a missing piece here. And you feel like two round OT extension is exactly the missing piece. Can we just plug it in? But if you look at two round OT extension, it actually looks like this, so it doesn't match. And in more detail, if you look at two round NPC, it needs to do this many number of OT's, and there are two special properties that they need from the underlying OT's. I will talk about this in a minute, but let's look at two round OT extension. It can do the same number of OT's, that's no problem, but it doesn't satisfy these special properties, so there is a mismatch between these two primitives. How can we solve it? Again, at a very, very high level, here is what we are going to do. We're going to somehow modify the puzzle here and also the small piece here so that they can match. In more detail, we're going to weaken the special properties, and also we're going to look deeper into the two round NPC and two round OT extension, somehow modify them so that first, the weakened properties are sufficient for the two round NPC, and second, two round OT extension also satisfies these weakened properties. In the rest of the talk, I will tell you what are these special properties, why they're needed for NPC, and why they're not satisfied in two round OT extension and how we're going to solve it. Here's a technical overview for the rest of the talk. First, I will need to define two building blocks. One is called Yao Scarborough Circuit. The other is two round Oblivious Transfer. This is the only place that we need to use public key operations. And next, I will tell you what are the special properties that are needed for the existing two round NPC and why they are needed. And also, I will tell you how two round OT extension works and why it doesn't satisfy the special properties, why there is a mismatch. And finally, I will briefly tell you how we solve the problem. Okay, let's get started. The first building block, Yao Scarborough Circuit, at a very high level, it takes the arbitrary Boolean circuit and gobble it into a gobbled circuit. Take the arbitrary input to the circuit and gobble it into a gobbled input. And then you can evaluate the gobbled circuit and figure out the output. Security guarantees that the only thing that you can learn from this evaluation is the output. Nothing more, nothing about the circuit, nothing about input. Only thing that you can learn is the output. This is Yao Scarborough Circuit. The second primitive that we will need is Oblivious Transfer. It is a special NPC protocol between two parties. We call them sender and receiver. The input from the sender is a pair of messages M0 and M1 and the input from the receiver is a single bit B. At the end of the protocol, the receiver gets one of the two messages depending on his choice bit. So if B is zero, he gets M0. If B is one, he gets M1. Security guarantees very simple, B is hidden to the sender and the other message is hidden to the receiver. Two round OT is a special OT protocol that only has two rounds. In the first round, the receiver somehow encrypts his bit B sends to the sender and keeps some randomness as security information. In the second round, the sender somehow encrypts our two messages and sends to the receiver. And then the receiver can use the security information to recover M sub B. Security guarantees the same as before, B is hidden to the sender, the other message is hidden to the receiver. Okay, now we have the two building blocks. We can look into two round NPC. How does it work? What are the special properties? Why they are needed? At a very, very high level, the two round NPC works as follows. Between every pair of parties, they need to run K number of oblivious transfer in parallel where K is a polynomial in the security parameter and size of the circuit. And each of these oblivious transfer is a two round OT. So the two parties were run K number of two round OT in parallel. And here are the two special properties that they need from the underlying OT. The first property is that these decryption secrets are known by the receiver before the first, before the second round. And this is naturally satisfied in this case because all these secrets are generated by the receiver in the first round. So they're known before the second round. Okay, this is satisfied. The second property is that these decryption secrets are independent to each other. What does that mean? It means that if you want to decrypt the first message, you only need the first secret. If you want to decrypt the last message, you only need the last secret. They're all independent. Revealing one secret doesn't affect any other OTs. And this is also naturally satisfied in this case because all the OTs are in parallel and independent. So decryption are also independent. But now you might be asking, why do we need these two primitives? They're trivially satisfied. They are actually very important for the two round MPC to work. Let's take a closer look at the two round MPC. What are the messages? In the first round, every party prepares a bunch of OT1 messages and broadcasts. In the second round, every party prepares a bunch of GABO circuits along with OT2 messages and broadcasts. That's it. One crucial point here is that the decryption secrets are somehow hard-coded inside the GABO circuits. And that's why we need the first property. Because the decryption secrets are hard-coded inside the GABO circuits, they have to be known by the receiver before the second round because they are used in generating the second round messages. Another crucial point here is that after the second round, the parties will try to evaluate these GABO circuits. And in the evaluation, these decryption secrets are output by different GABO circuits in different places depending on the actual computation. So that's why we need the second property. Revealing one secret shouldn't affect the security of any other OTs. The decryption secrets have to be independent to each other. Okay, so now we have seen the two special properties and why they are needed for NPC. Now let's look at two round OT extension. OT extension at a viral high level, the idea is the following. The two parties, instead of doing K-oblivious transfer, they just do lambda of them. And in addition, the two parties will run polynomial number of symmetric key operations, which we don't care. So this way you can minimize the public key operations to just lambda. And two round OT extension in particular works as follows. It has two rounds. In the first round, the receiver generates a new set of choice bits, lambda of them, somehow encrypts it, sends to the sender and keeps some secret information. In the second round, the sender somehow encrypts all her messages and sends to the receiver. And then the receiver can use the secret information to recover all the messages. Now let's see if the two round OT extension satisfies the two special properties. The first property, the decryption secrets are known by the receiver before the second round. This is satisfied because all these secrets are generated by the receiver in the first round. So they're known before the second round. This is good. However, the second property isn't satisfied. Namely, the decryption secrets are not independent anymore. If you want to decrypt any of these messages, you need to actually review the entire secret here. And why is that? Let's take a closer look at the protocol. So in the first round, the receiver randomly generates a new set of choice bits, lambda of them, and create lambda OT one messages for these new choice bits and sends to the sender and keeps some secret information. It computes something else, also sends to the sender. In the second round, the message sent from the sender consists of a big garbo circuit along with a bunch of OT two messages, which are corresponding to these OT one messages. And now the receiver can use the secret information to decrypt these OT two messages. And the output is actually the garbled input. So you can evaluate the garbled circuit and get the output, which is exactly what he wants. What is inside this garbled circuit? This is a functionality of this garbled circuit, but you don't have to look very closely into it. One thing you should notice is that this circuit takes as input a string of all the new choice bits. And inside the functionality, it computes a pseudo random generator. On this S, which means if you want to compute any of these messages, you have to take the Intel S and first to compute a PRG, which means if you want to do it, if you want to decrypt any of these OT messages, you have to actually reveal the Intel secret and recover all the garbled inputs. And that's the reason why the second property isn't satisfied. The decryption secrets are not independent at all. Okay, so now we have seen why there is a mismatch between two-round MPC and two-round OT extension. In the last few minutes, I will briefly tell you how we can solve it. Let's go back to the two-round OT extension. It doesn't satisfy the second property. The first thing that we are going to do is to somehow modify the two-round OT extension such that the second property will be satisfied. And here is the idea. The sender will in addition generate a new set of messages. We call them masks. And the two parties will round the two-round OT extension on these masks. And in addition, the sender will send her original messages XOR with these masks. Now the receiver can use these masks to unmask the corresponding message. So these masks are kind of a one-time pass. But the benefit of this is that now you can view these masks as decryption secrets. And now they're independent. If you want to recover any of these messages, you only need to review the corresponding mask. They're independent. However, the first property isn't satisfied anymore because now these are the decryption secrets and they're only known by the receiver after the second round. Remember we need this property because in the two-round NPC protocol, the decryption secrets are hard-coded inside the Garbo circuit. And we're going to solve this problem by somehow weakening this property. And the idea is to remove this restriction. So here is idea. Now the decryption secrets become these masks. And instead of hard-coding these masks inside the Garbo circuit, we will have another Garbo circuit that computes these masks and somehow feed into these Garbo circuits. So we will weaken the special properties to be, the decryption secrets can be somehow computed and fed into the Garbo circuits. This is very vague. But after weakening the special properties, we can further modify the two-round NPC and two-round OT extension so that everything matches. I won't have time to talk about that, but let me summarize. So this is what we achieved to run the NPC protocol from the minimal assumption to run OT and using, we improve the number of public key operations to be independent of the size of the circuit. And when we try to combine two-round NPC with two-round OT extension, they don't match. So we somehow change the special properties that are needed for NPC and modify these two primitives so that everything can match. So that's all for semi-honest setting. For malicious setting, there are more challenges and we developed new tools to solve them. A little bit on the future work. Essential question we wanna ask is how to make it more practical? Like for example, now the construction is making non-blackbox use of the underlying crypto operations. Can we make it blackbox? Unfortunately, it is impossible if you want to keep it in two rounds and you will hear it why in tomorrow morning, second talk. So can we weaken it a little bit to have blackbox but three rounds, maybe combining with the three-round blackbox OT extension. And further, if we want to make it more practical, what are the concrete optimizations that we can do? With that, I will conclude my talk. Thank you.