 Thank you. So the titles, the original title is extremely similar to the previous talk, so for a bit more clarity, as Serge said, the differences here we're talking about authenticating and encrypting quantum messages with Kimmy Cycling. So authentication of quantum messages was, the first paper that discussed it was this paper by Barnum et al in 2002, and it's up to today still the most interesting family of protocols for quantum authentication, and everything that came afterwards is some special case of this family. There are a few exceptions, which I might mention at the end if I have time, but it really remains the way of encrypting and authenticating quantum messages. So what we do in this work is that we prove that, very similar to what Serge was doing, all the key can be recycled upon accepting the message, but here it's a uniform key, and we don't have the problems of non-uniform keys that Serge had, but this actually only works for a subset of the original family, hence that we have the restriction, and if I have time at the end, I'll explain why it doesn't work for the entire family. We can also recycle part of the key upon rejecting, and we can prove that this is optimal, so all the bits which aren't recycled, the adversary actually can get them. And this work, we wrote it using the abstract and constructive cryptography framework from Maurer and Hiner. So it's some kind of composable security proof, very similar to the more familiar you see, it's just some kind of simplification and generalization of UC. I won't go too much into the framework, just the minimum so that you understand what we're doing. So key recycling is not actually a quantum property. The thing which is quantum is that we can recycle everything, but in the classical case, we can already recycle key. If we look at just the standard classical authentication scheme with the math, we have a message, and say we generate a tag like this, we apply some hash function to the message, and we one time pad this, and Alice sends this, Eve can modify it, Bob just does his standard check to see if he received the right thing. Already 1981, Vigman and Carter mentioned this and pointed out that we would need to new K2 each time, but we can reuse the same K1, and the intuition they give is simply as we're one time padding this, Eve here who observes the tag, well, she has no information about K1 and therefore it can be reused. That argument is actually not completely correct because when Bob accepts or rejects, this is a bit of information which Eve might intercept, and which might actually leak information about K1. So when you reuse K1 again and again and again, each time a little bit more information about K1 is leaked, but it's very little. You can actually prove that it's very little and it still remains close to uniform, sort of proportional to the number of times you use the key, which is something I did some years ago. Now, if you look at an authentic channel, what we're trying to build is basically this. Alice sends a message which goes to Bob, but Eve also gets a copy, and what's important about this channel is that Eve cannot influence the message. She can sort of passively read it, but she cannot change it or insert something to the channel. Now, if we think of doing this in the quantum case, and we change the message with row and Alice sends row, Bob gets a version and Eve gets a version, this of course cannot work because there's this theorem which is no cloning theorem which says the quantum state can't be copied. So if Bob actually receives row, he knows that Eve doesn't have a copy of it. So you can't, there's no such thing as an authentic channel which doesn't provide confidentiality to in the quantum case. If ever you get authenticity, if ever Bob can confirm he really has the message that Eve sent, that Alice sent, then he knows that Eve doesn't have anything. So in the quantum case, authentication is actually something stronger and harder to achieve than encryption. If you get authentication, you kind of get encryption for free. Now, supposed we design a scheme in such a way that Bob actually verifies that he receives the correct cipher. Note that this is not the same thing as receiving the correct message. So it's some slightly stronger requirement. If Bob receives the correct cipher, so he receives exactly what Alice sent, something close to that, then Eve has no information about the cipher at all and in particular, she has no information about the key because the key is kind of embedded in the cipher. So Eve knows nothing about the key and therefore the key can be recycled. So really it's kind of some no cloning going on here which is the same principle as quantum key distribution. So it's not really a surprise that we can do this. So before telling you how to do this in the quantum case, I'm just going to go over the classical case because we're trying to construct a secure channel. So let's look at how we construct a secure channel in the classical case. So we're going to do it in two parts. We're first going to construct an authentic channel and then given the authentic channel, we're going to construct a secure channel. So I'm going to have these kind of little pictures on all my slides in the next talk and the way you should think of it is that these little square boxes represent some kind of resources that the players need in order to run the protocol. They're going to need a secret key. Can't do anything without that because they're looking at information theoretic security. So you can think of them as having some kind of box which gives a key to each player. And they need some way of communicating so we're just going to give them an insecure channel which is the weakest kind of channel possible. Whatever Alice puts in goes to Eve and Eve can completely change it and send something else to Bob. So they have these two resources and they're going to run a standard MAC authentication protocol. So these boxes with little round corners are simply local operations that Alice and Bob can do with their interfaces. So this, if you want, is Alice's protocol. She provides it with a message. It gets a key. She generates a tag. Eve can change the tag. And on the other side, Bob is going to check if it's a valid tag and either accept it as prime or reject it. So what we actually want is to construct an authentic channel. So what we would like is to somehow argue that what we've done is we've just built an authentic channel. So this is a bit more of a formal version of an authentic channel. Whatever Alice puts in, Eve gets a copy. And now Eve can actually input a bit, zero, one, to decide if Bob is going to get the message or not. Because the authentic channel I had a few slides ago cannot be achieved because Eve can always jumble the communication. So Eve always gets to decide if Bob gets the message or not. So in some sense, this represents some kind of bound on what power we are willing to give Eve. We're willing to give Eve a copy of the message and we're willing to allow her to decide if Bob gets the message or not. Now we want to argue that this somehow constructs this. And if you look at the Alice's interface, the same as here, and Bob's interface has the same structure. Eve's interface here looks completely different because we have our idealized interface and we have our real interface. So to argue security, we need to find some kind of simulator here that is going to construct the real interface given access only to this idealized interface. So if we can't find such a simulator, it means this is certainly not more powerful, doesn't give any more information to Eve than what this does. And now to argue security, what we want to say that this system we've constructed here is indistinguishable from this system. So indistinguishable just means you kind of put a box around it and now we look, we have this sort of black box which can take an input here, produces an output, takes an input, produces an output. And we give either of these boxes to someone and have to guess which one they're holding. So we're gonna call this sort of abstract player distinguisher, it's given one of the two and has to take a guess and it's going to output a bit. So and we look at just the difference to probability of outputting one when you're interacting with the first system, with the second system and that's the advantage of the distinguisher. So if no distinguisher can guess whether he's holding this or this with advantage more than epsilon, then we say the two systems are actually done close. And if these two systems are actually done close, then what we're going to say is our protocol, so this part constructs the authentic channel given these resources. So the abstract crypto framework really sees cryptography as a resource theory. You start off with some resources and you construct some new resources. In this case, you start with the key in secure channel and you construct an authentic channel. This is this sort of written in English and this is the same kind of using some kind of formalism. The protocol is a map between resources. So it uses these resources, it constructs these resources and this is satisfied if there exists a simulator such that the two systems are indistinguishable. This is just some notation to try and capture the picture. So now we have an authentic channel, let's try and construct a secure channel. Now we do the obvious thing, it's a one-time pad. So suppose that Alice and Bob shared this authentic channel, Alice just one-time pads a message, sends it on the authentic channel and Bob inverses the one-time pad on his side. So we want to argue that this constructs a secure channel which is very similar to the authentic channel except that here it only leaks the size of the message. We can never hide the message entirely, we always have to leak the size. Or at least the bound on the size. So again, we're willing to give Eve bound on the size of the message and we're willing to allow her to decide if the message is received or not. And now to prove that this constructs that, we need to find a simulator which is trivial, it just outputs a completely random string here and you can show that these are, they are completely indistinguishable. So now we've constructed an authentic channel and then in the second step we've constructed a secure channel, we can combine the two steps. So if you just take this picture and you replace the authentic channel by the previous construction, which I've put here in purple, this is kind of the composed construction and then we get on the ideal side composed construction of the simulators. So these two parts of the protocol, the one-time pad and the authentic channel, we can think of them as one protocol, we can think of them. So these two parts of the protocol, I'm sorry, it's slipping again. No, no, it's okay. I just have to get it behind my ears instead of, let's hope it'll hold better this time. So these two parts, we can view them as one composed protocol which now uses these two resources, it uses two keys and it uses an insecure channel to construct a secure channel. So simply in this notation, we use these resources to construct an authentic channel and if we give it an authentic channel we can construct a secure channel, just the composition of the two means the composition of the two protocols uses these resources to construct a secure channel. Okay, so this is one way we can construct a secure channel classically. It isn't actually much help for us because we used an authentic channel in the middle which we can't do in a quantum way. So now I'm going to reverse the order of the one-time pad and the authentication. So now let's start with the one-time pad. We have an insecure channel, a message comes in, we one-time pad it, we send it on the insecure channel and Eve can change it and Boban does the one-time pad. So now what have we done here? We now have a weak resource on my previous slide. What we actually construct is a channel which looks like this. Eve gets no information about the message except the size because of course it's one-time padded here. But now Eve can change it and she can only change it in very specific ways, she can only do bit flips. So Eve can basically choose how the message gets changed. So to prove that this is the case you have to find a simulator, it does the obvious thing, it outputs a completely random cipher, it gets a C prime here, computes the X over two and these are the bit flips Eve performed here. So then we do the same bit flips there because bit flips commute with the one-time pad. So then you can show that this protocol, so the one-time pad, given these two weeks, it's mapped these two resources to a, what I'm calling here, an exo-manable channel. So now we have an exo-manable channel and we want to construct a secure channel. Now an authentication protocol won't do, doesn't do it in a generic way. We know that authenticate and encrypt is not the same as encrypt and authenticate. So how do we do it to get a secure channel? Well, the only thing Eve can do is bit flips, so we need to somehow detect bit flips. So what we do is we're going to encode X into some Y using some code which is going to detect bit flips. So this is just to quickly introduce the notation. Let's take a code, a linear code, CK, and I'm going to, we think of CK as being the generator matrix but I'm kind of padding it to make it square. So we basically take your message, we add what the syndrome is going to be, which is zero if we're just trying to generate the code word and we just multiply it to this matrix and we're going to get a valid code word. So this is what Alice is going to do. She just generates a code word and sends it on the channel and on Bob's side he's going to decode. So he applies the inverse of the matrix, he's going to get some X prime and some syndrome S. If the syndrome is zero, he's going to accept it and if the, he's going to accept X prime and if the syndrome is different from zero, he's going to reject it. So now we need codes which have a certain property. So every code is going to either detect certain bit flips or not detect them. So we can, I'm calling FK the set of all the bit flips which are detected by the code with index K. So this basically means if you encode it, you do your bit flips. So I'm just writing the bit flip here as a linear operator and then you decode it, you're going to get back syndrome zero. These are the ones that are not detected. So F of K is the set of errors which are not detected by code K and we need a set of codes such that have high probability over the K or errors are detected with probability one minus epsilon. So the probability of not detecting an error is at most epsilon. So we can construct, we can find such families of codes. And if we do this, well, we can show that we just have a small error epsilon when we're trying to distinguish these two systems which depends on the, on these families of codes. This error is just how well our codes cover all the errors. And so now we compose our one-time pad with these codes. So I'm just skipping a few steps here. This is the protocol which has both together. It gets a key, you're going to split in two parts. The first part we're going to encode it using some code chosen by K one and then we do a one-time pad and then the decryption works in the obvious way. And if after the decryption we get a syndrome zero, we accept it and if we don't get a syndrome zero, we output an error. So this is how we construct a secure channel from an insecure channel by reversing the order. So we're not doing encrypt and authenticate, we're doing a code then encrypt. And this is a generic way of constructing secure channel. Now, still in the classical case, we can recycle key. When we look at what we've done here, we've one-time padded our cipher with the key K two and therefore K one is completely unknown. So if we do this, we can recycle K one. But now the question is, when do we recycle K one? And this is an important point. If Alice recycles a key K one too soon, say before Bob receives his cipher C prime, she recycles K one, it might, in another application, leak somehow to Eve and Eve will get K one and we'll know how to change the cipher. So the key can only be recycled after Bob has received C prime. So what we're going to need is a backward channel so that Bob confirms to Alice that he has received the message. This is very similar to what Serge needed in his previous protocol. So now, so we only have to modify the protocol in a very simple way. When Bob gets a C prime, he sends this bit of backwards confirmation to Alice. He can recycle K one and upon receiving this bit, Alice can recycle K one. Of course, Bob, Eve could interrupt the authentic channel which means that Alice might not get K one. She might just abort, abort, like just get an error. And there's nothing we can do about that. This is a generic problem with any key distribution scheme. Eve can always block one of the message so that one of the players ends up with the key and the other one doesn't. So now what do we get? Well, if we look at our real protocol, we have a message coming in and a message going out and we have a key being produced. So what we actually construct are now two resources. We construct a secure channel and we construct a secret key which is starting to look a little messy but I'll try and explain. So it's a secret key which is slightly weaker than the secret key we have here because we're giving a bit more power to Eve. First, Eve gets to choose when they get the secret key because they can only get the secret key once Bob has received C prime and Eve chooses when Bob gets C prime. So Eve chooses when they get the secret key. So I've just put this sort of unary input here and the key will only be generated once Eve allows the resource to generate a key. And then of course Eve can prevent Alice from getting a copy of the key. So now we can prove that the two are indistinguishable with some error epsilon and basically what we have is this protocol given this key, a backward authentic channel and insecure channel constructs a new key resource and a secure channel. So this new key resource of course generates a uniform key. So now when you're done we can move on to the quantum case. So I've just written up very quick sort of dictionary of how we're going from the classical to the quantum case instead of having messages which are strings are going to consider messages to be density operators. So to basically you can think of them as big matrices of complex numbers. The one time pad in the classical case we just XOR every bit. In the quantum case we have to do bit flips and phase flips. So these are the Pauli operators. Code in the classical case where just add our syndrome zero and we multiply it with our linear matrix to get Y. In the quantum case we add a syndrome zero. We apply our unitary which generates our code. In the classical case we had to detect bit flips. So we had a set FK and we said the error is in FK if the code K fails to detect this bit flip. In the quantum case we're trying to detect Pauli operators. So we have a set FK which contains a Pauli operator if the code fails to detect that Pauli operator. We wanted a family such that the type property we detect all the errors. We want a family such that the type probability we detect all the errors. The cipher we generated by appending the syndrome, applying the code to doing a one time pad. We append the syndrome, we apply the code to do the one time pad. So really it's basically the same thing. But now comes the difference. So we encrypt as I just explained, we decrypt in the obvious way. We end up measuring, we get a syndrome, we get an error. But now if the error is zero we recycle both parts. Instead of just recycling K1 we can recycle K1 and K2. And that's really the difference with the classical case. We are, we can also recycle K2. And in the case of a reject we can only recycle K1. So what's different here is what I put in purple in the real protocol on the real side they're either going to recycle, so K is both K1 and K2 are kind of not enough space to write K1 and K2. So K is both. Or they just recycle K1. And here Alice will either recycle K or just K1 or she's going to get an error if Eve interrupts the back of the authentic channel. And now what we get on this side is a secret key which is very similar to the previous one except that here Eve can now input a bit which decides on the length of the key. Cause Eve decides if she's going to put noise or not so she basically decides if they're going to get a long key or just a short key. And then she has this other bit for, for Alice deciding whether Alice gets the key. So the main theorem basically says that these two systems are indistinguishable. So the errors, if we have this, our codes have this property that we can catch all power errors with probability or we fail to catch them with probability at most epsilon then the two are indistinguishable with an error which depends on epsilon which is some square root of epsilon and yeah plus epsilon over two. So this was just some parameters because here I've done this in a very abstract way I just said we need a code. Now of course there have been codes which have been proposed in the literature which do this. The codes proposed by Barneum and Dahl in the paper from 2002 achieved this. So we need, so if our message is length M our syndrome is length N. We need N bits to choose the code so it's actually a very compact family of codes and this is the bits we're going to need for the one time pad. And then we get an error which is exponentially small in the syndrome so we can really just, by changing the number of bits or increasing the size of the cipher we just get an error which is exponentially small. And then we can also do it with unitary designs which is a larger family of codes then we get an error here which is kind of a bit smaller and doesn't depend on the factor M. So last comment to make is I'm going back to the original protocol because I said we only prove security for a subset of the protocols and here's the difference. We require this property that the Pali errors were all caught except with error epsilon. The original protocol has a slightly weak requirement. This is some property you don't have for classical codes but you have for quantum codes. There exist errors which are not caught but do not change the message. Basically errors which do face flips on the syndrome for people who know what that is. So if I'm going to call G of K these errors which have no effect on the message they did not require that the sort of errors which are not caught are small they required that the errors which are not caught and do not change the message are small. Which kind of makes sense because the goal was that the message doesn't get changed. So if an error doesn't change the message it's okay we can accept it but an error which doesn't change the message this only guarantees that the message is not changed it doesn't guarantee that the cipher is not changed and we needed this strong requirement that the cipher should not be changed to be able to recycle everything. And we can actually construct attacks on this larger set of codes which prevent us from recycling all the key. For example, suppose there's a scheme and there exist schemes in literature which have been proposed which have this property that some error is roughly in half it has no effect roughly half of the codes and it gets detected by the other half of the codes. So now say Eve does this error on the message and then she looks where the Bob accepts or not the message that he received. Just this bit the Bob either accepts or rejects is going to leak one bit of information about the key which is used because then Eve knows if it's a code which actually detects this error or a code which fails to detect this error. So if you go over other codes or quantum authentication codes proposed in the literature that I've picked out here sort of the most common ones you have the sign polynomial code which falls in this category of the same structures these codes from Barnum at all but it uses QDT so it uses some the dimension is not two to some power the dimension is some prime power. So most likely the proof goes through but we haven't actually done it. The Clifford code is a special case of the codes on Barnum at all it goes through. The trap codes have this sort of weak purity testing code properties so we actually don't know what can be recycled and there's actually a very recent code recently proposed the last year and we have actually no idea if the key can be recycled or not for that one. Thank you.