 So, hello everyone, my name is Yi, and today we'll be talking about wrong-efficient secure multi-party quantum computation with identifiable words. This is a joint work with my advisor Kai Bin, and with my friends and colleagues, Bar, Hao, Mi Ying, and Yixing. So let's start with multi-party quantum computations. So here we have n parties, and the goal is for them to jointly compute a quantum circuit. So this circuit takes n inputs, so one from everybody, and it also has an output, so one for everyone. So at the beginning, every party holds their private inputs, and then they run some protocol. So they exchange some messages that can either be quantum or classical, and then at the end of the computation, every party gets their own output. A common security notion is called security with a board, which intuitively means that everyone learns only their own output, unless the protocol affords, in which case the honest parties would not get any output. Okay, so DuPois, Newton, and Samuel constructed such a protocol that satisfies security with a board. And similarly, for this more recent work, by Dulac, Brillo, Jeffrey, Mahans, and Schaffner. And well, this security notion is good, but there's an obvious weakness is that a protocol may afford, particularly the adversary might choose to abort a protocol whenever it feels like, and when that happens, we call it a denial of service attack. It's also well known that this type of attack cannot be prevented with the dishonest majority. And like I mentioned, when it does happen, the honest parties get no output. But because we are working under the plumbing setting, there is an additional issue, which is that all of the quantum inputs would be constant and lost due to a no cloning theorem. So here, of course, a denial of service attack, like I mentioned, it cannot be prevented. But still, we want to ask, is there still anything we can do about this? It turns out the answer is yes, because there's this other security notion called security with identifiable abort. So roughly, in instead of a protocol affords, everyone at least knows who to blame. So everyone knows who is causing the abort. So this notion was introduced by Isshai, Astrosi, and Zikas. And classically, it was satisfied by the GMW protocol, and their high-level idea is to use broadcasts and ZK-proofs so the honest party can prove to everyone that they did what they're supposed to do. But of course, now we are under a quantum setting, and we cannot broadcast a quantum state because, again, there's no cloning theorem, so broadcast does not work in quantum, and therefore it is unclear how to achieve the derivative identifiable abort from existing constructions, like I mentioned on the previous slide. And this is exactly our contribution. So our contribution is that we construct a protocol for computing any multi-party quantum circuit with identifiable abort using this primitive. So the first primitive we use is a classical multi-party computation with identifiable abort. And the other primitive we use is called a verifiable quantum full homomorphic encryption scheme, which was proposed and constructed by electric at all. Okay, and it's also worth mentioning that our protocol is wrong-efficient in the sense that the number of wrongs in our protocol with quantum mysteries does not depend on the circuit. But I want to clarify that this does not mean we have constant wrongs because our number of wrongs still depends on the number of other factors, such as one, the wrong complexity of this, and two, the number of parties, and three, the security parameter that we choose. So we do not have constant wrongs as opposed to this other concurrent work by Parthusset, Claude D'Angelo, Kurana, and Ma. And in fact, this concurrent work is also presenting in this conference, and they have a constant wrongs protocol for a multi-party quantum computation that they do not have identifiable abort. Okay, and the last thing that is worth mentioning about our protocol is that it is fair if we're underlying classical NPC if this thing is also fair. And what we mean by fairness is that either everyone gets their output, or nobody does, as opposed to the quote-unquote unfair situation, where the dishonest parties could potentially get their output first, and then they could abort the protocol so the others party get nothing. Okay, so that is our contribution, and now let me show you how do we make it happen. But first of all, I want to identify a challenge that is specific to a quantum setting. It's actually just sending a quantum message, even when we are trying to send quantum messages, we already encounter issues related to identifiable abort. So let me just demonstrate. So let's say these parties are running some protocol, and let's say player one is malicious. So he's a bad guy, so he just decides to withhold the message, so it's supposed to send a message to P2, but he does not send it. Okay, in which case, because there is no cloning, so this message is lost for good, and any information that has been stored in this message is also lost. So it is possible that we might not be able to recover from losing this message, and in which case we might have to abort. Let's say that does happen, then well, we'll have to catch the malicious, we'll have to catch the bad guy. And well, okay, so let's take a perspective of P3 for a moment. So of course, from his perspective, he can say that player one is malicious, for the reason I just mentioned, but he will not always be correct. Because there is also which other configuration, where P1 is honest, and P2 is malicious, and P1 sends a message to P2, but P2, after receiving the message, he falsely accuses P1 and claims that the message was not sent. And well, from the perspective of P3, these two situations are indistinguishable. So P3 does not know which of player one and player two is malicious. And therefore, we just don't have enough information to get identifiable abort in this particular case. So it almost seems like there's some kind of barrier to a panel to satisfy identifiable abort under a quantum setting. We can not even send quantum messages without running into these issues. But well, we're able to overcome this barrier, of course. So let me show you how to solve this problem. But before we solve it, let's first formulate it a bit better and actually make it well-defined. So the goal is, like I said, that player one wants to send a QB to player two, but we want to send it in a way that is secure with identifiable abort, meaning that if this process goes wrong, then everyone will know who is the cheater. So to make the discussion more effective, we're also going to put some restrictions in the adversary's power for now. So right now, the adversary can still drop outgoing messages that I mentioned. So he's supposed to send a message and he's just not sending it. Or the other attack, also I mentioned earlier, is that maybe player two is malicious, then he can take a message and claims that it was not sent. And right now, we worry only about these two attacks. There will be some other issues down the line, such as privacy or authentication, but we'll worry about that later. Okay, so this is the definition of this two-percent problem that I'm about to solve. So now let me present our solution, which is which we call routing. By the way, for this demo, for the purpose of this demo, let's say these two are honest and these two are malicious today. Okay, so as you might be able to tell from the name routing, all construction is inspired from computer networks. So when we talk about routing, then we are trying to route something from player one to player two, we are trying to route packets, and well, here is how we create our packets. So we tag the input, the player one's original input, run a quantum error correcting code, we run a QECC on the input to create our packets. The reason why we choose to use QECC is because we, as in our discussion earlier, we cannot avoid losing messages. And that is why we use ECC, we use error correction. So even if we lose some of these packets, as long as most of these packets do arrive at P2, then he will still be able to recover the original message just by decoding the surviving packets that he's received. Even if we lose some packets, as long as we don't lose too many, we are still okay. So that is our packet. And of course, we also have to talk about our network that we are going to use in our routing procedures. So we initialize our network as a complete graph between all of the players. Okay, so now we are going to route these packets from player one to player two. And well, of course, since there's a direct path here, then that is what we will try first. So we try to send these packets one by one from player one to player two along this edge until a packet gets dropped. Okay, if no packets get dropped, then of course player two gets all of these and he can just decode it easily and we'll be done. So right now, let's just say player two does this attack over here and now we lost a message. We lost a packet. And well, right, and we are still fine because we are using ECC. So again, we can go for losing a packet and now we know this edge is unreliable. So we get rid of it. We erase it. And then, just like how routing usually goes, we find a different path. So right now we find this path. And we try to send the remaining packets along this path. Yeah, I want to make a remark that this edge is between two others' parties. So packet would never get lost on this edge because player one will always send a packet and player three will never force the accusing of not sending one. So for the preference of this demo, let's just say the next packet gets dropped here. In that case, we erase this edge, but we do not erase this one. So generally, we only erase the packet. We only erase the edge where the packet drop actually occurs. And, you know, the process itself repeats itself. So next time we find this edge and we find this path and then we try to send the remaining packets along this path until well, there are two conditions where the protocol could end. The first condition is if P1 has no packets left, so everything has been sent. Or the other condition is that there might be no path exists from P1 to P2, in which case P1 would not be able to send whatever packet he has left. Okay, so let's talk about the first situation first. So P1 has no packets left, meaning that everything has either been received by P2 or had been lost somewhere in the loss in transmission has been dropped. Okay, so in this case, we actually have an upper bound on the packet loss, which is just the number of edges because recall, every time we lose a packet, we remove an edge. So, of course, we cannot lose more packets than we have edges. So we have this upper bound. And this upper bound actually corresponds directly to the number of errors in this error-correcting code, in this GVCC. And therefore, since we have an upper bound on the number of errors, therefore, if this were set up correctly, accordingly, to the upper bound, players who would always be able to decode the original message just from the surviving packets. So that is kind of the correctness property of our construction. So now, for this second case, let's say there's no path exist from player 1 to player 2, then, of course, the protocol we had to abort. So let's make it happen. So now, let's say this path gets broken and this one gets broken. And here, I claim that we always have identified our board. And let me explain why. Okay, so I've not stated a couple of facts. A couple of observations. So the first observation is that graph is a disconnected when this happens, because no path exists from one player to another. That, of course, gives us this right away. And it's disconnected in the sense that the path is made up of more than one connected components. So let's check number one. And then the other fact, I want to state, again, it's also an observation I made earlier, is that edges never break between honest parties. And this fact number two actually implies fact number three is that the honest parties are on the same connected component. And lastly, fact number one and three together will give us an identifiable abort because the honest parties, who, again, are on the same connected component, they can just agree to blend everyone else on different connected components. And that will give us identifiable abort. So that is our construction. And that is our solution to this QB setting problem. Again, we are putting some restrictions on this adversary. So here, I also want to make a quick remark that to deal with general adversary behavior, authentication code will help. But as for how exactly does it help, well, I will explain it later in this presentation. But for now, let's just take this construction of routing and let's try to build a multi-party quantum computation protocol from ideas that we get from routing. So the first step towards doing that is I'm just going to give a quick rundown on how the existing constructions are built. So as a really rough sketch, there are usually three phases. So there's encryption, there's evaluation, and there's the encryption. So let's talk about encryption first. So the encryption phase, it is if you are familiar with existing constructions, it corresponds to maybe first half or just first couple steps of only the first couple steps of what is commonly called input commitment or input encoding. But anyways, let me actually describe what it does. So the goal of encryption is to encrypt every party's input using quantum authentication code. And here I say encrypt because it's a non-fact, like quantum authentication implies encryption. So after this encryption phase, so everyone's input gets encrypted and now inputs are not protected in the sense that they are both encrypted and authenticated. So in other words, these inputs are now ready to be passed around between different parties. But we are not doing that yet. In the encryption phase, there's no quantum communications yet, even though there might be classical ones because the parties might come together and jointly generate the encryption key for this authentication code. And that is about it for encryption. So now let's move on to evaluation. So in evaluation phase, everyone just evaluates the circuit over the authentication code. And of course it involves quantum communications because at the end of the first phase, everyone holds their input and will have to make those inputs come together somehow. Okay? And at the end of the evaluation phase, everyone would hold a cipher tag of their own output. And then the encryption just does what you think it does. So if just everyone decrypts their output and go home with it and be happy and be gone. Okay. So that is how the existing constructions go. Again, this is just a very rough sketch. But let's see how does routing fit into this picture. Well, the first question we want to ask is of course, can we just incorporate routing into existing constructions and get identifiable abort? So here's what I mean as a candidate protocol. So we keep the encryption phase as then because it's local, it doesn't really need routing. And then in the evaluation phase, every time we are supposed to send a quantum message, we call the routing subroutine to send all of the... So for every quantum message, we just send it using the routing subroutine. Okay. And well, does this construction work? The answer is well, unfortunately not. And the really high-level reason is that the QECC would destroy the authentication. So here's what I mean. So we call that this is authenticated. So, and the purpose of authentication is to prevent the malicious parties from tampering with the underlying context. For land, when we tag the QECC of authenticated codework, then the individual packets are not authenticated anymore. So, when we try to call routing on this packet, then this packet can actually be tampered by relays. When I say relays, I mean it in the routing sense as in the parties that get to touch the packet between the sender and the receiver. Okay. So, the answer to this question is no. There are many reasons why this is no, and this is one of the main reasons. Okay. But still, from this no-go result, we still get some insight out of this situation. Then we let each of the packets have to be protected separately. So, why don't we just try to switch these two steps and see what happens? So, here we try to first do QECC, and then we encrypt. So now every QECC code word is protected. Every packet is protected. Okay. So now one of the reasonable, I guess, one of the natural strategies to tag is to just homomorphically evaluate the QECC. So we are evaluating both over QECC and over authentication code, and everyone still get their output, and then everyone just decodes locally and get their output. So everyone decodes both encryption and QECC after the communication is done here. Okay. So, this looks promising, but unfortunately this build does not quite work. So, we actually have a complete attack against this construction. Okay. So, we call this an invented QECC attack. So, the idea is that this QECC can be prepared incorrectly because it is prepared by dishonest parties, at least some of them are. So, the dishonest parties can just prepare this as garbage, and then, well, we know what they say, garbage in, garbage out. So, this is now also garbage, and it decodes garbage, and I will give a simple example to demonstrate. So, take this circuit, for example. So, this circuit, it has, of course, two steam updates. One of the ways to look at this circuit is just that it takes two inputs, and then it takes the XOR of the two inputs and it writes the result on this MCR. And now, let's try to run this circuit under repetition code and see what happens. And, of course, we know that repetition code is not fully homomorphic, but it is squinting now for me to demonstrate this attack. So, let's go. So, zero under repetition code. It gets repeated three times, so it goes to this. And these two are not real cohorts of repetition code. And now, under repetition code, if you want to do a C-naught, you just apply it to every qubit. So, this goes to this, it does not change. This goes to this, again, it does not change. And this, after these two C-naughts, goes to this. So, this is the result. And now, we decode the repetition code, which is just by taking the majority vote. So, this goes to zero, this goes to zero, and this goes to one. So, this result is saying that the XOR of zero and zero is one, which is not correct, obviously. So, here we have inconsistent output. And this will break the correctness of multi-party computation. And therefore, this construction is, again, no go. But still, we can try to fix this attack and maybe get a working construction out of it. And this is exactly what we did. So, this is our construction. The difference between this and the previous slide is, of course, this middle part. So, what we do here is that we decode QECC here. So, we combine the package before we evaluate this circuit. And this will fix the attack that we had, because, well, even if this were invalid, then we can also just, we can always just handle it here, and we end up with something valid here. So, we are always evaluating over valid inputs. Okay, so, this construction, it has a caveat. It says, well, we cannot communicate after decoding QECC, because this is not in package form. So, we cannot, we can no longer send any messages. Okay, and if we cannot communicate, then it sounds like a job for a very, very, very viable quantum, for quantum FHE, and that is what we ended up using. So, to sum everything up and to fill in the gap, then we just go through our protocols step-by-step. So, every, everyone starts with their own input. They first create packets out of their own input, and then they protect the packets, each of the packets. And then they route this packet to how we call a server, which is just one, which is just a designated party. It doesn't matter who gets to be a server. We can always say the player wants a server. Okay, and then the server, he locally combines this packet and apply the circuit to get everyone's output, and then he creates packets out of everyone's output. And then after that, he routes everyone's output back to where it's supposed to go. And then the parties, once they receive this, they can just decode it and decode it to get their own output. Or at least this is the really high-level summary of our protocol, just a sketch. And there's a lot of very interesting issues that we are brushing under a rock here, unfortunately due to time constraints. So, I really, really encourage you to read our paper to get a more complete treatment on this. Okay, so now to summarize, we construct the first multi-party quantum commutation protocol with identifiable reports. And it's also worth... And again, our protocol is run efficient, and it preserves the failures from the classical NPC that we use. In terms of future work, one of the direction is to require more dishonest parties to cause an abort. So, here's what I mean. In our protocol, because we use a server, so let's say if a server were malicious, then he can just tag, you know, he can just tag everyone's input and then just goes home with it. And then the protocol will have to abort because everyone has lost their input and that takes just one dishonest party to cause an abort. Then the server. So now, we are wondering if there's a better construction that can tolerate more dishonest parties before the protocol had to abort. Okay, so that is one of the open problems. And the other open problem we have is that we are wondering about the possibilities for getting a constant run multi-party quantum commutation with identifiable abort. So, here's what we mean. So we are wondering if it's possible to get this and this at the same time. So of course, we've accomplished this and there's the other work that we have and there is work that achieves this. But then we are wondering if it is possible to get both at the same time and right now our construction is not constant run because routing is a bottleneck because we need to route the packet one by one to all the parties, to different parties. So, right now, and right now we're suspecting that it might be impossible to get both of these but it's something worth thinking about. So, thank you very much. And that is all I have.