 The first talk is key alternating cyphers in a probable setting, encryption using a small number of public permutations, and the authors are Adrey Bogdanoff, Lars Knudsen, Gregor Lander, Franz Josef Jestandard, John Steinberger, and Elmont Tishhauser, and there's going to be Gregor giving the talk, so. Thanks. Yeah, thanks. Yeah, joint work with Andre Bogdanoff, Lars Knudsen, FX Stander, John Steinberger, and Elmont Tishhauser. So this is the outline of my talk. I'm going to first motivate the topic, then I'm going to state the results, give an outline of part of the proof, interpret the results a bit, and mention some further results that are in the paper, but I'm not going to talk about this, and mention some future topics that seem interesting. So the topic is this cypher, which is phrase the key alternating cypher. So what happens here is that you have a message, M, and then you XOR it with the first round key to K0 up to KT round keys, and you XOR it with the first round key, you apply a first round function, you XOR it with the second round key, apply the next round function and so on, until finally you get your cypher text. And this is not something we design, but this is something that's a very common way to design block ciphers, and the most prominent example is certainly AS. So AS is of this form, but many others exist. And then the kind of natural question you can ask is, is this a good way of the building block ciphers? And then maybe also the natural answer is of course, because nobody can break AS, and so this is a valid way of designing block ciphers. But if you phrase the question like this, so what I mean with this is, is there a generic way to break all these ciphers? And phrase like this, again it seems unlikely because nobody can break AS, but strictly speaking we don't know. So nobody approached this question so far, which except for one round, so one round of this key alternating cypher has been studied in 91 by Ivan Mansur. It's known as Ivan Mansur construction. So this answer that we don't know, the answer to this, I think this is very surprising if you compare it to the state of the art and provable security, especially generic group model where similar questions are answered for different setups of course. And also if you compare it to what happens in the SHA-3 competition for finding the new hash function, this is interesting I think because people often say that we are more familiar with, we are more confident with building block ciphers than hash functions. And example is DES is still okay, MD4, MD5 not really, but if it comes to provable security this is different. So all these SHA-3 finalists come with a proven and idealized model, but no AS finalists had one. So this is a discrepancy. So I hope this motivated why this is interesting to look at. So the result is then the following. So first I'm going to explain the setting. So we are going to model the round functions as ideal permutations, that the adversary has to query to evaluate. And then we are going to count often an adversary has to query these round functions and the cipher itself to have a good probability of success. So we are going to have two worlds, word one where the adversary has access to the round function and also the inverses and he can ask queries to evaluate those round functions and also the encryption oracle. So he has an encryption and decryption oracle. And in the second world what happens is that we replace the cipher by another random permutation. And then the adversary has to tell apart which world he is in. That's the setup. And the result that we are able to prove is that if there's only one round, so only one p1, then you need an adversary needs roughly 2 to the n over two queries to tell away, to be able to tell apart the two worlds. If there's more than one round, then he needs 2 to the 2n over 3 queries to have a good success probability. And the reason result, which is not in the proceedings version, but it's going to be in an upcoming full version is that if you have more than two rounds, then it's 2 to the 3n over 4. And it kind of already gives a pattern what you could hope in general, how this should increase with the number of rounds. But so far we don't have a bound that increases with the number of rounds. OK, a proof outline to say something about what we have been doing. So the initial game is easy. So we sample the permutations p1 up to pt at random. We select random round keys. And then we construct this encryption and decryption oracle. And then the adversary has to tell apart which world he's in. The next thing is modifying this by lazy sampling. So instead of sampling all the permutations and the keys at the beginning, we start with empty lists. So we start with empty lists for all these round functions and also for the encryption, decryption oracle. And then if we receive a query from the adversary to a round function or to this encryption, decryption oracle, we select all round functions at random among all permutations which are consistent with the queries made so far. And then we construct the decryption and encryption oracle again consistent with the queries made so far. And then we answer the query. We update the list. And this clearly gives the same distribution. So this is only a syntactical change. So it does not change the distribution of the two games. So now I'm going to tell you the hybrid. So a slightly modified game that we use to be able to bound the success probabilities. So we changed the game a bit. And this a bit is actually the most technical and involved part. And I'm not going to explain this in detail. So what we do, again, it's lazy sampling, but this time, if you receive a query to PI or E, what we do is we kind of focus only locally. So if we receive a query, we select a random answer Y. And the only thing we check is that PI should be a permutation. And then in the next step, we are going to check for consistency. And I'm going to say what consistency means in a second. And if it's consistent, whatever this means, we output the Y and update the list. And if it's not consistent, then we crash, we give up. And clearly, this is something the adversary will be able to tell. So what is this consistency? Consistency simply says that the encryption or decryption oracle fits to the picture of the key alternating cypher. That's what it says. So it fulfills this equation. And in a picture, the hybrid works like this. So for simplicity, I took n equals 2. So I have only four ns, the block size. So I have only four possible inputs and zero keys. And so what is shown here is this is the encryption, the cypher. And these are the two round functions. And so because the cypher is just a composition of P1 and P2, these things should be the same. So now if I start with a list of queries, the adversary first asks for P1 of 0. I'm going to pick a random answer. I'm going to answer this with 1. So this is updated the list. Nothing happened so far. Now the adversary asks for P2 of 2. And I'm going to, again, pick a random answer. Say this is map to 0. And then he asks, OK, what is the encryption of 0? Again, I pick a random answer so far, no problem. But now the adversary asks for P2 of 1. I pick a random answer. I pick 3. And now this crashes. So this crashes because it's not consistent anymore. Because this line ends up with 3. While this line ends up with 2. So these are not the same functions anymore. And this is where consistency fails. So these mappings are not the same anymore, clearly. So now we have two things to do. We have to show that you cannot win in this modified game without making too many queries. And we have to show that the modified game is only slightly different to what we started with. And so the first step is rather easy. And I'm going to give you a sketch of the proof in the next slides while the second part is not so easy. So this is quite involved. And it's technical. And it's in the paper. And this is also the part which has to be improved if you want to get better points. OK, so I'm going to say only a few things about this step 2. So why is that I'm not going to explain how different this modified game is. But I'm just going to show you that it's actually different. Because this might not be so obvious. So again, a small example with zero keys. And now only three possible inputs. So what happens if I assume these queries have been made so far? And so far there's no problem with consistency in nothing. But now if the adversary makes a query to zero. So he wants to know what is the encryption of zero. So then in the modified game, it's easy to see that none of these answers would destroy consistency. So there's no problem with consistency. But what is the probability of an answer? Because there's no problem with consistency, I'm going to select a random answer between all answers that keep e permutation. And because I don't have any previous query to e, I'm going to get all answers with the same probability, one over three. Now in the original game, what would happen is that I'm not going to look at e, but I'm going to pick p1, p2, and p3 randomly among all permutations that fit to the queries I already made. And now how many possibilities do I have for this? For p1, I have two possibilities. So I have two possible permutations that are consistent with this query that I already made. And the same for p2 and p3. So this gives me eight possibilities in total. So in the original game, at this step I have eight possibilities for choosing p1, p2, p3. But now eight is not invisible by three, and so clearly these distributions are different. OK, back to step one. Step one was the question about what is the success probability of winning in this modified game. So the first observation is that as long as the oracles does not crash, as long as it's consistent, both worlds are actually the same. Because what happens in both worlds is that I just pick a random answer, making sure that all the round functions and the encryption oracle is a permutation. And this is also what I do in world two. So there is no difference as long as it does not crash. So it also means that we have to study exactly this. What is the probability that the modified game crashes? So again, drawing some lines. What is the probability for a crash? OK, so now I modified the picture a bit, because I saw that it's clearer. So I put the inverse of the encryption oracle there, so the decryption oracle. And this thing has to be the identity. So if I put the same queries that I had before, that yielded a crash, so I started with those queries, and then this was the query that resulted in a crash. Because I here started 0, and clearly with this being different, I cannot end up in 0 anymore. So this is inconsistent. So what causes this crash? A crash can be seen as a sequence of queries which are connected in all but one positions. So this sequence of queries is connected here. Obviously, it's also connected here, and it's not connected here. So connected in all but one positions, this is exactly what makes the modified game crash. So and now it's not too hard to bound this probability. So what is the number of sequences? I make Q queries at most to each of the t plus 1 oracles I have, so this gives me at most Q to the power of t plus 1 possible sequences. The probability for a sequence to be connected in all but one positions is t plus 1 for the choice of the position where it's not connected times 2 to the minus t over n. Because for each position where it's connected, the probability to be connected is 2 to the minus n. And I have t positions, and then you're just multiplying them to get an upper bound on the probability for a crash. And this actually caps Q at around 2 to the t divided by t plus 1 n, where t is the number of rounds. And then just to have you shown this in the paper, it looks different. So here I'm not going to into details, but so we have these two parts, and they exactly correspond to these two steps. And this is step one, which I just explained, which is the nice, nice part. OK, so very briefly what does this result mean? So if you want to break this cipher with idealized permutations, then you cannot. Or you have to make a lot of queries. So what does it mean for a concrete cipher? So it means if you want to break a cipher, you can interpret it like this. It's a generic attack, which is also the question I kind of started with. If you want to break the cipher, you have to make use of a special property of the permutation. But special property could be anything. And for a concrete instance, what does this result imply on the security of AES? It doesn't imply anything. OK, so the last part, further results and future work. So in the paper, what we have on top of what I explained here is that we also study the expected resistance for such a construction against linear cryptanalysis. So we compute the distribution of biases for linear approximations where you run over all possible keys. And we have a concrete proposal using AES. And how is this motivated? So this is motivated by the following idea. So the slide says a concrete proposal or how it started. So the proposal is that you, one of the variants of the proposal is that you, for P1 and P2, you take AES with a fixed key. And on top of, and this is not reflected in the general statement, but you take the same key. So you take the same round key everywhere. And then the intuition is that this could be a good block cipher against related key attacks. This is the intuition. And this is how the whole thing started. So we were looking for ways to build block ciphers that have a good chance to give some resistance against related key attacks. And then we started investigating this construction. And then we thought, OK, this is so simple. We should be able to prove something. And then we checked, is there what is known for in the non-related key setting? And it turns out, well, this has to be settled first. So this is something we also have in the paper. Outlining this for future work. Yeah, other future work. So obviously, it would be nice to improve the bound. And then also, it would be nice to get closer to actual constructions. So if you look at AES, then these round functions are not all different. It's always the same round function that's applied. It's an iterated cipher, which makes very much sense for our implementation reasons. So it would be nice to not assume that all these round functions are different, but the same. And it's a similar question. Could you prove a similar result when all the keys are actually the same? And then as a last point, I'd like to mention that from a provable perspective, in this setting, this key alternating cipher does not seem very nice. It seems very difficult to get good bounds. And one could also try to come up with new ways to design block ciphers where having this provable aspect in mind and see if you can find something nicer there. So a bit more on how to improve the bound. We conjecture that the lower bound is actually the one that I derived in this step one. And as I said, we already have improved this to the 3 over 4 in for more than three rounds, more than two rounds. And the first challenging step would be to get a bound that improves with the number of rounds. And that's all I had to say. Thanks. So we do have time for one or two questions. So with this bound, you can find the key. That's all we know. Otherwise, we did not consider this. No, no, the bound is not tight. I mean, this is something you could maybe also hope. Either you improve the bound, or by looking at this involved proof, there might be some kind of new ways of attacking these things. Any other question? Let me actually ask something. So this construction that when you instantiate your construction using AES, are you able to say anything concrete about its security properties? For example, how would your construction instantiate it over AES would behave against some attacks like linear analysis? No. You cannot say anything concrete about that? No. OK. No, no, you have to look at AES. No, I mean conditional, let's say, on some property of AES. Could you say something about? No, no, as I said, for AES, this basically doesn't mean anything. OK. All right. Any other question? Yes, well, let's thank Craig again.