 Hi everyone. Welcome to this presentation on multi-party computation with synchronous security and asynchronous responsiveness. My name is Cenda and this is joint work with Julian Loss, Wally Maurer, Tal Moran and Daniel Chudi. Let me start by recalling what MPC is about. In the problem of secure multi-party computation, there are end parties. Each party has a private input. They are connected via some communication network and want to jointly compute a function in such a way that nothing about the input is revealed. And they basically want to achieve what is achieved or what can be achieved in an ideal setting with a trusted party, even when some of the parties are corrupted. Perhaps the most widely considered model in the MPC literature is the synchronous model. Here, protocols proceed in rounds. We assume that each party knows what the current round is and in each round it reads the messages from the previous rounds, maybe does some local computation and sends the messages for the current round. A crucial assumption is that for these protocols to work, we need that messages sent at round R are guaranteed to be delivered by round R plus 1. And in reality, we can achieve this round structure assuming synchronized clocks and channels with a known delay upper bound big delta. The idea is simple. We just start round 1 at some fixed time tau 0 and then each round takes delta clocks. The synchronous model comes handy. We like the synchronous model because it allows us to achieve very strong security guarantees. Usually, synchronous protocols can tolerate a very high corruption threshold. So for example, assuming standard setup assumptions, one can achieve the strongest type of security, full security or also called guaranteed output delivery, where parties are guaranteed to obtain the correct output for any adversary that can corrupt up to two parties, as long as t is smaller than n half. And one can even tolerate an arbitrary number of corruptions if one settles for a notion of security with abort or even unanimous abort and no fairness, meaning that every honest party gets the correct output or every honest party outputs bottom, but it is not fair in the sense that the adversary is allowed to learn the correct output. Moreover, in this kind of protocols, all inputs from honest parties are taken into account for the computation. So what is the downside? When we think about running a synchronous protocol over the internet, where the actual delay is hard to predict, we have to set the round-length big delta large enough to accommodate any possible delay in the network. This means that for a synchronous protocol to actually work, the big delta has to be set much larger than the typical network delay, small delta. So the speed of synchronous protocols is proportional to the conservatively assumed worst-case delay. And in particular, this implies that they are slow when executed over the internet. So how can we design fast protocols in reality in settings where the delay is hard to predict? Well, one option is to use asynchronous protocols. In an asynchronous protocol, we do not need to know any upper-pound delay. These protocols are message-driven, and intuitively, one can think of an asynchronous protocol as a greedy protocol. The idea is that as soon as a party gets enough messages to proceed, they proceed. On the upside, this immediately implies that the speed of an asynchronous protocol is proportional to the actual network delay, small delta. But on the downside, it is well known that asynchronous protocols can only tolerate up to t smaller than n-third corruptions. This is optimal. And moreover, unavoidably, the computation can ignore the inputs of up to t possibly honest parties. And intuitively, the reason is that one cannot distinguish between a dishonest party not sending a message or an honest party that is very slow. In this paper, we investigate the natural question of whether it is possible to leverage synchronous NPC protocols to also achieve this nice feature that asynchronous protocols have, namely to achieve responsiveness, meaning that parties obtain the output at a time that is as fast as the network allows. More concretely, we investigate if there is a protocol that simultaneously is able to achieve full security with responsiveness up to small t-corruptions, similarly to an asynchronous protocol. And moreover, it should also achieve up to large t some form of extended security, which can be, for example, full security or unanimous abort. And these are the guarantees that we would expect from asynchronous protocol. So for the case where extended security is unanimous abort, this is possible if and only if large t plus two times small t is smaller than n. And for the case where full security is required as extended security, in addition, we naturally need that large t is smaller than n-half. The model that we consider is a model of UC functionalities. We borrowed the synchronous clock introduced by Katz, Maurer, Takman and Zikas in 2013. And we modeled the actual network delay with a communication network that has a delay small delta, which is unknown to the honest parties. This implies that protocols cannot use small delta. However, we assume that parties know a conservative upper bound big delta, which can be thought of as a delay or a number that is much larger than the actual network delay small delta. And about the adversary, we assume a threshold adversary which can corrupt up to F parties in an arbitrary manner and can also schedule the messages arbitrarily, but within the small delta clock ticks. And one can ask in this model, how can we preserve the same security guarantees as in synchronous protocols and also achieve some level of responsiveness. And maybe an if attempt would be to try and execute a synchronous protocol with a greedy approach. And the idea is that parties proceed to the next round as soon as they get messages from all parties. And more concretely, each party basically appends to each message its round number. And as soon as PI receives all messages from round R, it doesn't wait. It directly sends the messages for round R plus one and notifies every party I am done with round R. And as soon as a party receives I am done from every party, they continue with round R plus one. And one can see that the protocol achieves security in the sense that when parties output, they output the correct value and also privacy is preserved. And moreover, if all parties are honest, the protocol is responsive, it outputs as fast as the network allows. However, because PI doesn't know who is corrupted and who is honest, it has to wait for all parties. And this implies that a single corrupted party can make the protocol not terminate simply by not sending its messages. And as a consequence, one cannot hope to obtain any level of responsiveness so far. So let me explain the security guarantees that our protocol achieves in more detail. If there are up to small T corruptions, parties obtain all the security guarantees that one would expect from an asynchronous protocol. This means that all parties obtain a correct output value Y async, which is guaranteed to take into account the inputs from N minus T parties. That is, it achieves what we call full security with responsiveness up to T corruptions. And as a remark, note that this output in contrast to synchronous protocol may ignore the inputs of up to T honest parties. But it is easy to see that this is unavoidable if one wants this output to be fast. On the other hand, if there are between small T and large T corruptions, then parties still benefit from having extended security. Meaning that they obtain a correct output in the case of full security, or they may all obtain bottom in the case of security with unanimous abort. Our security guarantees are actually a bit more concrete in the sense that parties may all obtain an asynchronous output that takes into account N minus T inputs. Or they may also, on the other hand, obtain a synchronous output where all inputs are taken into account. But parties are able to recognize whether they obtain the asynchronous output or the synchronous one. So how do we obtain such guarantees? So for that, the idea is that we design a compiler that takes two protocols. One synchronous protocol with extended security that is secure up to large T corruptions. And an asynchronous protocol which is secure up to small T corruptions. And the hope is that the compiled protocol achieves the security guarantees from both protocols. However, the compiler doesn't really work like this. And intuitively, the problem is that the asynchronous protocol might in principle lose all security guarantees when more than small T corruptions happen. So it is hard to make use of the asynchronous component. Therefore, the idea would be to instead of taking an asynchronous protocol with security up to small T corruptions, it also achieves some level of security even if there are large T corruptions. Meaning that it actually achieves all the security guarantees in the sense that correctness and privacy is maintained. So it may not be able to obtain output in the protocol. And these two threshold asynchronous NPC protocol can be obtained by modifying existing protocols. And in our paper, we modify the protocol by Cohen, which is based on homomorphic encryption, but one can also modify other protocols to achieve this two threshold property. So in the rest of the talk, I will focus on the design of the compiler rather than the asynchronous protocol with two thresholds. Okay, so what is the idea of the compiler? The idea is actually very simple. We first optimistically run the asynchronous protocol. If there are up to small T corruptions, then we are fine and parties obtain an asynchronous output as fast as the network allows. However, if there are more than small T corruptions, it could be that the protocol doesn't terminate. So we follow the approach introduced by our compiler has an asynchronous phase and asynchronous phase separated by the timeout. The asynchronous phase has this bulb, which is initially off. And the bulb turns on as soon as the asynchronous phase gives output. If the bulb is on, the synchronous phase also outputs why a sync. On the other hand, if at the end of the asynchronous phase, the bulb is off. The synchronous phase can either output why a sync or why sync, but only one of those, not both. So how does the asynchronous phase look like? The asynchronous phase has two sub protocols. And the idea is that first parties run an asynchronous protocol, which doesn't really output the correct thing. It outputs an encrypted version of the correct output why a sync. And this I denote why a sync with the square brackets. And for that parties use a threshold encryption scheme as a setup. And to decrypt that output, we set the threshold to be say n minus T. Then the decrypt box has a task to decrypt the ciphertext. And if it succeeds, then the bulb turns on. Now let's go to the synchronous phase. This phase has also two boxes. There is the box check and the synchronous protocol. The task of the box check is to check whether the bulb is on or off. If it is on, then it must output why a sync. We should be the same output as the one that was output in the asynchronous phase. And if the bulb is off, then check can output either why a sync or bottom, but only one. And if bottom is output, then the synchronous protocol is executed and the synchronous phase outputs why sync. So this is the complete picture. How does the decrypt box work? The idea is quite simple. So when a party PI receives the ciphertext containing why a sync, it just signs it and sends the signature to every other party. And once a party collected n minus T signatures on the same ciphertext, it sends the decryption share. And once a party gets n minus T decryption shares, it can reconstruct the output. And by a standard quorum argument, if there are less than n minus two times small t corruptions, then there cannot be two lists for different ciphertexts. And if the asynchronous protocol went right, this is the correct ciphertext. So here is the condition, here is where the condition large t plus two times small t smaller than n is needed. In the check protocol, parties synchronously broadcast a list of n minus T signatures if they managed to form any such list at step two of the protocol decrypt. And then if a list is received, then everyone sends decryption shares and recovers the output why a sync. And otherwise check outputs bottom and the synchronous protocol is executed. Now if the number of corruptions is smaller than n minus two times small t and the bulb is on, meaning that a party obtain an output, then the party collected n minus T shares. This implies that there exists an honest party that sends his decryption share. So this honest party got a list of n minus T signatures on a ciphertext C. And in the check phase, this honest party will send this list, implying that all honest parties will send the decryption shares and reconstruct why a sync, which is what we wanted. For the impossibility proof, we are going to show that a protocol that achieves full security with responsiveness up to small t corruptions and unanimous abort up to large t corruptions is not possible. If large t plus two times small t is larger equal than n. And the proof is similar to the proof that a synchronous NPC or consensus is impossible above and third corruptions. So without loss of generality assume that large t plus two times small t is equal to n. And we consider the majority function. And we divide the parties into two sets of size small t and a set at the bottom of size large t. So in the first scenario, the left and the bottom sets have input zero and the right set in red is corrupted and crashes at the beginning of the protocol execution. Since the majority is zero, the majority of inputs is zero, and the protocol achieves full security, even when small t corruptions are there, then all honest parties output zero. And furthermore, in this scenario, the adversary schedules the messages between the two assets very fast, according to say some delay delta prime, which is much, much, much smaller than delta. So the time at which the parties output is proportional to delta prime. And of course, symmetrically, we can argue that if the right and the bottom sets have input one and the adversary schedules messages very fast between these two sets, then the honest parties output one, which is the majority value and at a time proportional to delta prime as well. Finally, if the adversary corrupts large tea parties, the bottom set, then it can play at the same time the first execution with input zero towards the left set of small tea parties. And also the third execution with input one towards the right set. Then if the adversary delays the messages between the two small sets by delta, effectively, since delta prime is much smaller than delta, the left set will output at a time proportional to delta prime, and will output before getting any message from the right set. This means that the left set behaves as in the first scenario and output zero, whereas the right set behave as in the third scenario and outputs one. This means that they both output different values contradicting the fact that in the protocol all parties output the same possibly bottom value. This impossibility was for the case of unanimous abort as extended security. And of course, if full security is required as extended security, then we also need that large tea is smaller than n half, but these we already knew from Cliff's classical impossibility result. Thank you very much for listening. I put here the full version of the paper.