 I'm going to talk about our work on secure multi-party computation with free branching. This is joint work with Mathias Hall Anderson, Aditya Haigde and Abhishek Jain. So MPC, as we've seen through this day, is a protocol that enables a group of mutually distrusting parties to jointly compute a function over their private inputs, while guaranteeing that an adversary who controls a subset of the parties should not learn anything beyond the output of the function. And while there has been tremendous progress in improving the efficiency of MPC protocols, most of the techniques in efficient MPC literature currently rely on a circuit representation of the functions. And the communication complexity in these protocols is typically linear in the size of the circuit. And while there are some protocols that have sublinear communication, those usually rely on heavy computational primitives such as FHE or homomorphic secret sharing schemes, which at least currently are pretty far from being practical. Therefore, in order to efficiently compute a function, what we need is an efficient representation, I'm sorry, an efficient circuit representation of the function. But what if a function doesn't have an efficient circuit representation? Indeed, there are examples of functions that do not have an efficient circuit representation. For example, conditional branches. In conditional branches, evaluating such a function only depends on one of the branches. However, the circuit representation typically needs to encode a description of all of the branches as a result of which an MPC protocol or naively running an MPC protocol for computing such a function would result in communication that is dependent on the size of all of the branches. Therefore, the question that we ask in this work is whether it's possible to design an efficient MPC protocol for the purpose of securely computing conditional branches where the total communication only depends on the size of the largest branch. In other words, is it possible to compute conditional branches at the same cost of, for instance, computing a regular circuit of the size of a single branch? But before moving on to any prior work in this area, let me try to quickly convince you that computing conditional branches inside MPC efficiently is an interesting problem, which could have potential applications. So it's well known that control flow instructions are inevitable in computer programs. And prior works have shown that many forms of control flow instructions can actually be rendered into conditional branches. And these refactorings or renderings usually result in very many conditional branches. As a result, designing MPC protocols for conditional branches where the communication cost does not depend on the number of branches would be pretty useful. A more concrete real life application where such a protocol could be used is for example, where a collection of servers provide a set of K services together, which the clients can pay for and avail without having to reveal to the servers which service they actually accessed. Okay, so recently some works have addressed the exact same question that we are considering this work and have managed to make significant progress. In particular, the works by David Heath and Vlad Kolosnikov have shown that two-party protocols for conditional branches can have communication that is independent of the number of branches in the conditional branching program that's being evaluated. However, in the end-party setting, no such protocol is known. These recent works have managed to reduce the dependence on the number of public key operations, but the total communication in these protocols still depends linearly on the number of branches. These works overall leave some several interesting open questions. The first one being can we design an end-party protocol for conditional branches where the total communication is independent of all of the branches. Second, all of these prior works only consider security against a semi-honest adversary and the question that we ask is whether it's possible to also consider protocols with similar efficiency in the malicious setting. And finally, these protocols only focus on the Boolean circuit case. What about protocols for arithmetic circuits? In this work, we positively resolve almost all of these questions. In particular, we design an end-party protocol where the total communication is independent of the number of branches that are being computed and our protocol works over arithmetic circuits. For this protocol, we present variants that have communication complexity both linear and quadratic in the number of parties. We next show that this protocol can also be extended to work in the malicious setting. However, one drawback of that extension is that it has an additional multiplicative dependence on the statistical security parameter. And finally, we show that this protocol can also be extended to obtain a similar result in the constant round setting, albeit only for Boolean circuits. Due to time constraints in this talk, I'm only going to focus on our first result. Okay, moving on to the ideas that we use to obtain these results. So all of these prior works that I discussed so far rely on the same high-level idea. And the idea is to enable all parties to evaluate all of the branches and then to filter out the correct output. In particular, given an input, once the index of the active branch is decided, in this case 3, this value is sent to a multiplexer who then forwards the correct input to the active branch and sends some garbage values to the remaining inactive branches. These branches are then evaluated on the respective inputs, and the outputs of these branches are sent to a de-multiplexer of sorts, where this de-multiplexer also gets the same index of the active branch's input and filters out the correct output, that is the output of the active branch and forwards it to the next step of the computation. In our work, we take a slightly different approach. Instead of having to evaluate all of the branches, we consider a strategy where we enable parties to obliviously select the active branch and only require them to evaluate the active branch on the correct inputs. However, since we want the identity or the index associated with the active branch to remain hidden, we would somehow have to enable parties to compute on a hidden function. And this leads me to our initial observation, which is that this problem of computing on a hidden function has some similarity with the problem of private function evaluation. Recall that in private function evaluation, only one of the parties knows the function, and all of the other parties are in some sense computing in the blind. In our setting, however, nobody knows the function that needs to be computed, but the saving grace is that they collectively hold enough information about which function to compute. And we observe that a particular PFE protocol can actually be modified and adapted to our setting to obtain an efficient protocol for conditional branches. Okay, so the rest of my talk is going to be divided as follows. I'm going to first start by giving an overview of the PFE protocol by Mohasil and Sadegini. I will then show how we adapt and modify their protocol to our setting. Then I'll discuss the concrete efficiency of our protocol and how it compares to naively computing conditional branches inside any state-of-the-art NPC protocol. And then, based on if I have time, I can add some remarks about the additional two results that we have. Okay, so the main observation or the starting idea in this PFE work is that in order to hide the function that needs to be computed, we need to hide the circuit apology. And to hide the circuit apology, we want to hide the wired configuration of the circuit, that is how the different gates in the circuit interact with each other. And the second thing that we want to hide in order to hide the circuit apology is to hide the function associated with every gate in the circuit. Okay, so now in order to hide the gate functions, the idea used in this work is as follows. The function holder of the party who holds the function assigns a variable type g to every gate in the circuit. And this variable is set to a value 0 if the gate is a multiplication gate and it's set to 1 if the gate is an addition gate. It then secret shares these types for every gate amongst all of the remaining parties. And now assuming that the parties somehow get shares of the input wire values for this particular gate, they can compute both an addition and a multiplication on these left and right input wire values and based on the type of the gate choose the appropriate operation. And since this computation requires parties to work over shares, we want to use any underlying MPC protocol that is able to compute on shares. And we know that most existing efficient MPC protocols do indeed work over shares. But this particular description makes a simplifying assumption that the parties already start with an additive sharing of the left and right input wire values to every gate. But it's unclear how they actually obtain this because all but one party don't even know what the wire configuration in the circuit are. Which brings me to the next idea in this paper that is enabling parties to determine additive shares of the inputs to every gate while keeping the wire configuration of the circuit hidden. Their protocol proceeds in two steps. In the pre-processing phase, the function holding party starts by assigning incoming labels to every wire in the circuit. This incoming label is in some sense associated with the gate to which this wire goes as input to. They also assign an outgoing label to every wire which is associated with the gate that this wire comes as output from. Based on these incoming and outgoing labels assigned to every wire, they define a mapping let's call it pi and simultaneously the remaining parties that is the non-function holding parties sample random masks for every wire in the circuit. Let's call these the incoming mask and the outgoing mask. After this, the parties interact with each other at the end of which the function holding party is able to learn the delta value which is the difference between the incoming wire mask and the outgoing wire mask associated with every wire in the circuit. This delta value is then used in the online phase to enable parties to evaluate the circuit without leaking the wire configuration to them. Let's say we have a gate g which has incoming wire values with incoming labels a and b and an outgoing wire that has an outgoing label c and I'm using za, zb and zc to denote the actual wire values induced in these wires as a result of the computation. Now after we are done evaluating this gate g, the parties are going to add the outgoing mask associated with the outgoing wire of this gate to the the zc value that was computed as an output of this gate and they reconstruct this value. And for computing the gate g itself, the function holding party identifies the correct masked inputs to this gate and adds the delta value that we computed in the pre-processing phase to these values and sends this added value to the remaining parties. The remaining parties can now simply subtract the incoming masks from these a and b values to get the the additive shares of the actual values on which this gate g needs to be evaluated on. And again this I'd just like to reiterate that this is a general compiler that can work on any MPC protocol that is capable of working over shares. I'm now going to talk about how we can adapt this exact protocol to our setting to get a protocol for evaluating conditional branches where the total communication does not depend on the size of all branches. Okay so starting with how to evaluate a gate while hiding the gate function, let's assume that the parties have an additive sharing of the unary representation of the index associated with the active branch that is the branch that we want to evaluate. And assuming there are k branches, we assume that the parties have additive shares of bits b1 to bk. They can now use these shares of b1 to bk and take a linear combination with the different types of the gth gate in every branch to obtain an additive sharing of the type g of the active branch. And since this is just a linear combination, the step doesn't require any communication. Now once we have additive shares of the type of every gate in the active branch, as before, assuming that the parties already have additive shares of the left and right input power values to every gate, they can perform a similar operation as before to get additive shares for the outgoing wire of every gate. And note that this particular step because it requires parties to first compute the addition and multiplication operations and then perform a selection process requires two times the amount of communication and computation as the size of one branch. But again, the question that still remains is how the parties actually obtain additive shares of the left and right input wire values to every gate in the active branch. Similar to the PFE protocol that we just discussed, we will have a separate preprocessing phase and a separate online phase. So in the preprocessing phase now, because the parties already know all of the branches, all the parties can assign separate incoming and outgoing wire labels to every wire in every branch. And this gives us a separate mapping PII for every branch that we are considering in our conditional branches. These parties like before also share incoming and outgoing random musts, but they do this only once. They only sample one set of masks. They don't do this for every branch separately. These masks will be reused for every branch. And again, since we only sample one set of masks, the communication required or incurred in sampling these masks is again independent of the number of branches in the circuit. Now, given these incoming masks and the outgoing masks, what we want is to compute a sharing of appropriately permuted outgoing masks associated with every wire in the active branch. And this can be done by taking a linear combination with the shares, the bit shares of B1 to BK, which is the unity representation of the index associated with the active branch. But since this step requires us to actually multiply shares, this will, and naively doing this will incur communication and computation that depends on the size of all branches in our program, which we'd like to avoid. But let's assume that we're able to do this efficiently. Now, if we have this sharing, it's easy to compute the Delta value as before. We simply subtract this permuted outgoing mask from the incoming mask to get the Delta value associated with every wire in the active branch. So the question that remains in the pre-processing phase is how do we efficiently compute this inner product step? For this, we will rely on threshold linearly homomorphic encryption. And the protocol proceeds as follows. We start by computing encryptions of the bits associated with the index of the active branch. Every party encrypts its share of every bit individually and sends it or broadcasts it to every other party. Every other party then takes a linear combination of these shares with their shares of the appropriately permuted outgoing masks in every branch. This gives them an encryption of the shares of the permuted outgoing masks for the active branch. Once we aggregate all of these encryptions, we get an encryption of the outgoing masks that is appropriately permuted according to the mapping of the active branch. And now we can simply decrypt this to obtain shares of the appropriately permuted outgoing masks, where the mapping that's used in this permutation depends on the wire configuration of the active branch. Again, here, note that the communication here is only required for communicating encryptions of B1 to BK values, which are independent of the size of the branches. They only depend on the number of branches. And in the aggregation step, which again only depends on the size of one branch. This brings me to the end of the preprocessing phase. Now given that we have additive shares of the delta values associated with every wire in the active branch, we can now use that to proceed in the online phase as follows. Again, as before, we have this gate G that has these incoming and outgoing wires. Similar to before, after computing the gate G, parties add the outgoing, sorry, mask the output of this gate with the appropriate outgoing mask and reconstruct this masked value. Now for computing G, what we want is to identify the correct U by A value, which is the appropriate masked input wire value. Earlier in the PFE setting, we relied on the function holding party to send this to us. But here, since none of the parties know this, what we're going to do is we are again going to rely on the additive shares of the index associated with the active branch that we have and take a linear combination of these additive shares with the UPI values associated with every branch to actually get the right masked value for the active branch. And this can be repeated as is to compute shares of the UPI B value. And as before, given the shares of these A and B values, we can subtract the appropriate incoming mask to get shares of the actual additive shares of the actual input wire values to this gate G on which we'd like to evaluate the gate. And as before, similar to the PFE protocol, this approach can work with any MPC protocol that is capable of operating over shares. Okay, so given this protocol, let's now see how it compares to just lively computing conditional branches using a state-of-the-art MPC protocol. I think you're slowly running over time, so maybe if you can sum this up quickly. So we compare it to Mascot, which is a dishonest majority protocol that has a quadratic dependence on the number of parties. And as you can see, the communication complexity in our protocol pretty much remains consistent as the number of branches increase. And similarly, the runtime of our protocol also doesn't increase with as much rate as just naively running conditional branches inside Mascot. And we do a similar comparison with CDN, which is a dishonest majority protocol that only has a linear dependence on the number of parties. Finally, we show that this protocol can also be extended to the militia setting. And we also give a constant round variant by relying on a multi-party garbling approach. Thank you. I think we have time for one quick question. So first of all, thanks for the nice talk. David. Thank you for the nice talk. I was just curious if you had the opportunity to do a concrete comparison with the prior work on MPC free branching. Like start garbling and stuff? The multi-party variants that reduce the number of public key operations. Right. So the communication complexity in our case will be better because our communication complexity is really better. And I believe we did, I don't think we put the graphs in the paper for the actual runtime. But even our runtime was actually not that bad in comparison to the motif paper is, I think, what we compare to. Thank you. Okay. Thanks very much, Arshi.