 Hi, my name is Chenda, and I'm going to talk about always have a backup plan, fully secure synchronous MPC with asynchronous fallback. This is joint work with Erika Bloom and Julian Los. The paper is on secure multi-party computation, or MPC. At a very high level, MPC allows a set of parties, each with a private input, to jointly compute an arbitrary function in such a way that nothing about the inputs is revealed. Of course, beyond what is revealed, play the computed output itself. The parties want to achieve what can be achieved in an ideal setting with a trusted party. And this is especially difficult because some of the parties might be corrupted. Very roughly, protocols for MPC can be classified according to the underlying communication model. On one hand, we have the synchronous model, which assumes that parties have access to synchronized clocks, and also parties know an upper bound on the network communication delay. That is, when a party sends a message, it is guaranteed to be delivered within a known quantity delta. This model, although widely used in the crypto literature, is not very realistic. Consider, for example, a setting where the network delay is unpredictable and gets large at specific points in time. Maybe the weather is bad, or maybe the communication network is under attack. Then, synchronous protocols lose all the security guarantees, which is highly undesirable. A much more realistic model is the asynchronous model. This model does not make any assumptions on the synchrony of the clocks and only uses the fact that messages sent by honest parties are eventually delivered. So why do we design synchronous protocols? I guess one of the main reasons is that they achieve very strong security guarantees. Assuming standard setup assumptions, it is known that synchronous MPC protocols can tolerate up to T smaller and half corruptions. And allow every party to give input. In contrast, asynchronous MPC protocols can only tolerate up to n-third corruptions. And unavoidably, the inputs of up to T parties are ignored. What does this mean? Formally, this means that the adversary can choose up to T inputs and substitute them by a default value of both before the output is computed. So it would be great to have the advantages of both models, namely to design a single protocol such that when the network is synchronous, it achieves a very strong security guarantee. And even when the network is asynchronous, it also achieves reasonable guarantee. And the question is not only motivated by theory, but also the real world. Imagine a setting where the network conditions fluctuate, but are mostly stable. In periods where the network delays are stable and within delta, our protocol achieves synchronous strong guarantees. And even if parties experience a short outage, our protocol still achieves asynchronous guarantees. More concretely, we would like to have input completeness and tolerate up to TS corruptions when the network is synchronous. And even when the network is asynchronous, we would like to at least tolerate TA corruptions. Of course, allowing some of the inputs to be ignored. So we answered the question by showing that such a protocol exists if and only if TA plus two TS smaller than N and the number of ignored inputs is at least TS. That is, we cannot guarantee to ignore less than TS inputs when the network is asynchronous. So we are not the first to ask this question. The literature on hybrid security guarantees is extensive, so we defer a detailed related work to the paper. I guess the most closely related work is the recent work by Bloom, Katz and Loss on achieving such trade-offs for the case of presenting agreement protocols and also later extended to the problem of state machine replication. Work mentioning is also the work by Hird, Nielsen and Bartosz, which provide an asynchronous NPC protocol for up to m3rd corruptions with the feature that when the network is synchronous, all inputs are taken into account for the computation. So let's start with the feasibility result. We make use of a core sub protocol, which we call SMPC. This is an NPC protocol which achieves all the security guarantees we expect when the network is synchronous. But in addition, still achieves reasonably strong security guarantees even when the network is asynchronous. In this case, the protocol allows all honest parties to give a valid output YA with up to L ignored inputs or all honest parties output BOT. So there is agreement on what the output is. We can then use this strong sub protocol with any asynchronous m3rd NPC protocol to get the guarantees we want. The idea is simply to first run the SMPC protocol and then run the asynchronous NPC protocol if the output is BOT. So let's see if the network is synchronous, the security guarantees are inherited from the sub protocol SMPC. And if the network is asynchronous, either all parties obtain an asynchronous output YA that can ignore up to L inputs, so we are fine. Or all parties obtain BOT, in which case parties know the network is asynchronous. So they can all execute a traditional NPC asynchronous protocol, so we are fine as well. So let's get into the sub protocol SMPC. The protocol uses a threshold comomorphic encryption scheme. And this is a public key encryption scheme with the feature that the secret key is distributed among the parties. All parties have a public key EK and each party PI also has a secret key DKI. With the public key, any party can compute an encryption. The encryption is homomorphic in the sense that given two ciphertexts, one can compute a ciphertext containing the addition of the corresponding plaintexts. One can then compute a decryption share from a ciphertext. And given enough decryption shares on the same ciphertext, one can reconstruct the corresponding plaintext. And in our protocol, the number of decryption shares needed to reconstruct will be TS plus one. The sub protocol SMPC follows the CDN approach, Cramer-Danvers-Nielsen approach, based on threshold homomorphic encryption. So the CDN protocol has three phases, which roughly proceed as follows. In the first phase, each party PI encrypts its input with the threshold encryption key and broadcasts the ciphertext. The parties then jointly evaluate the circuit. The addition gates are evaluated using the homomorphic property of the threshold encryption scheme. And the multiplication gates are performed using a distributed protocol. Then after the circuit evaluation, each party holds an encryption of the output. And then each party computes a decryption share and distributes it. And then parties can jointly reconstruct the output. Of course, to achieve security against a malicious adversary, parties need to make use of zero-knowledge proofs in several steps of the protocol. And the CDN protocol was designed under asynchronous network. And intuitively, it works because honest parties have agreement on the ciphertext to decrypt after the circuit evaluation. And also no crucial information is revealed throughout the execution of the protocol. When the network is asynchronous, however, several problems might arise because agreement is lost in critical points of the protocol. For example, when parties broadcast their input ciphertext, it is possible that different parties receive different sets of inputs. So if they evaluate these, different parties will end up with different ciphertexts, which if decrypted will lead to the adversary learning different outputs and breaking privacy. We address these problems by using several primitives that guarantee different properties depending on the communication network. In this talk, I will only introduce two such sub-protocols. And this will serve to get a high-level idea of our protocol. The first protocol is a broadcast protocol that achieves all the security guarantees when the network is synchronous, but also achieves so-called weak validity when the network is asynchronous. Meaning that when the sender is honest, its recipient outputs the sender's input or both. Such a protocol can be achieved using a dollar-strong approach. The second primitive is a so-called asynchronous common subset protocol. And this primitive allows each party to give inputs and agree on a common subset of the inputs. We need that if the network is synchronous, some sort of validity is ensured. This means that if all honest parties give the same input value, then the output is a singleton containing this value. Also, when the network is asynchronous, all honest parties have consistency, meaning that they all output the same set of values. And moreover, this set contains at least the input of an honest party. Such an ACS protocol can be achieved using the traditional Benor-Kelmer and Rabin approach, later modified by Blum-Cuts and Loss, where they give a twist to the traditional protocol to achieve higher validity, meaning that it holds even when there are up to TS corruptions. Now we can plug in the described primitives into the CDM protocol. So in the input distribution, parties use this enhanced broadcast primitive and expect to obtain at least N-TS good ciphertexts. For this, parties wait for a time T, which is an upper bound on the execution time of the broadcast protocols when the network is synchronous. If an honest party didn't receive these many good ciphertexts, it simply skips the circuit evaluation and starts the ACS with both as input value. Otherwise, parties evaluate the circuit as before. And after this, instead of decrypting, they jointly execute the ACS protocol with the output ciphertext as input value. Parties then obtain a set of ciphertexts. If the set is a singleton, then parties proceed as in CDM, as described before. That is, parties jointly decrypt the ciphertext and output the decrypted value. Otherwise, if the set contains more than one value, all parties output both. So note that when the network is synchronous, the protocol proceeds similarly to CDM. All parties obtain the same output ciphertext, and the ACS will output a singleton with this ciphertext, which will be decrypted. And when the network is asynchronous, the ACS guarantees consistency. So all honest parties obtain the same set as output, which contains the input of at least an honest party. So either the output is a singleton set, which contains the output ciphertext proposed by an honest party, in which case it contains n-ts inputs. So we are happy. Or the ACS outputs more than a value, in which case the output of sNPC is both. So we can evaluate the asynchronous MPC protocol, as described before, in the compiler. So we talked about visibility, and now we proceed to the lower bounds. The first lower bound says that it is unavoidable to ignore the inputs up to TS parties. And this holds independently of what the corruption threshold is in the asynchronous case. That is, even when TA is equal to zero. The function that parties wish to compute, and the one that we consider, is the OR function. So consider a scenario of the protocol execution under asynchronous network, where parties are divided into two sets. The first set in red contains TS corrupted parties, which crash at the beginning of the protocol execution. The second set contains n-ts honest parties, all with input zero. Because the parties are computing the OR function on the receipt inputs, and the protocol is secure up to TS corruptions, all honest parties output zero. Now consider a scenario where the network is asynchronous, and all parties are honest. The first set of parties has as input one, whereas the second set has as input zero, as before. The adversary, however, delays the messages between these two sets. Since the parties in the second set cannot distinguish between being in the first or second scenario, all parties in the second set output zero as well, in the asynchronous case. But this contradicts the fact that the output ignores less than TS parties. If the input of any party on the first set is taken into account for the computation, the output would be one. The second lower bound is inherited from the lower bound presented by bloom cuts and loss for Byzantine agreement. Here parties compute the majority function. And we divide the parties into three sets of sizes TS, TS and TA. So in the first scenario, if TS parties are corrupted and crash, and all honest parties have zero as input, the output is zero, because zero is the majority value. And the same argument holds symmetrically when the input is one for the other sets. So now, consider a scenario where the adversary corrupts TA parties, and also in addition delays all messages between the upper two sets. The adversary simply plays the two strategies as in the synchronous execution, with input zero towards the left set, and with input one towards the right set. Since the upper sets have the same view as in the synchronous execution, the left set outputs zero, and the right set outputs one. But this contradicts the fact that parties should get the same value, since they compute the majority function over the same set of inputs. And note that this holds even when all the inputs are ignored. So thank you very much for your attention, and this is all from my side. Here you can find the references and the link to the full version of the paper. And I hope to see you all at the virtual conference.