 Hi, I'm Nathan Munnerherr, and I'll be presenting Secure MPC, Laziness Leads to God. This is joint work with Psychristina Badrugnarayanan. I use Jane and Amitsa Hai. I hope you enjoy this virtual presentation. In Secure Multi-Party Computation, there are many parties that each possess some private input, and their goal is to compute some function on their joint inputs. And so they execute some protocol, and at the end of the protocol, they should only learn the result of the function computed on their joint inputs. Now in traditional MPC, if a party aborts during the protocol, they are treated as a corrupted party. However, this is unrealistic. We view an abording party like this malicious entity that's colluding with the adversary and other abording parties. When what actually happens is there was a storm and they lost internet connection, and that's why they aborted, not that they were colluding. Honest parties may abort for a variety of reasons during a protocol execution. For example, as as we just went over, they may lose connectivity, or they may lack the computational resources to perform the desired computation, or they may simply lose interest. However, in none of these instances, is it reasonable to assume that the abording party is colluding with some adversarial entity? Thus, we wish to consider multi-party computation in a setting where abording parties are not necessarily considered corrupted, and their inputs are not discarded simply because they aborted. So how are we going to model this version that we're calling lazy MPC? Well in traditional MPC, there are honest parties and corrupted parties. And in lazy MPC, there are honest non-abording parties, and then there are honest abording parties or lazy parties that behave completely honestly, but at some point in the protocol, they stop responding. And then once again, they're corrupted parties. And for this work, we're going to focus in the standard broadcast model, and the honest behavior of a party is now to either send the honest message or abort, and we also are going to require that a party that aborts never returns. So in lazy MPC, there are going to be two phases of the protocol, an input commitment phase and a computation phase. Now, the input commitment phase is going to be independent of the function. And parties that complete this phase without abording are said to have committed to their inputs. The computation phase follows and parties evaluate the function on the committed inputs, that is, on the inputs of all the parties that successfully completed the input commitment phase. We refer to this as input fidelity. If enough parties remain at the end of the protocol, all parties, including those that aborted, should recover the output. This can be referred to as guaranteed output delivery or God. To formalize the desired security notion of our protocols, we will work in the threshold mixed adversary model. This was formally introduced by Fizzi et al. in a series of papers, and the adversary is parameterized by a tuple of thresholds, T-mal, T-semi-honest, and T-fail corrupt. These represent the number of parties that the adversary has allowed to maliciously corrupt, semi-honestly corrupt, and fail corrupt respectively. The fail corrupt parties correspond exactly to our honest, but abording parties in that the adversary can instruct them to abort at any time in the protocol, but does not learn their private input or any internal state information. Hurt et al. showed the guaranteed output delivery is only possible if the above inequality holds, that two times the number of malicious parties plus the number of semi-honest parties corrupted plus the number of fail corrupt parties is less than a total number of parties. So in this talk, we are only going to focus on the above setting where guaranteed output delivery is possible. So what did we show in this work? We gave a three-round MPC protocol with guaranteed output delivery in the plain model that is secure against threshold mixed adversaries that satisfy the previous inequality, assuming learning with errors. And in order to do this, we introduced and constructed a new primitive that we called threshold multi-key FHE in the plain model from LWE, and we also constructed a multi-string NISIC in the plain model from LWE. Now what are some of the properties of our MPC protocol? First of all, the communication complexity is only proportional to the depth of the circuit evaluated and not the circuit size. Moreover, the computation phase of our protocol is reusable. The input commitment phase consists of the first two rounds, and the third round can be reused with multiple functions to learn the function evaluations on the same party's committed inputs. Furthermore, as we discussed previously, our protocol satisfies input fidelity. Moreover, it is round optimal. A lower bound due to Gordon at all showed that two rounds is impossible with guaranteed output delivery, so three rounds is optimal. And moreover, if we instantiate the threshold mixed adversary with one that is purely malicious adversary, our protocol immediately implies a round optimal maliciously secure protocol with guaranteed output delivery in the plain model. And previously, Gordon at all had shown this in the CRS model, and in a recent independent work, Anant that all showed it from public key encryption and zaps in the plain model, just like our result, using completely different techniques from us. So how did we go about constructing this MPC protocol? Well, our starting point was to consider multi key fully homomorphic encryption, which can be used as a recipe for building MPC protocols. So in a multi key FHE scheme, there are some public parameters. And then a user can generate a public key secret key pair with respect to these parameters. Then each user can use their public key to encrypt a message and obtain some cipher text. Then given these cipher texts, it is possible to compute homomorphically on them. This is done by expanding them into some expanded cipher text with respect to all the public keys, and then evaluating some function homomorphically to get this evaluated cipher text. Then each of these parties can take the evaluated cipher text and use their secret key to obtain some partial decryption. And then given these partial decryptions, anyone can perform some final decryption procedure and recover the function computed on the inputs. Moreover, we can consider multi key FHE with this distributed setup. In this situation, each party will first output some parameters, and then the public parameters of this scheme will simply be the concatenation of these parameters. Now multi key FHE was used in BHP 17 to build a three round semi malicious secure protocol. So how was this done? In the first round, each party generated the public parameters and sent them out. And in the second round, each party used the public parameters to generate a public key secret key pair, encrypted their input and broadcast the cipher text. In the final round, everyone expanded their cipher texts and evaluated homomorphically to obtain an evaluated cipher text, and then computed their partial decryption and outputted it. And now using the final round, everyone has all the partial decryptions and can recover the output. Now why isn't this lazy? Suppose an honest party had a board in the last round, so then outputting a partial decryption. Then nobody can recover the output. Crucially, we need a partial decryption from every party in order to decrypt. Thus, multi key FHE does not suffice in order to construct a lazy multi-party computation protocol. To deal with this, we introduce a new primitive that we call threshold multi key FHE. So in order to build lazy NPC, we want each party to encrypt under their own public key. However, we also only want some of the parties to be needed to decrypt. So how are we going to define such a primitive? Well, as a first attempt, we could basically do the same thing as multi key FHE. We could have some public parameters. Everyone generates a public key, secret key, pair, encrypt their input, can be combined and homomorphically evaluated to get some evaluated cipher text, and then say we only need two parties partial decryptions to recover the output. That is party one outputs P1 partial decryption and party two outputs P2 as partial decryption. And then anyone given these partial decryptions can recover the output. However, this provides no security. In particular, given CT1, the ciphertext of the first party, anyone could simply generate two public key pairs, encrypt whatever they wanted, compute the function that just outputs x1, and then use their two secret keys to determine two partial decryptions, which would allow them to recover x1, completely breaking the security of the scheme. So observe that the ability to combine ciphertext encrypted under different keys had compromised security. So what if we encrypt under a set of keys rather than a single key? So in threshold multi key FHE, we define it as follows. There are some public parameters that every user generates a public key, secret key pair. Now it turns out, crucially for our scheme, that in threshold multi key FHE, the public key, secret key pair of each party can be generated independently of the public parameters. Then each party will take the public key set, all the public keys, and encrypt their input with respect to this public key set. Then as before this ciphertext, the ciphertext can be computed upon homomorphically, and then given a couple partial decryptions, say two, anyone can perform some final decryption procedure and recover the output. Furthermore, since we want to work in the plain model, we consider threshold multi key FHE with distributed setup, that is each party can output a parameter string, and then the public parameters are the concatenation of the strings. Now, once again, I'm going to emphasize this. In our definition of threshold multi key FHE, the parameter string and the public key, secret key pair of each party are independent, whereas in multi key FHE, the public key, secret key pair is generated with respect to the public parameter string. So how do we go about constructing threshold multi key FHE? Well, the tools we're going to use are multi key FHE with distributed setup from BHP 17, threshold FHE from BGG plus 18, and public key encryption. All of these can be built from the learning with errors assumption. So in threshold FHE, there's a public key and a secret key and the secret key is shared among parties. Then each party can encrypt their input with respect to the public key to obtain some ciphertext. These can be computed upon homomorphically to obtain some evaluate ciphertext. And then each party can use their secret key share to give out some part for decryption, which can be combined to cover the function evaluation in the clear. Now, crucially, to decrypt, we only need partial decryptions from some of the parties. In particular, if there are n parties, and we had secret share the secret key using a T out of n secret sharing scheme, then we would only need partial decryptions from T of the parties in order to decrypt. However, in a threshold FHE scheme, everyone must encrypt under the same public key. So using these primitives, we are now ready to describe reconstruction of threshold multi key FHE. The distributed setup procedure, this is what outputs public parameters is to simply run the multi key FHE distributed setup procedure. The key generation procedure is to simply use a standard public key encryption scheme and generate a public key secret key pair. Note that the key generation procedure does not take the public parameters from the distributed setup as input. Now to encrypt, what one will do is they'll use the key generation procedure of the underlying multi key FHE scheme to generate a public key secret key pair of the multi key FHE scheme called FPK FSK. And then they will secret share FSK with respect to the access structure. So say it was a T out of n access structure, threshold access structure, then you'll secret share FSK with respect to this T out of n secret sharing scheme. And then one will encrypt the ith share FSKI under the ith public key PKI. Once this is done, the encryptor will then encrypt their message X under the multi key FHE scheme. The ciphertext of the threshold multi key FHE scheme will consist of the multi key FHE ciphertext of X under FPK along with n public key encryptions of the secret key shares of FSK under the appropriate public keys. Now for the evaluation procedure, one simply runs the multi key FHE evaluation procedure on the multi key FHE components of the ciphertext and leaves the others untouched. To perform a partial decryption, a user possessing the ith secret key is able to decrypt the public key encryptions that encrypted the ith shares of each of the underlying multi key FHE secret keys. These can then be concatenated in use of the secret key for multi key FHE partial decryption. And then for the final decryption, one combines the partial decryptions according to the reconstruction procedure of the access structure under which the secret keys were shared. Now, why does this work? Well, for one, the secret key of the expanded ciphertext in the multi key FHE scheme is simply the concatenation of the secret keys in the multi key FHE scheme. Secondly, each party that needs to perform partial decryption is able to possess secret key shares for every single multi key FHE secret key that goes into the expanded ciphertext. Furthermore, the secret sharing scheme is linear, in particular if it's a t out of n access structure, it's linear. And finally, the multi key FHE decryption procedure is linear. So to illustrate this graphically, let's consider the following example with four parties. So here the access structure is P1 and P2 or P3 and P4. So in the multi key FHE scheme, there will be some underlying secret. And when we encrypt, we will secret share it according to the following procedure where the first two shares sum of the secret as to the third and fourth shares. Now, in our special multi key FHE ciphertext, there will be a multi key FHE component that is expanded upon and evaluated homomorphably. The expanded ciphertext is an encryption with respect to the following four public keys, one for each party that are concatenated together. And the decryption procedure is a linear computation that takes the concatenation of the four secret keys and computes a linear operation with them in the ciphertext. Now, the way our special multi key FHE scheme worked is due to the party one possessing the first secret key of the public key encryption scheme, they're able to recover the first share of all four of these multi key FHE secrets. And the second party is able to recover the second share of all these multi key FHE secrets. Now, since the first and second shares sums of the original, if each party performs a linear operation, then these resulting computations can also be summed to recover the message. Thus, only parties one and two are needed for decryption. Now, our threshold multi key FHE scheme will immediately give us a three round lazy MBC. Now, how does this work? Well, in the first round, each party generates a public parameter string and a public secret key pair and broadcast the parameter string and the public key. Recall that the public key CP key generation did not depend on the public parameters of the scheme. So this can be done. In the second round, each party will concatenate all the public parameter strings to obtain the public parameters. And then it will encrypt its input using all the public keys and the public parameter string. In the third round, each party will evaluate the function on the ciphertext to get this expanded evaluated ciphertext, compute the partial decryption using its secret key, and broadcast this partial decryption. We refer to rounds one and two as the input commitment phase. And the final round is the computation phase. Observe that do the properties of threshold multi key FHE. If everyone was encrypting using a t out of n threshold access structure, then one only needs t partial decryptions at the end in order to recover the output. And particularly we can prove that this is secure against threshold mixed adversaries. If the threshold mixed adversaries only allowed to make semi malicious corruptions instead of fully malicious corruptions, that is, it has a tuple of semi malicious corruptions, semi honest corruptions, and fail stop corruptions. Furthermore, the protocol satisfies reusability since the third round can be repeated with many different functions by the properties of fully homomorphic encryption, which allow for computing different functions on the same ciphertext. Additionally, if the number of parties that remain at the end of the computation satisfy the access structure, then anyone can use the transcript of the protocol to recover the output. And this will be the case if the inequality required by a threshold mixed adversary, that is the inequality for which guaranteed output delivery is possible is satisfied. In order to obtain security against malicious adversaries, let's make some observations about the previous protocol. It turns out that the lazy NPC protocol is actually secure against a malicious adversary in the first round. That is an adversary that is allowed to behave maliciously in the round one, but then can only behave semi maliciously in the second and third rounds. Now, why is this? If we go back to the protocol in the first round, each party broadcasts a public parameter string and a public key. It turns out the public parameter string of the underlying multi-key FIG scheme is simply a random string. And if we use a public key encryption scheme where any string is a valid public key, and it turns out that malicious and semi malicious adversaries are actually identical in the first round, because anything a malicious adversary can do, a semi malicious adversary can do as well. Thus, our protocol is secure against this malicious round one adversary. Since it's secure against a malicious round one adversary, we could attempt to use a NISIC and use the first round to transmit some CRS in order to get maliciously secure protocol in the plain model. It turns out there exists primitive called multi-string NISICs that work with the majority honestly generated strings. What this means is that if you have a bunch of parties and they each output some string to be a CRS, and we can catenate all the CRSs, we obtain a valid NISIC provided that a majority of these CRSs that were generated were generated uniformly and random. However, it turns out that a majority of the strings will be honestly generated whenever this inequality holds, which is when guaranteed output delivery is possible, and is exactly the case that we're considering. Thus, a multi-string NISIC would suffice to obtain an MPC protocol that was secure against a malicious threshold mixed adversary as desired. So the final step, if we want to only assume learning with errors, is to construct a multi-string NISIC from LWE and due to time constraints, I'll refer you to the paper for details on how we did this. So in summary, we built a three-round MPC protocol with guaranteed output delivery in the plain model from LWE that's secure against a threshold mixed adversary when the following inequality holds, which is the condition when guaranteed output delivery is possible. And in order to do this, we introduced and constructed a new primitive called threshold multi-key FHE in the plain model from learning with errors and built a multi-string NISIC from LWE. Thank you.