 Okay, thanks a lot for the introduction. So, how do we do this? Okay, so here's the outline of my talk. First of all, I'll introduce the task that we're gonna be solving. Then I'll go into the security definition that we'll use. And then I'll start with what I'll call a baby version of the protocol that we're presenting, namely the protocol, but that's secure only against semi-honest adversaries. And then I'll go into what's needed to turn this protocol secure against semi-honest adversaries into one that's secure against active adversaries. And then I'll go into a very high level description of our protocol since it's a bit heavy and I don't have time to go through all the details. And certainly no proofs. Okay, so what are we doing here? So we're doing two-party computation. So I suppose Alice and Bob have some quantum circuit in mind that they would like to execute. Like the circuit might look like this here. So Alice has some qubits, Bob has some qubits as well, and they have a joint circuit on all of this that they would like to execute securely. So what do they want? Well, they want a protocol. So sending classical or quantum messages back and forth that essentially imitates a black box, so a magic box that does exactly that circuit and doesn't leak anything. Now, as you might expect, this is impossible just by communication. Why do we know this? Well, because we know it's impossible classically. And since any classical circuit can be represented as a quantum circuit, this impossibility result carries over to the quantum world. So we'll have to assume something to be able to do this. And what we'll assume is that Alice and Bob can do classical two-party computation for free. So basically in the protocol, we'll assume that Alice and Bob have access to an ideal classical functionality that does arbitrary two-party computation. Now, of course, for this to eventually someday be useful, we'd have to have a result that says that a classical ideal functionality can be replaced by an actual protocol that would be secure against quantum adversaries. And fortunately, these gentlemen here, Hal Grinsmith and Song, have shown that if you have a classical ideal functionality, well, you could replace it by a computationally secure protocol as long as the computational assumption holds against quantum adversaries. So this sort of justifies our use of classical ideal functionalities in this quantum setting. So here's what we show in one line. Basically that classical two-party computation implies that you can do quantum two-party computation. As opposed to what you might think a priori that doing two-party computation on quantum data might require a fully quantum cryptographic primitive and that classical would not be enough. We show that that's not the case, that you can just have quantum, have classical two-party computation and harness that to compute on quantum data. So here's some related previous work in the area. Quantum multi-party computation has been looked at for 10 years now. So Krippel, a goddess man in Smith, in 2002 had a result that, or had a protocol that was secure as long as you had at most N over six cheaters. And then in 2008, they improved it to a strict honest majority. Now in the two-party computation case, we had a paper here two years ago that was basically the baby version that was talking about earlier, namely two-party computation secure against what we call specious adversaries, which you can think of as semi-honest adversaries. We changed the name because defining semi-honest adversaries in the quantum case is a bit tricky because you can't just, an adversary can't just copy everything it sees because of the no-cloning theorem. Okay, so now before getting into the protocol, I'd like to do a brief detour into the security definition. So we define security of the simulation as you might expect. But we can't just, we can't do exactly what I sort of showed in the introduction where you had a black box that does everything you want as the ideal functionality. And the problem here is that the player who goes last has an unavoidable advantage. He can always prevent the other player from getting his output. And the way to see this is that if you imagine the last round, so the last round of communication or use of a classical functionality, well, the person who speaks last can just walk away from the table. And of course if, of course by then that player has his output and the other player can't have his output, otherwise that round would be useless. So since this is unavoidable, we have to build it into the ideal functionality and say that this is the, in some sense, the only attack possible. There we go. So here's what the security definition looks like for a dishonest Alice. So here's the real protocol where you have Alice and Bob communicating back and forth where some of these rounds are actually uses of the classical ideal functionality. So we want this to be distinguishable from the ideal case here where the dishonest Alice here is replaced by a simulator that interacts only with the ideal functionality. And here the ideal functionality is a bit strange in that it takes the inputs from Alice and Bob here. And then first outputs Alice's output and not Bob's. And then Alice can choose whether Bob will get the output or not. And that's all she can do. And of course, if you have a dishonest Bob, then you have the simulator on this side and then Alice is basically just a dummy that sends her input, gets her output and always tells the ideal functionality to get the output to Bob. So that's all I'm gonna say about the security definition. So now I'll move into the description of the protocol. So how do we execute the circuit? Well, first of all, we'll represent the circuit into a sequence of quantum gates and the gates will be drawn from this set of universal gates meaning that any quantum circuit can be represented as a sequence of these gates. And so what do we have here? I guess we can divide these gates into three levels of difficulty for the purposes of our protocol. So we have these gates here that the one qubit gates that I've left in white, including this state preparation. These are all members of the Clifford group which I'll get into later. But in a nutshell, these turns out to be the easy gates in some sense. And they're basically treated the same way by the protocol. So you can think of that as one big, you know, one qubit Clifford sort of set of gate. And yeah, as I said, those are the easy ones to deal with with our technique. Yes, the level two difficulty would be this year. So the CNOT gate. This is also a member of the Clifford group. So it's also easy in this sense. But the fact that it's on two qubits presents some difficulties. And then there's this R gate here that I've highlighted in red. And so this is the headache inducing gate in some sense. This is the one gate that's not part of this Clifford group again that I'll talk about later. And this is the one where we'll need some tricks to be able to do it. Okay, so now that that's out of the way. So how does the protocol work roughly? First, let's suppose the adversaries are semi-honest. So basically what we're gonna do is that we'll encrypt all of the inputs with a quantum one-time pad. So then at least the adversaries won't be able to see data that they're not supposed to see. And then for each gate in the circuit, we'll execute a sub-protocol that basically performs the gates and updates the encryption keys. And for the semi-honest case, it turns out that all of these gates can be done without communication. So all the easy gates I talked about, except for the C-naught, so this two-qubit gate. And I said a non-local C-naught, meaning that one of the qubits is at Alice and the other is at Bob. And so this one needs classical communication. And then there's the headache-inducing R-gate that needs one instance of oblivious transfer to do in this semi-honest protocol. So this is from our paper two years ago. And then at the end, we just exchanged the encryption keys and we're done. So what do we need to do to make this secure against active adversaries? Well, we need some way to force the dishonest players to follow this protocol. So of course, if you're just encrypting the data, the adversary could just do all kinds of things and you have no way of seeing that they've done something they're not supposed to. So the basic solution is that instead of just encrypting, we'll authenticate all of the inputs and an ancillary qubits. And then at every step of the protocol, whenever we get something from the other player, we'll check the authentication to make sure that nothing bad's been done to it. So I'll talk about, so how do we do this authentication of quantum states? Well, basically a quantum authentication scheme looks like this. So basically you have an authentication key K and then two algorithms, one to authenticate data and one to test the data. So, and we want to do this in such a way that, so this test here will pass if the adversary did not try to tamper with it and fail otherwise, that's the ideal case. And really to model this, we want to say that every attack that the adversary can do, so the adversary can have access to the Cypher text here and anything that might have been correlated with it, do an arbitrary attack on it. And we want this to be equivalent to an attack of this form. So look at whatever the adversary has that might be correlated with the data, measure it, do whatever. And then based on that just push a button here that says either destroy the data or let it pass. But you can't, we don't want the attacker to be able to do anything else. And so here's the particular authentication. Oh, and I, one comment I should make here, I've been talking about the Cypher text here. That's not a slip of the tongue. So in the quantum world, it turns out that authentication actually implies that you're encrypting. Basically the idea is that if you were able to extract the plain text and have an authentication tag next to it, well, by no cloning, the authentication tag can't be correlated to the plain text. So an attacker could just replace the plain text by something else and you wouldn't have authentication in the first place. So for authentication to work, well, the attacker just can't be able to see the plain text at all. So when I say authentication, I'm implicitly saying I'm encrypting the data. Okay, so what authentication scheme am I, are we gonna use? Well, there's one called the Clifford-based quantum authentication scheme that was introduced by Aharonov, Benar, and Eban in 2008. So here I'll talk a bit about this Clifford group that I was referring to earlier. So you might be familiar with the Pauly group, which is basically a tensor product of these four operators. The Clifford group is just any operation that takes Pauly operators, two Pauly operators by conjugation. And it turns out that you need order of n squared bits to identify a Clifford operator. And you can also perform Clifford operations efficiently. So if this sounded like quantum mumbo jumbo so far, you can just think of the Clifford group as some set of quantum operations that you can identify efficiently, sample from efficiently, and execute efficiently. And the authentication code based on this is actually pretty simple. Suppose you want to authenticate a state kept psi. Well, you append n qubits in the cat zero state to it, and then apply some randomly chosen Clifford to it. And the key is just which Clifford operation you applied to it. And of course to check, that's pretty easy. You just undo the Clifford, and then measure these qubits here. If you see that any of them are not in cat zero state, then you declare an error. Somebody tampered with it. Now, for our protocol, we'll actually need to do this twice. Namely, we need every state to be authenticated both by Bob and by Alice. So we just do this twice essentially. So suppose we have a qubit at Alice and we want to swaddle it. This is what we call this double authentication operation. So we first do this thing where we append n qubits, do a random Clifford, and then Alice will send the authenticated psi to Bob. And then Bob will just do the same thing. Just take the authentication of psi, append his own dummy qubits here, and then do a bigger Clifford on two n plus one qubits. And then that'll be the swaddled version of psi. So now psi is authenticated both by Alice and by Bob. So what's our protocol gonna look like now? Well, we'll swaddle all of the inputs and commit to the keys. Remember that we're allowed to do two-party computation, classical two-party computation for free, so we can commit to stuff. So we'll commit to the keys. Then we'll generate the extra ket zero, swaddle them, and we need to ensure that they are indeed ket zeros and not something that the adversary replaced it by. And then for each gate, well, we'll run a sub-protocol that tells Alice and Bob how to execute the gate and how to update the authentication keys on them. And we'll verify the authentication whenever necessary, which means in practice that whenever you get something from the other party, you check the authentication. First thing you do. And then we'll open the commitments at the end, so we'll reveal the keys, and that'll be it. Now, I mentioned earlier that the R gate is somewhat annoying. And now you might have a better intuition as to why that's the case. If we go back to the authentication scheme, you'll notice that the authentication is just based on having a Clifford applied to this big block thing. So suppose that we want to execute a Clifford gate on this thing. Well, you really just want to put a Clifford gate here. But of course, if you look at the Clifford gate plus the Clifford that's used for the authentication, that's also a Clifford gate. So essentially, you're just changing the keys by doing this. And by running these two party computations, we can basically update the keys and play this game. And it works well as long as we're trying to do Clifford gates on it. Now, if we'd like to put an R gate here, then the whole thing is no longer a Clifford operation. So we need to do something special to make it work. And this is why the R gate is problematic. So here's what we do. So we need to reduce the R gate to Clifford operations. So now, for instance, now for now, suppose we assume that we have this M state available. We have a supply of this magic state that's defined like this. And we'd like to apply an R gate to psi. Then we can do this circuit here. And that will apply R to this. So it's basically you do a scene off from this magic state to psi, measure this guy and based on the answer, then apply this or not. So all of this can be done by Clifford operations except for preparing this guy. So now we've reduced the R gate to preparing a supply of this magic state. And I mean, if you've been attending the MPC talks, you might think of this as this magic state is a bit like these multiplicative triple that they need to generate at the beginning of the protocol. Now, so how do we generate these magic states? Well, first of all, we'll have one player generate a huge supply of them, much more than we'll need for the protocol. And then we'll have the other player test a random sample of them and abort if any errors are found. Now, this will enter a low error rate, but not a zero error rate. Of course, an adversary could just try his luck and have one bad magic state and hope it gets through. So to bring it down to really negligible error rate, we'll use a distillation protocol designed by Bravyi and Kitayev for, and they use this for fault tolerant computation. And using this protocol, we can distill it down to a smaller number of good magic states. It's basically, it basically works by considering many copies of a noisy magic state as an encoding of one magic state in an error correcting code and then decoding it and correcting the errors. It really is magical. So yeah, this is how the protocol works. And I guess the take home message is if you have classical two-party computation, you can do quantum two-party computation using this protocol. Thank you.