 Hello everyone. This talk is on the bottleneck complexity of MPC with co-related randomness. I'm Dhavya and this is based on a joint work with Claudia Orlandi and Peter Scholl. Let me begin with what Secure Multiparty Computation or MPC means. Suppose you have n mutually distrusting parties out of which T are corrupt and the goal is that these parties want to compute some combined function on their private inputs. MPC gives them a way to do so while ensuring two main properties. The first is correctness. That is at the end of the protocol, everyone gets the correct function output and the next is privacy, meaning that nothing beyond the function output will be revealed. So in a nutshell, you can think of MPC as a protocol that emulates the effect of having a trusted third party to whom all these parties simply submit their inputs and get the output in return. The efficiency of an MPC protocol can be measured with respect to different parameters. One such popular measure is communication complexity, which measures the total number of bits that are sent or received by honest parties during the protocol execution. Bottle-neck complexity is a special flavor of communication complexity. So to understand this, let's look at this protocol A, where every party sends a single bit to a central party. Next, let's look at this protocol B, where again every party is sending a single bit, but this time the bits are communicated in a chain-like fashion. Now you can see that in both these protocols, the total number of bits that are being sent is the same, which is n minus 1 bits. So their communication complexity is the same. However, protocol B seems much better in the way that the communication has been distributed because it's more balanced among the parties. So to capture this, Boyle and others, they introduced this notion of bottleneck complexity, which is defined as the maximum communication complexity of any party within the protocol. So if you consider protocol A, its bottleneck complexity will be at least of order n because the central party there is receiving n minus 1 bits. However, for protocol B, the bottleneck complexity is a constant because every party is actually receiving or sending at most one bit. And that's why this bottleneck complexity is independent of the number of parties. So now if you have a situation where the bandwidth of this central party is creating a bottleneck, then definitely protocol B with lower bottleneck complexity would be the one that is preferred in practice. Now, if you think about settings where the number of parties is very large, there the goal would be to design protocols having bottleneck complexity independent of the number of parties. And we refer to such protocols as being BC efficient. BC efficient protocols were studied by the work of Boyle and others. And on the negative side, they showed that it's impossible to design BC efficient protocols for general functions. And more specifically, they showed that even if you don't care about security, still it's impossible to design protocols having bottleneck complexity sub linear in the number of parties for general functions. However, on the positive side, they presented a bottleneck complexity preserving compiler that transforms any insecure protocol to a secure one, and this compiler was relying on FHG. Since FHG is relatively inefficient, a natural question to ask would be that if we restrict ourselves to just specific functions, then can we design protocols with low bottleneck complexity without relying on FHG. So this is the question that we addressed partially in this work. So we considered this setting of semi honest adversary, where the corrupt parties, they follow the protocol steps but the adversary can learn their internal state. And we allow the adversary to perform up to n minus one corruptions. And we also assume that the parties have access to a correlated randomness setup. So in this setting, we designed BC efficient protocols for two function classes. The first function class is abelian programs, where an abelian program can be expressed as a function on the sum of parties inputs over an abelian group. This is actually a very expressive class of functions, which covers important applications like voting and classifiers and so on. The next class is that of selection functions, where the input of the first party is the selection index that can vary from two to n, and the output is nothing but the input that the first party has selected to learn. So for these two classes of functions, we design BC efficient protocols, and we use the tool of garble circuits, which can be built from one way functions to construct them. And additionally, the construction corresponding to selection functions also uses additively homomorphic encryption, which can be instantiated from standard number theoretic assumptions. So now in the rest of the talk I will present some warm up examples and give an idea about these two constructions. So before going into the construction, let's think about how any protocol design will look like such that it's independent of the number of parties. So one of the designs that we saw earlier was a chain like interaction. And this was quite promising because every party was talking only to its neighbors, which were constant. So this helped us design the protocol having bottleneck complexity independent of the number of parties. But it's not just enough to design protocols over the chain, because we also have to make sure that the number of traverses that we're making over the chain, even that should be independent of n, and the size of the messages that we're sending over the chain even that should be independent of n. So what kind of functions can be computed incrementally over the chain in a way that the size of the messages don't blow up. A natural example that comes to mind is that of the addition function. So let's consider the XOR example where every party has a single bit as input and the output is nothing but the XOR of these n bits. To begin with, if we did not care about privacy, then what the first party could do is she could simply send her input to the second party who could locally XOR his input with hers and forward it ahead on the chain and so on until the last party on the chain gets the output. So note that this is a BC efficient protocol because here the bottleneck complexity is independent of the number of parties. What if we now want this protocol to satisfy privacy. So assume that you had access to a correlated randomness setup, where every party is given its own masking bit such that the XOR of these masking bits is zero. And then what each party could do is she could locally XOR her input with her masking bit to compute the must input and then the parties could compute the XOR of these must inputs over the chain. It's easy to see that the XOR of these must inputs would be the same as the XOR of the actual inputs and therefore the protocol would be computing the function correctly. This is an example of a BC efficient protocol that computes XOR securely. Next, let's look at a BC efficient protocol for and function, where every party again has a single bit as input, and the output now is the logical and of these input bits. In this protocol, as a part of the correlated randomness setup, we give each party two elements, one for each potential input. She will use the element Z if her input is zero, otherwise she will use her element R. So the basic idea is that if you visualize the and function as this tree, then what we want is that at the end of their chain of inputs, we want the parties to identify whether they have arrived at a green node or a gray node, because that would correspond to their output being one or zero. So if there's just one green node, it's enough if we just give the parties some information to identify if they have arrived at this special green node or not. So this information that we give to the parties that can simply be a sum of these hours that were given to them. So that's what we do. Let capital R be the sum of the individual hours given to these parties and the parties are given this as a part of the correlated randomness setup. What the parties do is that in a forward chain they compute the sum of their wise. Now note that if each of their inputs was one, the sum of these wise would be nothing but the same as capital R. So the party at the end of the chain can simply check if this is the case if the sum is equal to capital R or not, if so she outputs one otherwise she output zero. So this protocol seems to work correctly, but let's analyze its security. Suppose an adversary is corrupting the first and the third party where the input of the first party X1 is one and X3 is zero. So the correct output in this case is zero. Now from the adversary's perspective, among all the possible parts during the protocol execution, based on the inputs of the corrupt party, he already knows that the actual part during the execution should be one among these two parts. So as per the security of the protocol, he must not be able to identify which of these two parts has been active during the execution. However, now what he can do is that in his head, he can imagine what the sum would have been had he added R3 instead of Z3 on behalf of P3. So he computes this sum Y dash based on that and checks in his head if Y dash is equal to capital R or not. If it is indeed the case that Y dash is equal to R, then he will be able to identify that the path taken during the protocol execution should be the one passing through the orange node. Because this is the one that if P3 had added R3 instead of Z3, then she would have arrived at the green node. So this contradicts the security of the protocol because now the adversary has learned which was the correct path taken during the execution and this will allow him to learn X2, which is the input of an honest P2. So to fix this, we do not give the parties the capital R as a part of the setup. Instead, we give each of them a PRF key. Now, what the parties do is that at the end of the forward chain, once they have obtained the sum, now the last party, she will be computing the PRF on this sum using her secret PRF key and forward it to the next party. The next party does the same. He applies the PRF using his key on this and then forwards it to the next party and so on. So there is a backward chain where there are N applications of the PRF on this sum. Now, as a part of the setup, instead of giving them capital R, we will be giving them Z, which is the output of the applications of a PRF using the N different keys on capital R. Now, what the first party at the end of the backward chain does is that she checks if the Z dash is equal to Z or not. And if it is the case, then she outputs one, otherwise she outputs zero. So it's easy to see that the correctness still holds because when the sum Y is same as R, these two will match. And now we have avoided the attack that we saw previously. Intuitively, that's because as soon as this honest party applies the PRF using his secret key K2. Now this in some sense fixes the sum Y. So now the adversary can no longer imagine what the output would be had the sum being Y dash instead of 5. So this is an example of a BC efficient protocol for and that is secure. Now the two warm up examples that we saw for XOR and and they are actually special cases of a function class called abelian programs, where an abelian program can be expressed as a function on the sum of inputs of parties over an abelian group. So we generalize some of the ideas there in this construction. Now what we already know is we know how to compute the sum of inputs securely. So if you had as a part of the setup some quoted sharing of zero, then the parties could simply compute the sum of the must inputs, which would give them the sum of their actual inputs. However, note that the output of edge may not necessarily reveal the sum of inputs, it just reveals F on the sum of inputs. So we want to avoid parties from learning this sum. So what we do instead is instead of having a quoted sharing of zero, we have a quoted sharing of a secret random element R instead. So that at the end of the first forward chain, the parties compute the must sum X plus R, which we refer to as Y. So now to compute H what we need to do is we need to compute F of Y minus R. But we should do this in a secure manner to be sure that this capital R remains hidden from the parties. So for this we use the tool of Gabel circuits for this secure evaluation. So let me take a detour and let's look at what Gabel circuits does. This is the circuit that we're interested in where input R is hard coded, it takes as input Y and it outputs F of Y minus R. To evaluate this securely, we transform this into a Gabel circuit, which you can imagine as a magic box, which has slots for each input bit. So imagine that this Y can be expressed as a string of five bits. Now this has a slot for each input bit and each of these slots can take two types of token. One is the token for zero corresponding to that bit of Y being zero and the other is the token for one. So the key of Gabel circuits is that if you feed this box, the tokens corresponding to an input, then this box will output F of Y minus R and nothing else beyond that. However, this box can be evaluated only if you have these tokens available. And also the security of this Gabel circuit holds only if one token per input slot is available. Now coming back to the protocol, recall that we were trying to compute F of Y minus R securely using Gabel circuits. So now as a part of the setup, each of these parties is given this magic box or the Gabel circuit. Now we also need to give them some information related to the input tokens so that they can evaluate the Gabel circuit. Now recall that the input tokens would be corresponding to Y but the value of Y is something that is determined only during the protocol and we do not know during the time of setup. So that's why the setup must give these parties information related to all possible values of Y related to the bits of Y turning out to be zero as well as one. So let's just consider a single bit of Y for simplicity. So there are two possible tokens corresponding to this single bit of Y. So what we do is that we additively share each of these tokens where additive sharing means that only if all the shares are available, then this token can be reconstructed. Otherwise the parties learn no information about the token if even a single share is missing. So we do an additive sharing of the token corresponding to zero as well as one and give the parties their respective shares. These are going to be useful in the evaluation as we will now see. Now in the protocol as we saw before the parties compute the mass sum in the forward chain. Now what the party at the end of the chain does is that once she knows the value of this mass sum Y, which is the input to the gavel circuit, she identifies her appropriate share of Y based on whether Y turned out to be zero or one. And then she forwards her share and why to the next party. What the next party does is that he also identifies his appropriate share of Y and he adds it up to her share and then he sends this forward along with Y to the other next party and so on. So now at the end of the backward chain, the first party would be getting the sum of all these additive shares of Y. So she will be able to reconstruct the token for Y and use it to evaluate this magic box and get the output F of Y minus R, which is nothing but the correct output of H. Note that here the input of the gavel circuit which is why is actually public because all the parties know it. However, gavel circuit still helped us in order to ensure that this hard coded input are still remains hidden from the parties. And also note that if, for example, two out of these three parties were corrupt, still that adversary cannot obtain multiple evaluations of the function and he cannot carry out residual attack. That's because he gets exactly one of the tokens. So due to this additive sharing, we know that he will just get the token corresponding to Y. And for the other bit, which is not equal to Y, he will be missing the share of the honest party. So that's why the security of the gavel circuit holds since he gets just one token per input slot. So this completes the description for the protocol for a billion programs. And for simplicity, I explained it for three parties, but it can be extended up to n parties, and it maintains the property that the bottleneck complexity is independent of n. Lastly, let's look at the construction for selection functions. Recall that selection function has the input from party P1 as the selection index, which can vary from two to n, and the output is nothing but the input that P1 chose to learn. A useful way to look at the output of selection functions is to express it as a summation of bi into Xi, where bi is an indicator bit, which is one, if i is equal to the selection index C, otherwise it's zero. Now this way of looking at it is useful because if we could make a party pi compute this bi Xi, then the values of these bi Xi's can be aggregated over the chain in a BC efficient manner. But the problem with this direct approach of making each party compute bi Xi would need the party to know bi, but that is something that is not leaked by the output of fetch. So to do this without allowing the party to know bi, we do it under the hood of additive homomorphic encryption. What I mean by this is that suppose somehow these parties P2P3 and P4 they got access to encryptions of B2B3 and B4 respectively, then what they could do is they can locally compute the encryption corresponding to bi Xi without knowing bi. And these encryptions can be added up over the chain to obtain the encryption of the output. But now we need a way to give them these encryptions of bi, but that is something that we cannot directly give as a part of the setup because the value of bi depends on the input of party P1, which is something that is determined only during the protocol. So that's why the setup must somehow account for all possible inputs of party P1. Instead of giving them a single encryption each, what we give them is a lookup table. This is how the lookup tables would be having the structure. So each of these lookup tables have exactly one row which has the encryption of one. And that is corresponding to the case when the selection index turns out to be the same as the parties index and all the other rows have an encryption of zero. The idea is that during the protocol, what P1 can do is that based on a selection index, he can point these parties to the correct row based on whatever his index is. For example, if he points, if his selection index is three, then he can point all of them to the second row so that they use these appropriate encryptions and they're able to get the encryptions of the output. However, if you order the ciphertext in this way, then the pointer is automatically revealing what the selection index is. And that is something which we want to avoid because we do not want these parties to learn the selection index. So what we do instead is that we apply a random cyclic shift on these rows of the lookup table. Now they are not in this lexicographic order, they will be shifted sequence of rows with an offset R which is big during the setup. And this offset is also given as a part of the setup to party P1. The reason for giving him the offset is so that he can calculate the appropriate pointer based on this offset and his selection index, and he can give it to the parties. Now what each party does is that she just looks at this pointer C dash, the row corresponding to that in her lookup table, and then she computes these ciphertexts. And now C dash doesn't reveal anything about the selection index, so the protocol maintain security. So this is the main idea of the protocol, but there are still a couple more things to take care of. The first thing is that here we just got an encryption of the output, but we also need to decrypted in a BC efficient manner. And secondly, if you generalize this and extend it to n parties, then we are actually giving each party a lookup table of n minus one ciphertexts. And this is a huge storage overhead in the cases when n is large. So we also have a mechanism to compress the size of these lookup tables and make it independent of n. Interestingly, both the techniques for these two features, they actually rely on gobbled circuits and I refer to the paper for for the details. So, to summarize, the notion of bottleneck complexity captures how balanced the communication of a protocol is. And in our work, we design BC efficient protocols for a billion programs and selection functions. And interesting open questions are to get more thoroughly characterize which functions allow for BC efficiency. And it would also be nice to get a general bottleneck complexity preserving compiler that does not rely on FHG. With this, I conclude my talk. Thank you for listening.