 So thank you, Michelle, for the kind introduction. So what I'll present here is a talk divided in three parts. First, I'll give a bit of a background into the design of block ciphers and different settings in which you can analyze the security of a block cipher. Then I will discuss the main result, which is related to security against multi-key attacks, which I'll explain what I mean by that. Then I will look at several block cipher constructions including the Monser construction and an ideal block cipher to analyze security in this setting. And then I will look at the relevance, the practical relevance of the results in this talk. Because this talk is basically a bit located on the intersection of provable security and cryptanalysis and implementation. And I think you need to know a little bit of everything to see exactly how this talk comes together. So I'll do my best to make this talk as simple as possible to make it easy to digest, because I know that I'm going to combine several different areas. But let's start by block cipher design. So the way a typical block cipher is constructed is that you iterate a round function. And then if you look what a round function consists of, this would typically be an addition of a round key and then an unkeyed invertible function. Now I cannot really think of any block ciphers that don't fit this scheme. Most will follow it and definitely desks or AES or the typical block ciphers that you may be familiar with. Now question would be how do you design a good key schedule? It basically means how do you design the round keys that you're going to use for every round? And there, basically, there seems to be no consensus. So if you look at the design of AES handbook, then it says there is no consensus on what constitutes a good key schedule during the SHA-3 competition in the finals. And one of the finalists was Grustl. And they're also in the design document that states there is no consensus of what constitutes a good key schedule. So it's definitely interesting to look further into this problem. And basically you have to ask yourself what do you want from a block cipher, because this determines how you're going to design a key schedule. One possibility is to say, I want my key schedule to be as strong as possible for whatever your definition of strong is. Basically you could say, I want to instantiate an ideal block cipher. So a block cipher chosen at random from the space of all possible block ciphers of the same block and key size, because that would be the way to guarantee security against all attacks. You could also say, let's aim for a simple key schedule. And in that case, you may not be secure against certain attacks, so you really have to fix your model to know which attacks you're recovering and which attacks you won't. Like for example, typically when you're going to use a block cipher, you will use a uniformly random key to key the block cipher. In such a case, you're going to avoid attacks based on, for example, weak keys or known keys or chosen keys. And basically choosing a key uniformly at random is a good practice anyway, because otherwise you would be speeding up an exhaustive search. But then what's about related key attacks? Do you want security against these types of attacks or not? That's something that I'm going to investigate further in the slides that follow. So basically what are related key attacks? If you consider related key attacks, you have the possibility to encrypt a certain plain text under keys for which you don't know the secret key, the master secret key, but an attacker can choose relations between this key and encrypt the particular plain text of its choosing under these keys. So basically you could say, I want to encrypt under key k and also under key k plus 1. An attacker would have this possibility. Now if you want to formalize related key security, you have to be careful how to do this. It's not so straightforward. So I referred to Bellaria and Kono at EuroCrypt 2003 to get for full formalization of how to look into this problem. Now when you look at related key attacks, they are able to trivially break desks and triple desks just by having two plain tags and two different keys. And also in 2009, Berjakov et al showed that you can also break the full AES using related key attack. It was a very interesting moment for me to be in Leuven when this attack was announced. So everybody was looking forward. What are the designers going to reply? How are they going to respond to the attack on AES? And very interestingly, so Daman and Reimer gave a presentation where they said, well, the attack doesn't actually work. Oh, well, it can be fixed. So I'm not saying that it's an invalid attack, but the way it was originally formulated was not better than a generic attack. OK, interesting. So what did Daman and Reimer specifically refer to? They said, well, we should take into account if you are going to look at related key security, you're actually considering a setting where you're going to have many different keys or several different keys under which you will encrypt. And in such a case, if you're encrypting under different keys, you will always have a loss of security. This was shown already in 96 by Ali Biham, where he shows, and this is the example right here. If you have a certain plain text, the same plain text that you're going to encrypt under many different keys, let's say L different keys, then exhaustive search can be sped up by a factor of L. Basically, you're going to try exhaustively all keys, but you have an L times higher chance of hitting any of these keys, and then you will be able to break the system. So in this case, Daman and Reimer also published this in a paper at, I guess maybe not so many people will know what RCD is, Romanian Crypto Day. So this is the write-up of this talk that I gave in response to the related key attacks on AES. And they formulated there what I thought was a very interesting open problem. So basically, Daman and Reimer say, if you're looking at this setting where you have related keys or even multiple keys, this is always going to lead to an erosion in security. So basically, if you do not require security against related keys is their question, could you have a block cipher with a lighter key schedule? This is what we will answer in this talk. So first, we need to formalize this. What you will see now is basically the same thing that was presented right before me by Yannick Saurin. So you need to consider two different worlds where you have an ideal, a real world and an ideal world. And what you see here in the real world is a keyed block cipher. And you have, for this key block cipher, access to pi. And pi is basically, next size will make this more clear, the source of randomness that you have to generate your block cipher, which you can then query directly. And in the ideal world, you will be comparing this to random permutations. Now also, similar to the previous talk, we're going to consider the queries, which basically corresponds to the data complexity as the queries that you would do when the block cipher has been instantiated with a secret key. And t queries, which would be the time complexity, as queries that you would do when you have direct access to the block cipher under a key of your choosing. And then when you have this distinguishes setting, you can consider the advantage of any adversary that you could come up with. And upper bounds, as is typically done, improves the maximum advantage in the information theoretical setting. So when we are looking at the Evan-Monser construction that you're familiar with from the previous presentation, and I will talk here about the single round, also one key Evan-Monser block cipher. So you have key k, one key k, which you're XOR with, and a permutation. And then you XOR again with the same key. So here the source of randomness would be the permutation that is underlying. So this is one that you would be able to query directly as well. And what you can show is that this here is the upper bounds of the advantage of any adversary that you would have to distinguish between these two worlds. I'm not going into details in the proof, but for the people who understood the proof of the previous paper, this is a really simple case. And then we looked at the ideal block cipher as well and analyzed security in the same multi-key setting. So it's the same thing you have here. But now this source of randomness, this e, is going to be the unkeyed ideal block cipher. So you now, as an adversary, can not only choose the plaintext, but also can choose the key. And then if you're going to distinguish between these two worlds, you find an expression that is quite similar if you construct a proof, which is given here. So let's look now at this in detail. In this multi-key setting, which basically means we start with a related key setting, then we set, as an attacker, you cannot query, you cannot choose the relation between different keys, but you can query under multiple keys of as many keys as you would like to choose. Then this is the bounce that you would have for the even monster construction in the multi-key setting. This is the bounce for the ideal block cipher. Now here you have n, here you have k. So n the block cipher, k the key size. To make them comparable for the even monster construction, you always have the same key sizes you have block size. So if we assume that, yeah, this k, if you assume that k is going to be equal to n, that the blocks of the key size are the same, then you have this bounce. If we compare them to each other, and we basically see that if d is approximately is close to l, or in the same order of l, or maybe even d equal to l, which basically means if you're going to rekey very frequently, or state it differently, if the amount of plain text that you would have for every key is going to be limited, then you will see that these bounds are equal up to a constant factor. And when you can also see that the bounds, both bounds here are tight, so each of them will result, I mean, you have a key recovery attack of a similar complexity, which was already shown by Biham in 96. And also because there's an attack by Fouk et al, it was published recently for Evan Mansour in the multi-key setting at AsiaCrip 2014. This attack also matches the bound that is given here. So basically here you would have an answer to the open question formulated by Daman and Reim, which was, given that you always have security laws, if you look at multiple or related or even multiple keys, can you have a simpler key schedule that you could use for your block cipher? Yes, you can because the Evan Mansour construction would be the block cipher that reaches the same security or similar level of security as an ideal block cipher. Now let's move to more interpretation and practical relevance of this. First thing I have to say is that I'm mentioning here that this is a multi-key setting. Previous papers have talked more about multi-user instead of multi-key. So the multi-user setting typically is motivated by the fact that any good block cipher, well-designed block cipher, will typically have more than one user. But multi-key, I think, captures a bit more what is going on. So one thing that is done here is some technical thing is that you are saying, typically in the ways that the multi-user setting is formulated, the plain text is always the same. You only have different keys on which you're querying. Now we say, well, an adversary should not only be able to choose how many keys he's going to choose for encryption, but also choose the plain text. But another thing is that I think it captures better the scenario in which one user is going to rekey frequently, because then you're actually also considering the setting that we considered so far. So frequent rekeying is something that actually can happen in many different cases. I'll give just some examples here. One is that you take use of the fact that session keys is typically a good design idea because then you limit the risk associated to the compromise of one key. It can be that due to standard compliance, like you have some example for a limit that NIST sets on two key triple desks that you need to rekey after a certain amount of data, or that you would rekey after some failure. Many standards specify that if something goes wrong, like for example an authentication tag appears to be not correct, then you need to close the session and change the key. These are examples in which you would rekey frequently. To really drive the point home I'll give some really practical examples of how such attacks would work. Let's look at for example the attack on TLS by Alfredo Nadal, who was presented two years ago at USNIX. What they do there is they have one longer term secret, so one cookie or password that you would encrypt and that you would reuse in multiple sessions. And basically you have JavaScript malware, that's one possibility, that you would use, it would be like as part of an advertisement in the browser, that would generate many different connections, each different connection would have different key that would be generated for it, but every time you're sending the same plain text. Another possibility is, and this would be if you have, you place yourself in the middle, that you just change some bits or introduce some error into the connection. In this case many implementations will automatically reconnect once they find out that there's an authentication failure and retransmit the secret, so the cookie or password that was used. Another example is an attack by Pettersen et al on WPATKIP, and here because of the use of pre, per packet keys in WPATKIP, you have basically the same attack setting. So, going back to the even monster construction and explaining a bit more of its advantages, it has the advantage of being simple, as Dunkelmann had already noted, if you remove any of the components here, you get a completely insecure construction. Then basically you could say like, okay, but still I have three components, would it not be simpler if I just have one component, which is one ideal block cipher? And to understand this you have to go back to the slide that I introduced in the beginning, where I say all block cipher constructions that we know of are constructed by saying that we have some key addition and an unkeyed invertible transformation. So in this case, if you can make this key schedule simpler, you're going to have a simpler, more efficient construction, because we only know using a key schedule how to design this thing that would simulate an ideal block cipher. It also has advantages in terms of efficiency, because when you don't have round keys, you don't need to either pre-calculate the round keys or to calculate them on the fly, depending on how you do the implementation, which means that you have a higher key agility and in software implementations, a lower register pressure or less RAM that you would have, just because you have no round keys to keep track of or no hardware implementation, fewer register needed or a smaller hardware area. And also it's advantageous when you look at secure implementations, because for AES, you need to take into account that if an attacker can somehow obtain any round key for AES-128, for example, then it is possible to reconstruct the master key very, very easily. So with Evan Mansour, you don't have this problem because there's only, or the problem becomes easier, let's say, because there's only one N-bit key to protect. You could say, okay, I understand this for the very low end, like if you're looking on microcontrollers or on low end hardware, because there you typically have stringent requirements on ROM or RAM or hardware area or on speed for short or long messages. Basically for the Chesky MAC function that is now in a study period for standardization at ISO, what we did there is use the Evan Mansour construction as part of one of the techniques to realize the main design goal of having a block cipher-based MAC construction that was supposed to be, as one of the design criteria, drop-in replacement for an AES-based MAC function, so with the same security level, but 10 times faster than AES on microcontroller platforms. This is one of the things we did to realize the design goal. Then you may say, okay, but what about high-end platforms, general-purpose CPUs, maybe let's say, for example, disk encryption, clearly there you don't change the key so often, would you really care does Evan Mansour make sense because you have enough registers and you don't have to worry so much. I hope to argue to you that also here it can be very interesting to consider this construction. Why? Because when you do disk encryption, you have to make really sure that the key is not going to be in virtual memory because then it may be stored on your hard disk somewhere. So to do this, you need to avoid the key will be swapped into memory, but those techniques are very error-prone, it's very easy to get it wrong, or you need to encrypt your swap. But you say, okay, but even if you're only going to, if you're always going to make sure that your key never moves into virtual memory, it never moves into swap, if it stays inside RAM, even then you can have a problem, as was shown by Hallermann at USNIX 2008, when he explained cold boot attacks. So what you can do there is do key recovery from noisy round keys, and the typical counter measure that you use is to keep round keys inside the registers, or like CPU cache or some variants. So even in that case, you have to be really careful that you never make a key leak from the registers, and then it's easy if you have no round keys to worry about, it would be a more efficient construction. Because again, as I said, Evan Munser has only one NBIT key to protect. So to summarize, I looked at Evan Munser in the multi-key setting, which is going to be encryption under multiple independent keys, which is highly relevant in practice. Bounds were given for the security-tight bounds in the case of an Evan Munser block cipher and an ideal block cipher. And then I explained relations with practice that Evan Munser construction has advantages related to simplicity, efficiency, and security of the implementation. This includes my talk. I thank you very much for your attention.