 My name is Rex Fernando and I'll be talking about achieving secure massively parallel computation in the presence of dishonest majority This is joint work with Ilan Komorgotsky, Yanilu, and Ilan Shi Alex, I'll start by explaining what we mean by massively parallel computation Our work studies the kind of distributed computing which happens inside data centers in particular the kind that deals with extremely large data sets Perhaps the most classic example of this is the Google search index This index is distributed over a large cluster of machines and whenever someone enters a query The machines have to coordinate with each other to respond since no machine contains the entire index Cluster computing has become the rule for computing over very large data sets over the last 20 years Since no one server can store the entire Google index or the entire Facebook social network graph or the entire Amazon product database In this talk, we're going to explore what's possible in terms of secure computation in the context of cluster computing To that end I'm going to introduce a model called the massively parallel computation model Which has more or less become the de facto standard model used by the algorithms community When studying the type of distributed algorithms that run inside data centers The way that this model works is that we assume we have a large input string and a set of machines Each of which have local space that is much much smaller than the input size This input gets divided among the machines which then run a distributed algorithm or a protocol and Collectively come up with an output which is defined to be the concatenation of the local outputs of each machine So to be more specific about the parameters the local space of each machine s is Defined to be n to the epsilon where n is the total input size and epsilon is a small constant less than one It follows naturally that the number of machines M is around n to the one minus epsilon an Important detail about the space model is that each message sent and received by a machine are counted against that's that machine's space budget What this means is that there's no broadcast because it would involve a cost linear in n and Finally we say that just a distributed algorithm or a protocol is efficient in this model if it has much less than log n rounds So before we go on I'd like to fix some terminology So for the rest of this talk, I'm going to refer to an MPC algorithm as an MPC protocol And I'm going to refer to each machine as a party since this is a crypto talk Now that I've introduced the model. Let me introduce the type of questions we address in our work We're interested in constructing protocols in the MPC model that satisfy a security notion Which is similar to the one in cryptographic secure multi-party computation In classical secure computation protocols, we assume that some of the parties are malicious Which we model by allowing a polynomial time adversary to corrupt and control some arbitrary subset of the parties The goal is to construct protocols where the honest parties outputs are hidden from the adversary And the adversary is prevented from tampering with these outputs So how do we capture these requirements formally? We do it in the following way a Protocol is said to be secure if there exists a simulator which has no direct access to the honest parties and Instead only learns the protocol output and is still able to generate a simulated view of the adversary Along with a simulated distribution of the honest parties outputs That is computationally indistinguishable From a real-world execution of the protocol and It turns out that at least in a syntactical sense this definition adapts to the MPC setting with minimal changes So now the natural question is can we actually achieve this definition of security in the MPC model as a reminder? We have two requirements The first is that the local space of each party is limited The second is that the wrong complexity is very small So the question is if we have an insecure MPC protocol that computes some functionality F Can we transform it into a secure version of the protocol that computes the same functionality while still respecting these two requirements? At this point it makes sense to consider some classical secure computation protocols and to understand why they don't extend to our model We'll start with the with the original secure computation protocol by GMW The problem with this protocol is that at the very beginning each party has to store a commitment to all other parties inputs and randomnesses This means that every party has to store data that's at least linear in the size of the input So this definitely doesn't work for us And it turns out that most other classical secure Protocols have a similar problem and that they all have a simultaneous broadcast phase So what this means is that every party has to send a message to every other party There is some previous work on secure large-scale computation But this but this previous work also involves a simultaneous broadcast phase. So none of these options will work for us In a very recent work, Chanadol initiated the study of secure massively parallel computation And they showed that the answer to our question is yes In particular, they built a compiler that takes any MPC protocol and turns it into a protocol with the following properties First it has a small multiplicative blow-up in the space used which means that asymptotically it respects the space requirement Second it has a constant round complexity blow-up, which means that asymptotically it respects the round complexity requirement And finally it satisfies malicious security against up to one-third corruptions in the common random string model The assumptions that they use are the hardness of the learning with errors problem along with the existence of a compact fully homomorphic Encryption scheme for polynomial size circuits along with non-interactive zero knowledge Here compact means that the ciphertext size is independent of the circuit depth The goal of our work is to improve upon the state of the art in this new line of research In particular, there are two main deficiencies in the previous protocol, which we will focus on The first is that security only holds if the adversary does not see the CRS when choosing the corrupted parties And in fact, there's an obvious and devastating attack if this is not true Second is that security only holds for up to one-third corruptions Since there are many classical secure protocols tolerating all but one Corruptions is not clear if this is optimal in this model Interestingly, these two deficiencies seem tightly coupled to the overall approach of the previous work Because they hold even if the adversary is not allowed to deviate at all from the protocol description Or in other words, if the adversary is semi honest So we see it as an important question whether these two deficiencies are inherent in the MPC model Or whether it's possible to build a compiler that does not suffer from them And we believe that this question is interesting even if we limit ourselves to the case of semi-honest security Our contributions are divided into two results First we consider the case of protocols where the output is short enough to fit inside the local storage of a single party In this case, we show that the answer to our question is yes In particular, we build a compiler that works assuming the existence of a public key infrastructure along with the hardness of the LWE problem and the existence of a fully homomorphic encryption scheme The efficiency properties of this compiler are the same as in the previous work I'd like to quickly point out that this already captures a very large class of MPC protocols Whose functionalities are considered very useful Our next result considers the more general case of protocols whose output sizes are unrestricted In this case, we also show that the answer is yes In particular, we build a compiler that relies on the existence of a PKI, hardness of LWE, the existence of an FHG scheme And additionally, the existence of an indistinguishability obfuscation scheme This protocol also has the same efficiency properties as the previous work For the remainder of the talk I'm first going to explain the short output protocol Which is quite straightforward and then I'm going to give a high-level overview of the long output protocol, which is more involved I'll start by explaining fully homomorphic encryption or FHE since it's an important building block in both of our protocols An FHE scheme is like a public key encryption scheme in that it contains a setup algorithm, an encrypt algorithm, and a decrypt algorithm But it also has an evaluate algorithm which lets anyone evaluate a circuit over encrypted ciphertexts I'm going to demonstrate this with a short example Let's imagine there are three parties where party one has the public key and party three has both the public key and the secret key Let's also say that party one encrypts some input x and sends the resulting ciphertext to party two Under an FHE scheme party two can use the evaluate algorithm with this ciphertext and some circuit And then when party three decrypts the evaluated ciphertext the decrypted message will be the evaluation of this circuit over x For our purposes, we're going to use a variant of FHE called threshold FHE where decryption privileges are shared among m parties More specifically each party is going to have a decryption key share and when all the parties collectively want to decrypt some message They perform the following decryption phase First the parties run what's called the partial decryption algorithm with the ciphertext and their share Then the parties combine the partial decryptions using the final decryption algorithm which reveals the output For security we want that all parties have to agree to decrypt in order for the message to be revealed and On the other hand if one party withholds its partial decryption then the message is hidden We'll call this m out of m TFHE We'll require the TFHE scheme to satisfy some additional properties as follows First the evaluated ciphertext has to have size independent of the circuit size Second the space required by the partial decryption algorithm must be independent of the number of parties Finally we assume that there's a master secret key Which can decrypt any ciphertext non interactively and we also require the secret key shares to be additive shares of this master key TFHE has proven useful in building classical secure computation protocols in particular ones with low round complexity The previous work on secure computation using TFHE all use the same general strategy And so I'm going to start the discussion on our short output protocol by explaining why this general strategy Doesn't immediately generalized to our model I'm going to describe the strategy in terms of the behavior of party one Since the behavior of all parodies is symmetric We assume party one has the public key of a TFHE scheme along with a secret key share and In round one party one starts by encrypting its input and randomness for the protocol and Sending the resulting ciphertext to all the other parties In round two after receiving all the other parties ciphertexts It uses these as inputs to the evaluation algorithm where it outputs the circuit corresponding to the functionality of the MPC protocol It then runs the partial decryption algorithm on the resulting ciphertext and broadcast this partial decryption After receiving the partial decryptions from everyone else it can run the final decryption algorithm to decode the output Earlier on in this talk I mentioned that the problem with using classical secure protocols in our model is that they rely on Simultaneous broadcast and we run into the same problem here Notice that in the first round party one broadcasts its ciphertext to all other parties And then it needs to store all the other parties broadcasted ciphertext in order to run the evaluation algorithm We also have the same problem in round two except with the partial decryptions For our short output protocol We're going to modify the strategy to adapt it to the MPC model and we'll first start by modifying the evaluation phase Recall that we want to build a compiler which takes an insecure massively parallel protocol and produces a secure one So the first modification that we're going to make is that instead of evaluating the functionality directly We're going to evaluate the underlying insecure protocol Let me explain this in more detail First, let me fix some notation for the underlying insecure protocol Assume that party one has a circuit for each round that describes this party's behavior in the round So in round I party one inputs the messages that it receives from the other parties along with its state at this point into the circuit and Receives an up back an updated state and some messages to send out in the corresponding secure protocol Instead of evaluating the circuit in the clear it evaluates it under FHE It receives encrypted messages from the other parties and it has an encrypted version of its state at this point and After evaluation it has an encrypted updated state along with a set of encrypted messages to send out Finally at the end of the encrypted version of the protocol party one has an output ciphertext Which contains an encryption of the of the protocol's output? One subtlety is that the communication pattern of the underlying protocol could leak something about the party's inputs And so we have to assume that this is in the case Luckily for us the previous work of channel has shown that without loss of generality we can assume this Now all that remains is for party one to compute the decryption of its final output ciphertext In order to decrypt party one has to run the partial decryption using its secret key share It also has to send the output ciphertext to all the other parties and to receive partial decryptions from these parties In order to run the final decryption algorithm to compute the output But now we run into essentially the same problem before Because party one has to receive and store partial decryptions from all other parties in order to run the final decryption algorithm It seems like we're back at square one But let me show you a simple observation about an existing TFG scheme in the literature Which will help us to get around this this observation is about the final decryption algorithm Namely that it can be broken into two steps and that the first step is simply addition in a field We're going to use this observation to prevent party one from having to store all the partial decryptions at one time So the decryption phase will work as follows first party one will distribute the output ciphertext to all the parties We can do this in a tree-like fashion to prevent any party from having to send too many messages in one round Then every party will run its partial decryption algorithm And then it's very straightforward for the parties to compute a sum of the partial decryptions They can do it in a tree-like fashion so that no party needs to store more than one more than a small number of values at once Then once party one has the sum value it can run the last step of the final decryption algorithm to obtain the output If we set the fan end of this tree along with the distribution tree in the previous slide to be lambda Then we get that the protocol satisfies the requirements of the model The rounds required for this phase is order of log base lambda of n which is a constant and the multiplicative space blow-up is a small a small polynomial in lambda Now we have a working compiler for any protocol with the short output which works in two phases First is the evaluation phase where we wrap the underlying insecure protocol in FHG Second is the decryption phase which we just went over For the rest of the talk I'll be talking about the long output protocol Let's see what happens when we try to use our current compiler with long output The evaluation phase still works without any modifications But now instead of there just being one output ciphertext for party one Every party has its own output ciphertext and this is going to cause problems in the decryption phase Let's focus on what party one would need to do in order to decrypt Like before party one will need to run a partial decryption algorithm on its own output ciphertext But now in addition party one will have to run partial decryptions for all the other output ciphertext from all the other parties What this means is that party one has to obtain ciphertext from each other party and to store these m ciphertexts Essentially what we need to do is run m instances of the decryption phase and using this strategy It's not clear how to avoid an unacceptable blow-up in the space complexity or the round complexity So it's clear we need a new approach for the decryption phase of the long output protocol And that's what I'm going to focus on for the rest of the talk The high-level idea of our approach will be that of a restricted secret key Which the parties will collaborate with each other to derive This restricted key will allow every party to decrypt its output ciphertext But will not allow any party to decrypt any ciphertext other than this In particular we need that for every efficient adversary even one that has the restricted secret key Any ciphertext other than the output ciphertexts should not reveal any information about the plaintext So what will this restricted secret key look like and how will we compute it? I'm going to describe a first attempt at constructing such a key Which will end up not working but through this first attempt. I'll still be able to showcase the general techniques we use We use several ingredients the first of which is an obfuscation scheme And we're going to assume that this is an ideal obfuscation scheme Namely that it takes a circuit and outputs an obfuscated circuit that still has the same functionality as the pre as the input circuit But hides everything about this circuit beyond the input and output behavior We're also going to use a succinct commitment Which which allows for succinct openings which prove that the commitment contains a particular ciphertext Remember that for the TFHG scheme we're assuming that there is a master secret key Which is simply the sum of the secret key shares modular some field With that in mind we're going to construct our restricted secret key as the obfuscation of a circuit Which has this master secret key hard-coded along with a succinct commitment to the output ciphertexts The circuit will take a ciphertext and a commitment opening as input if the opening is valid with respect to the hard-coded commitment The circuit will output the decryption of the ciphertext and otherwise it'll output garbage The obfuscation of the circuit will allow decryption of the output ciphertexts And it's not hard to see that any adversary which has this obfuscated circuit will not be able to obtain any information about any non output ciphertexts Since the obfuscation only reveals the input output behavior of the circuit The only way the adversary will receive a non garbage output from the circuit is if it opens if it inputs a valid opening and If it is able to produce an opening for a non output ciphertext, it will contradict binding of the commitment scheme Thus semantic security holds for all non output ciphertexts If you're familiar at all with the obfuscation literature You'll know that there is an obvious problem with this construction and that is that the obfuscation scheme is too strong Or in other words, it's impossible to have an obfuscator which hides all non input output behavior The best we can hope for is an obfuscator that satisfies the weaker indistinguishability obfuscation definition. I Won't have time to go into detail about how we fix this problem But we're still able to construct a secret key as an obfuscated circuit with the master's secret key hard coding Using indistinguishability obfuscation by using a tool called somewhere statistically binding hash functions I'll refer you to the paper for the details So now we have an algorithm which takes us input the master's secret key of this TFHG scheme and Assessing commitment to the output ciphertexts and outputs a restricted key But we're not done yet because we still have to have some way of evaluating this algorithm securely and Notice that one of the inputs to the algorithm the master's secret key can't be revealed to any party because that would completely break security So essentially what we need in order to finish our secure MPC protocol is some other secure MPC protocol for evaluating this restricted key derivation algorithm This seems like a cache 22 but but notice that the output of this algorithm is short and Remember that we already have a compiler for short output MPC protocols There's a very simple MPC protocol for the restricted key derivation which works as follows First parties collectively compute a succinct commitment to the output ciphertexts They can do this in a tree like fashion so that no party has to send too many messages in one round Then the parties collectively compute the master's secret key by summing all of their secret keys. They can also do this in a tree like fashion Finally once party one has the commitment and the master's secret key It can run the restricted key derivation algorithm and it can distribute the output to all the parties Now that we have this insecure protocol for computing the restricted key We can compile it using the short output compiler to obtain a secure restricted key derivation protocol Which doesn't leak the master's secret key to any party With that we finish constructing the new decryption phase and thus we now have a compiler for long output MPC protocols I'll end the talk by restating our results We improve upon the state of the art in the secure massively parallel computation setting by showing that any MPC protocol Can be made semi on a secure in the PKI model against all but one corruptions incurring a constant round blow-up and a space blow-up that's polynomial in the security parameter I Like to also mention some exciting follow-up work that we've done subsequently Namely, we were able to construct a compiler with the same efficiency parameters Which achieves all but one semi on a security without IO and without setup and We were also able to construct a compiler which achieves malicious all but one security Assuming a PKI With that I'd like to conclude. Thank you