 Sandbrough asynchronous multiparty computation based on one-way functions by Sandro Coretti, Juan Gare, and Martin Herd, and Vasile Ciccas, and Juan will give a talk. Thank you. Hello everybody. So this is constant round asynchronous multiparty computation based on one-way functions. I'm going to work with Sandro Coretti, Martin Herd, Vasile Ciccas, and I just noticed that Vasile Ciccas' name is in a smaller font. Do you see that? That's not done on purpose, and I hope Vasile Ciccas is not watching, but he cannot do anything about it, so we'll continue. All right, so second multiparty computation, we already saw some definitions. We are talking about mutually distrustful parties trying to compute the function of their inputs, and the idea security-wise is that these computations should emulate the situation when we have a trusted party performing the computation for the parties. Okay, that's what we call these days the simulation-based paradigm, where you would have this ideal world here with a trusted party doing the computation and the real world where the protocol is being run. A distinguisher could not figure out, you know, which world the computation is happening, so it's called the simulation-based paradigm, and in fact, more than that, it's universal, it's universally composable in the sense that then if you have this security definition, you can have this ideal functionality, okay, and any protocol that realizes functionality can be plugged in in other protocols, and those protocols can be running concurrently in very complex environments. So that's the UC framework simulation-based security, and typically, all these protocols are designed and analyzed in what we call a synchronous communication network, okay, where each party is connected by secure channels, and this is an assumption that we're going to be making now for simplicity, but typically, you would just need reliable and authentic channels, and you can do security, you can implement a secure aspect if you are in the computational setting. So in this synchronous communication network setting, the protocol proceeds in rounds, and messages sending one round are guaranteed to arrive in the next round, okay? So that was the synchronous setting. We mentioned UC, turns out that this plain UC framework is incredibly asynchronous, okay, in the sense that the adversary has full control of a message delivery between, even between honest parties, and there is a, in fact, there is a synchronous version of UC, okay, introduced by Katz, Maurer, Tagman, and Zika, okay, which makes the UC framework synchronous and therefore easier to, you know, design protocols for analyzed security and so forth, okay? So because, you know, synchronous network is great for analysis, and how would you implement this in practice? It would be, you know, you would assume that parties participants are more or less synchronized clocks, and there is a time bound on the message latency, okay, and then you would be, you would have a round, but typically this round, this is, you know, supper bound on the latency would be higher than the average transmission time, so that's one drawback. On the other hand, we mentioned the UC framework, which is totally asynchronous and overly pessimistic, and in fact, there might not be a reason for that, because, you know, just give you this quote from the blockchain era that says, you know, information is, it diffuses, it's easy to, to spread and hard to stifle, and everybody knows who said this, blockchain era, all right? So this to motivate that, you know, you see the asynchronous network is overly pessimistic, okay? So in fact, what we would shoot for, and this, what we're doing in this work, is that messages, you know, this network is asynchronous, there is no, you know, synchronicity assumption, but messages get delivered eventually, okay, where, so in this network, the adversary may delay messages by an arbitrary, by finite amount of time, it might be able to reorder messages, okay, but there's no deletions, things are, you know, eventually gonna get through. Okay, and in fact, this is the model that was typically considered in early works by, in this full-tolerant distributed computing, so you might be familiar with this, the famous impossibilities of a fish, fish or lynch and Patterson, and in fact, in asynchronous NPC by Menor et al. Okay, so in this sense, this asynchronous network with eventual delivery is opportunistic because you're not gonna wait for the maximum, you know, delay to move to the next round, but things are gonna, you know, as soon as they can, the message will arrive, and in fact, we noticed that this type of network, this capability had not been modeled in UC, okay, which is one of the things we do, this is not our main result, but we need this tool to be able to say formally what we achieve. Okay, so we formalize one contribution is to formalize this asynchronous model with eventual, eventual delivery, when you see framework. For this, we need the notion of asynchronous and complexity, and also, we have to model what the basic communication of resources in this framework will be, and those are a secure channel, yes, I say, instead of secure channel computational setting, you can think of reliable and authentic channels, and broadcast type functionality, which is asynchronous Byzantine agreement, okay, and it's worth pointing out here that in the synchronous setting, you would typically assume a broadcast functionality, right, you have like point-to-point communication, and you have broadcast functionality. Turns out that in this world, broadcast is not achievable. Okay, essentially, if you have a distinguished sender, you cannot wait for the sender because you don't know if the guy is late or is being delayed, but what is achievable is the Byzantine agreement, everybody has an input version of the problem, okay, and it is the broadcast like communication resource for this type of network, this type of setting, okay, so once we have a little, we have done the modeling for this asynchronous model with eventual delivery, we come to our main result, which is the constant round MPC circuit multiplication protocol, and by constant round, we mean that the brand complexity is independent of the circuit's multiplicative depth, based on the standard assumptions, PRFs, tolerates up to a third of corruptions, and it turns out that this is optimal in this asynchronous setting, and it also tolerates an adaptive adversary, which means that adversaries may corrupt parties, they don't have to commit to which parties to grab a beginning of execution, but this is a dynamic type corruption situation, okay, so those are the two things that we do, so let's see what the situation was before this, prior work on constant round MPC protocols in the synchronous network, we have a bunch based on circuit garbling, as we just saw, we have more based on FHE, this is due to Azure of it all, and in this setting, you can tolerate up to a half of corruptions, okay, and here you also have to assume, remember I said in synchronous networks, broadcast works, but if you want to do it constant round on a point to point setting, there's, you know, you have to settle for expected constant round, okay, for these primitives, I mean, you can assume it as a resource, and it should be just invocation, but this is one round, but if you want to implement it in a point to point network, that is expected constant, and this was noticed early on, in particular by, we had a paper in crypto formalizing this aspect, okay, but the bottom line is that in the synchronous world, so constant round MPC protocols existed, as opposed to in the asynchronous model with eventual delivery, our model, until this concurrently independent work by Rand Cohen in this past PKC, which shows how to do asynchronous MPC based on FHE, okay, and in fact, that's why our paper now is called based on one-way functions, because you ran already show how to do it based on this stronger assumption. This protocol today is number three corruptions, which we said is optimal, but withstands, is a security and static adversaries, and also as ours, assume this resource asynchronous business agreement, okay, so this was the situation. So far, and there are other known protocols, but for asynchronous MPC, okay, but the run complexity was proportional to a death of a circuit, okay, so until this result of this year, there was a gap between synchronous and asynchronous, okay, so let me tell you a little bit about how we formalize this eventual delivery capability in the UC framework. So one first resource is what we call the asynchronous secure channel, okay, and here you have a sender, a receiver, okay, and the secure channel functionality stores messages and might maintain some delay, okay, so it's a fixed integer, okay, that the adversary is going to be able to manipulate, okay, the adversary is going to be able to tell this, intuitively, this is the delay in the number of operations that this functionality is going to wait until delivering a message, okay, and these things work in a fetch mode, okay, if you are supposed to receive a message according to the protocol, you're going to keep asking the functionality, you know, do I have a message, do I have a message, all right, the adversary can manipulate that, but up to T because then polynomial time adversary is going to be running out of time because it's how we model asynchronous secure channels, all right, and then we can formulate the notion of protocol execution in this model where the part is going to be sending messages using this resource and then polling for messages, okay, so naturally you can now define the notion of round complexity in this setting as the number of times, the maximum number of times that protocol switches between sending and fetching, okay, that's the notion of round complexity for asynchronous NPC, so that was a secure channel, similarly we can talk about asynchronous secure function evaluation, okay, where the functionality is going to collect all the inputs, all right, and then as when the computation is performed, everybody provides inputs, then the adversary might be able to influence it, well, I'm going to increase the delay, you know, increase the delay or reduce the delay, but it cannot do it arbitrarily because it's going to be running out of time, okay, and importantly in this setting, there is no input completeness in the sense that not all, not all honest parties are going to be able to provide inputs because you cannot wait for some of the end, you won't be able to distinguish if some party is late or is corrupt, okay, but you can agree on a core set of parties are going to be providing this input, okay, that's fixed, and that's the computation that's going to be performed, the other parties are going to be assigned a default value, okay, this is different from the single setting where all the honest parties inputs are going to be taking into account, okay, and similarly we mentioned asynchronous business agreement as a resource, you know, shares the same profile with asynchronous SFV in the sense that it's going to be collecting inputs, okay, and if all the inputs are the same of this core set, that's going to be the outcome of this broadcast-like functionality, and if the inputs of the honest parties differ, you know, it's going to provide some value provided by the adversary, okay, but it's going to be consistent, everybody's going to see the same value, okay, so we model the communication resources for asynchronous MPC, now we're going to go to, we're going to see how to build a constant-round asynchronous MPC protocol, constant-round means the rank complexity is independent of the circuits of that, based on assumptions, as I said, tolerates a third number of interruptions, it's unsecured against an adaptive adversary, which I'm repeating here, okay, and the function, we're going to be assuming that it's specified by a Boolean circuit, and protocol overview, the protocol is going to consist of three phases, in one phase we're going to be computing, in the first phase, a distributed version of a garbled circuit as we just saw, or a variant of it, okay, but the sort of pre-computation, this garbling phase, we're going to be, it's going to be a constant def function, okay, this is basically, well, we're going to garble things, we're going to be trying to randomness, okay, this can be done in constant time, constant number of rounds, and for this, we're going to be using a protocol by Benoar, Kelman, and Wraving, which if you're familiar with the literature, it's an unconditional, it's an information theoretic secure protocol for asynchronous networks, models, okay, but same as, so this is the asynchronous version of BGW, the information theoretic MPC protocol, and as such takes, you know, the number of rounds is linear in the depth of the circuit, okay, so that's one thing, except that for this pre-computation phase, because this function is constant depth, we don't care, it's still going to be constant, okay, so that's one thing, the other thing is, if you're familiar with this protocol, these protocols work on arithmetic circuits, and I said we're going to be working on Boolean circuit representations of functions, so we're going to have to do some tricks to adapt this protocol to our setting. After running this, we're going to be a phase two, where players are going to be complete this phase, circuit garbling, and finally phase three, parties are going to be computing this garbled circuit locally, okay, so we said Boolean circuits, circuit garbling, let me remind you a little bit what this is, so we have this Boolean circuit represented the function, and for each wire, we're going to have a mask, a bit, MW, and two keys, you know, depending on the value of that bit, and then every circuit is going to be evaluated, maintaining the invariant, that if the mass value is Z, then one key is going to be known, and the other key is going to remain secret, this is a traditional version, a variant of the threshold, yeah, a garbled circuit approach, and this can represent it like this for a generic gate, these are going to be the mask values, okay, oh, and we're going to be using a circuit that only uses NAND gates, NAND is a complete gate, so we can just do all the, you know, just use NAND gates, so here, for each value, each mask input values, what we're going to be doing is first unmask the inputs, you know, perform the computation, and mask them again, okay, and then the garbled entry is going to be the encryption, double encryption using the two corresponding keys of the mask output, and the key corresponding to that wire, okay, I'm not simplifying notation here using Z for all the outputs, but it would be corresponding to each row, okay, and that's pretty much what I'm saying here, okay, and so A and B are the two input wires to the gate, then C is the output wire, okay, so it's the basic YAL circuit garbling approach. Now, I mentioned that we were using this big, big AR, NPC protocol to do things, right, so one might wonder, well, you have the, you can do this, you can probably do the, you know, encryption, evaluate the software using the same protocol, so one issue is that, well, that's going to be a huge circuit non-assolid constant, and the other issue is it will not be black box, okay, so what we use is a distributed encryption approach due to formalized by Damgar and Ishai, which, if this is the regular encryption formulation, the distributed encryption is as follows, instead of just one key, assume n keys, one for each party, if you're trying to encrypt some message m, you seek a share m, and then give that share to the ith party who is going to encrypt it and send it to everybody. Now, assuming everybody has, at some point, all the keys, okay, they're going to be able to decrypt and make sure that reconstruct and seek a share m, and that would be the outcome, okay, so this was circuit gobbling with distributing encryption, so before we saw for each wire, we had two keys, now we're going to have two key sets for each wire, one key for each participant, and the invariant is going to be similar, that if the mass value is z, then one set is going to be known, one set of keys is going to be known, and the other one is going to remain secret, okay, so this was gobbling without distributing encryption, and this is with distributed encryption, which is similar, except that here, what we represent by this, the secret sharing of the outcome and the corresponding sets of keys, okay, so this is going to be done by this BKR protocol that I mentioned, all the shares are going to be sent to this preprocessing for each gate, for each table, to all the parties, and all that process is a constant depth function, okay, so this is the BKR protocol that's going to be choosing mass and subkeys, it's going to be computing this secret sharing of all the tables, and it's going to giving the parties the right shares of things, okay, now so there are a couple of things that we have to take care about here, one is that what I mentioned, we are going to be using this protocol to do the evaluation, this is linear depth, but this is a constant depth circuit function, and the more, the tricker one is that we are talking about Boolean circuit, and this BKR protocol is for arithmetic circuits, so we have to make sure that, you know, we can do, we can compute the arithmetic circuit, this NAND operation, this is easily done by having this arithmetic operation in the circuit, except that now you have to make sure that all the inputs are one or zero, right, and there's another technique we can use to make sure that corrupt parties don't deviate from that, that all values are input are ones and zeros, and there's another technique to achieve this, and if that part, you know, when you do that in the beginning and if the party doesn't do that, you just replace this input value by a sharing of zero, right, so I'm out of time almost, okay, so we do all the sharing, and then parties start encrypting, you know, with their own keys, with their own shares of keys, shares of the values they have and send to everybody, okay, and remember in the output table, we have shares of keys that are needed for the next wire, okay, so things diffuse, break through the circuit, okay, now once all that happened, players are able to compute, to evaluate this function, you know, locally, given that they were able to reconstruct all the keys from all parties and all the shares, okay, so this, why does one encrypt things and not just seek the shares, if the reason is you just send stuff that can be decrypted that opens up just one row of the table, okay, so, and you do, you wait until you have the enough shares that lie on the, that are inconsistent, lie on the right polynomial, okay, just to recap, we presented a protocol, constant round protocol based on one-way functions, one-way functions because this encryption is based on, the only operation that we have here is encryption that can be based on one-way functions, there's good potential security against adaptive adversaries of the order of players, constant round and it's a black box of one-way functions, and the full version is in the print, that's it, thanks. So we have time for one quick question, if no one again.