 Okay, thank you. Welcome. Good morning everybody. No roaring lions this morning. So hopefully you'll still be away. Yeah, so this is John and Mark with Die Barrel Day, Mark and Elizabeth Oswald, and myself who are all from the University of Bristol. So let's first start to deconstruct the title a little bit. So this is about authenticated encryption. So I think you will all realize that this is a key component in secure communication, and we're going to look at it from a provable security angle. So what we're trying to do is to bootstrap security over a complex primitive because authenticated encryption is not at the lowest level, from a more simple primitive, for instance, a block cipher or a two-dimensional function. What we're interested in is to do this in the phase of leakage. So there's two types of leakage we will consider, protocol leakage and side channel leakage. So protocol leakage happens when the implementation of constructions aren't perfect for whatever reason, and you start leaking little things like different error messages or unverified plaintext. That differs a little bit from side channel leakage where you really leak directly over primitive. You can think about differential power analysis or cache timing attacks. So the good news is that if you take secure primitives and you take provable security, you get secure constructions, for instance. There are many papers that talk about this, so you might not be able to see quite what the titles are, but trust me, there are many papers here that do this. Now, once you add the real world into the mix, then suddenly your constructions are no longer secure. And again, there are many papers here to display it. So this is Serge, for instance. This is you. And some other papers as well. Other ones are harder to read. So this is not good. This is quite ugly. So you can try to get rid of the real world. I mean, we're in the eye track, which I think is probably the ideal world track based on Europe or the president. But maybe we don't want to get rid of the real world and we want to be able to do something for the real world. So then it becomes rather ugly model-wise, but it is what it is. So what can we do? So we need better models. So the questions that we then want to address are threefold. So one is how to argue about AEs, so if I'm going to get an encryption robustness in the face of leakage. The second one is when do these primitives compose securely? So when the primitives are secure. When do they compose against leakage securely as well? So ideally you want to say if my primitive is secure against leakage and then I compose it into a construction that I know is supposed to be secured and the whole thing is still secure when considering leakage. Then the next question is how resilient can your primitives actually be against leakage? So I'm going to warn you that this is a rather theoretical construction, so not something you might actually want to do in the real world. So from the contributions we'll provide a definite framework to deal with the top one. We will give the confirmation of what I call the ROOP FOLK LORP, even though it's not that old, the release of our play text, that the NRS schemes they behave as you would expect them, so if you release it or verify the play text, you're insecure, if you don't, you're fine. And we also formally prove that cipher feedback mode is resilient as well against leakage. So the main reason we chose PRP is because it relies on PRS and it was relatively easy to analyze. You should be able to also work with other schemes. And then finally, we provide a strong link of resilient pseudo-random function. And yes, we do throw a kitchen sink that is in the generic group and random workflow model, so this is why I say you might not want to do this necessarily in practice, but this is, as a proof of concept, it tells you that it's possible to do this relatively efficient. So this is then the outline of the talk. So we'll look a little bit first at what's known about modern authentication encryption, just to set the setting. Then we'll look at the new leakage scenarios, so the protocol leakage, primitive leakage, and also how the composition under leakage works. And then there's the leakage resolution PRF and the conclusion. So authentication encryption, we are using this quite common syntax where authentication encryption, the encryption takes a key, a non-associated data, a message, and it outputs a ciphertext. There's no real point in splitting out a tag here, so the tag is kind of integrated into the ciphertext. Of course, if you have a construction, you can have an explicit tag from a definitional perspective with no need to. And then encryption, key, non-associated data ciphertext, and output either the message or a symbol that the ciphertext was not in the, well, not there. There's the usual three-night behavior assumptions, so correctness. If you encrypt, then decrypt, you get the message. Tidiness, if you decrypt, and it pops up the message, and then you re-encrypt the message, you get back the ciphertext, then you fell into it. And then length regularity means that the length of the ciphertext only depends on the length of the message and all the nine things. So the standard security notion for authentication encryption is conveyed in this picture, which is a security notion due to Robert H. Schrupton from 2006. So you have an adversary, and the adversary has to distinguish between two words. In world one, he has the real encryption and the real decryption oracle, and in the other world, he has something that produces random mysteries of the appropriate length, or if you look for the encryption, he just rejects everything. Now, of course, to make this notion meaningful, you have to make sure that there are some restrictions. If you ask for encryption and then feed it back in here, you'll want to prohibit this or deal with it in a way because otherwise they're trivial to distinguish. But those are details that you can look up in the paper, that paper, our paper, many papers. But the idea is here. So this notion is known to be equivalent to having both indistinguishable T under a chosen plate text text plus ciphertext integrity. So it's really neat because it captures these two different notions called nationality and authenticity in one overarching notion. So when you look at it, in more detail, you see that this encryption oracle is really an encryption where you feed the norms that associate the data and the message. So the question is, what are the restrictions on these norms that associate the data and message? And then it turns out that, so there's no restrictions on the associated data and the message, but there are restrictions on the norms and there's a well-known hierarchy of three levels in its random. Then it's really an initial vector. So this is what people used to do to analyze, for instance, in C mode. If it's unique, then it's a nonce. So this is, for instance, something that breaks counter-mode. And then if you have no restrictions or you can repeat the nonce, then we talk about mission resistance. So these abbreviations, I think they are also due to non-prime for a roadway and strip, and I believe they don't hold me to it. So this is the strongest, so this is where we would like to be, but often we start with things there. So the question is, how do you go down and can you do so even if things are starting to leak? So this is where generic composition comes into play. So there's three different types of goals you might want to consider. So the first goal is domain extension. So you have a PRF that takes a fixed, or a PRP that takes a fixed input, but then you want to go to something that has a variable input length. So this is CBC does this for you, or CFB and D. You might want to boost security. So I said there are at least three levels. So you might want to go from the top level, the weakest level, IV-based security to the strongest notion where you can reuse nonces. So randomized and encrypt is a way to do this. And finally there's composition of security. So this is related to what I mentioned before, functionality and you have integrity that together gives you a complicated encryption. So encrypt and MAC, MAC, then encrypt and encrypt and MAC, they all offer you this sort of... So there's several schemes that do this for you and they've been analyzed in a mode setting by an Unprepared World Instructor. So this is scheme N2. So it encrypts and creates a tag. This is a scheme that takes a PRF and an IV scheme and builds it into a multi-based scheme and then you can mix them up and then you get the scheme which is called A5 so you have a PRF, an IV-based scheme and a message authentication code and then you get a nice scheme. So the question now is how secure is this scheme or this scheme when things start to leak? So what I've mentioned so far is all due to a sequence of papers and there's an IRS I should have mentioned there as well. And then when you move to leakage people have looked at it but they've really concentrated on decryption leakage in a very specific type of decryption leakage as well. So Valdireva has all... they looked at the special case where there are multiple decryption errors which occurs in certain contexts. Then I keep thinking Valdireva et al. they looked at the release of unverified play text so this is a situation where you need to effectively decrypt part of the cipher text to get a message so you can then feed the message into a tag into a tag verification algorithm so you might actually release the play text before you have verified it. Then Valdireva et al. they looked at a special case based on encode and encrypt and finally Valdireva et al. they looked at any type of deterministic leakage on invalid cipher text. But it's still quite restricted and it doesn't really deal with probabilistic leakage or leakage of encryptions. So we'll look at that in a moment first the release of unverified play text so as I mentioned what you have here is scheme 801 and if you want to decrypt this you'll have to go up and you'll have to go up here before you can do the verification of the tag to recompute and at this point you might end up leaking M so this is the release of unverified play text so with the deterministic leakage it looks like this so you'll have an additional leakage oracle that outputs your leakage but only if this one rejects and if this one doesn't reject then that one effectively rejects so the things that are not being considered is for instance if this leaks or if the tag might leak when you start recomputing all sorts of other things might leak so the block ciphers for instance could leak because they're the smallest building block and they might still leak all sorts of internal variables for instance noisy hamming rate of S-boxes is very common in the side channel community to look at there's other things that can leak as well and they can leak directly on the key it's not clear what the effect of this is going to be so there's a challenge so how does this would the leakage affect the overall construction in the security setting and how can you model and argue about the leakage so what helps to look at this is to reconstruct the Rothery-Sremton definition so they only have two oracles encryption and decryption but really there should be four so there's two oracles encryption and decryption that specify the goal so there you have either decryption or real or random and the true encryption and decryption oracles so these were implicitly usurped by goal oracles because you can simulate them using these but it's much easier if you have them around and then you can use them for the leakage so the way this looks is like this so what you have is you have here always true encryption oracles and here you have the challenge oracles and then we assume that only these leak so we're not allowing leakage on the challenge oracles because that's quite difficult to define nonetheless I should point out that there is a scenario where leaking on challenge oracles does make sense if you look at secret sharing based multi-party computation because in that scenario you might want to open certain values even during the challenging version so with this model in place you can start reanalyzing all the NRS schemes and the first thing you have to do is of course you have to define how to relate the leakage classes because what you want to say is that if this is secure against leakage and this is secure against leakage then the whole thing is secure against leakage leakage is now the security definition is with respect to a class of leakage function so you have to define how these leakage classes depend on each other because you can't suddenly start leaking more and leakage will be kind of independent so the leakage of the whole construction is that concatenations speak of the leakage of the individual component and you assume that there is certain independence there and what you then see is that from the eight schemes that don't run for at all identify as secure A1, A2, A4, A5, A6 and A7 and A8 there's only two A5 and A6 that go well with leakage and these are precisely the ones where you have encrypt the MAC so you can actually verify before you need to decrypt as soon as you need to decrypt before you can verify then you have release of a verified plaintext attacks and you can't have security in a decent leakage setting either so A5 and A6 and this is a problem because only A4 is known to be secure against misuse-resistant so these notions they are secure but only if you keep the nonsense unique as soon as you start repeating nonsense you need to go to A4 so now we're in a situation where none of the known schemes is actually secure against misuse-resistant in the presence of leakage so to solve this we have a new mode which is called CVET CVET? if anybody comes up with a better name how to pronounce it so what we do is we combine here the various IDs then we have a PRF then we have the IV and then finally we have the extra tag so we have to pay a price for this additional security because the expansion is going to be two elements out of a PRF rather than the usual one element out of a PRF but the good news is that it is now secure if you underline derivatives are secure and that also means that the MAC verification doesn't start to leak the true tag so you can't for the MAC verification you can't do a recompute the tag and check with the tag that is given because then very trivial things arise so you have to be a little bit careful how to do this and the other thing is that you need a PRF strongly adaptive secure against leakage and this is something that is difficult to achieve so why is this? well, let's look at PRF security so again we have two oracles around the challenge oracle is either output a PRF or a randomness and the real PRF function also provides you with leakage and only this one leaks and again security is going to be relative to a class of leakage functions and this allows us then to model a split state leakage assuming only computation leaks information because what you want to do is you want to use something like masking where you split the state and then you're going to assume that you can't leak shares of the secret at the same time I don't know I didn't know that's my question well good so the main challenge is to get strong adaptivity and with strong adaptivity what you want is that if somebody asks here for the output of a PRF and gets the output of a PRF or a completely random string and then starts to ask for leakage here you ask making this query where it leaks you still want to have it secure and what we're going to do is we're going to work in a model where the adversary can specify the leakage function so this leakage function that might depend on the input outputs and especially the outputs that you've seen here so more specifically the type of leakage we want to consider is leakage functions that are only restricted in the output length to prevent leaking full input because if you can leak all inputs completely then you can't get any secure so you need to do something again and then repeating invocation results in more and more and more leakage so it kind of accumulates so there's some caveats so for instance this model allows future leakage which is always a bit peculiar but this is what leakage resilience does and the model also allows for inefficient leakage functions so it's a very strong model but it has some aspects that are not realistic and it's also weak in the sense that this is very restricted in the length of the output whereas if you'd actually take a real device and plug an oscilloscope to it it will not give you only a few bits it will give you gigabits gigabytes but still it's a useful model so if you look at how a PRF with a split state model works it looks roughly like this so you have your key that is split now into two parts you have an update function here which also has two parts and you have the actual evaluation here which is also in two parts so what you do is, in the first state you update and you evaluate and you might leak on this but in the second state you update you evaluate the second part and you leak again now there is a wonderful construction by Kielts and Pietersack where they explore bearings to make everything neatly fit together so if you think about this function fk of x is the bearing evaluated in the secret key at the edge of the input then that's a wonderful PRF and it's very easy to evaluate it in a split state model namely like this so you update your secret key by adding randomness and then you subtract it so then the sum of these two will be the same here you do the bearing and then you multiply in this thing and you will see that you will get exactly the bearing of this one plus that one of h of x so that's easy and then you think like wow this is great this is brilliant why isn't this secure and the problem is that you can do kind of side leakage so imagine that x star y star is your challenge so this is what you receive from your article then you ask for a leakage to be on evaluations on those side channel points and you can actually do a leak in the middle attack and these values will coincide so as soon as you can leak just a few bits you can check whether they indeed coincide so the solution to this problem is to use three shares instead of two and then you can leak lambda bits which should be about half of the group side thank you for your attention