 So the second talk is key production security of key sponges by Batman Inc. OK, yes. I cannot walk around here, so I have to stand here. So welcome to my presentation. A bit of explanation to the picture. So there has been a lot of analysis on the key sponge. And it turned out that there was one small piece of the analysis that was not really finished yet. So basically what this work does is the last piece of the black box security of the key sponge. So I think most of you know the basic sponge construction. It's a hash function. It takes a permutation, in this case, permutation pi, and then you have an inner part and an outer part. And the message is always absorbed in the outer part step by step, then you permute the state, and in the end you truncate data by squeezing the outer part. The construction turns out to be very popular. Since the introduction, it has been used in many hash functions, including SHA-3. Many lightweight hash functions are based on it. And it is proven that if you take an ideal permutation pi, then this construction behaves like a random oracle up to 2 to the c over 2, where c is the capacity, so the size of the inner state. But this is just keyless hashing, keyless cryptography, just hashing. It turns out that you can also use the sponge in a key setting. And this is what the keyed sponge does. And originally, the original idea of the keyed sponge is just to glue together the key and the message. So you use the normal sponge as a black box, but as input of the message, you just don't take the message, but you glue together the key and the message, and then you pad it into orbit blocks, and then you absorb it step after step. And this is the original keyed sponge, which is currently known as the outer keyed sponge, because the key goes into the outer part. There is an alternative, namely the inner keyed sponge, where the key goes into the inner part. So you just initialize the state by having the key k in the inner part. It doesn't need to be c bits. What matters here is that the key size is smaller or equal than c bits. And this is the inner keyed sponge. Finally, there was the full keyed sponge, because it turned out that you do not need to have, if you have a keyed state, so if you have a secret state, you do not need to restrict yourself to orbit absorption. You can have full state absorption. And this is the full keyed sponge. And note that the full keyed sponge is a generalization of the inner keyed sponge, because you can just pad the message in such a way that you have orbit message blocks, and then you pad it with zeros. So the full keyed sponge is a generalization of the inner keyed sponge. And this work therefore considers the outer keyed sponge and the full keyed sponge. So the focus in this work is on the outer keyed sponge and the full keyed sponge. And this is a picture that covers both of them. So I'm sorry I changed the style, but it's the same function. So we have a capacity c, which guarantees basically the security, which is the capacity during the squeezing. So here you have a squeezing of orbits, and the capacity is c. And for absorption, you have a capacity which I currently called c prime. So the absorption of the key, the key is first padded into blocks, then a message which is padded into blocks. The capacity is c prime, which is c if you take the outer keyed sponge, and which is zero if you take the full keyed sponge. And this picture does covers both the full keyed sponge and the outer keyed sponge. Now if you look at the security of the scheme, the scheme has received a lot of analysis. But if you really simplify the bounds, really look at the core terms in the bounds, you see that both have a comparable security bound. So if you take m to be the data complexity, so the cost of making construction queries, and the time complexities, which in this case corresponds to the number of queries to the permutation pi, then the bound really is something of m squared over 2 to the c plus m times n over 2 to the c plus some magical term. And this applies for both the full keyed sponge and the outer keyed sponge. There are a lot of constants hidden in this equation, which I did not put on the slide. But at a high level, this is how the bound looks like for both constructions. This work focuses on this last term, this magic term here. And what this term basically says is it bounds the probability that the attacker predicts the key. And what do we mean by this? So we focus on the key absorption part in the sponge. So the rest we forget about. We forget about the rest. We focus on the key absorption. In this case, we have lambda blocks, which are absorbed one by one. And now we consider the following game for an attacker. So the attacker can make primitive queries, evaluations of pi, namely n of them. And then we randomly select a key. And the attacker wins if the query history, so all queries that the attacker made, cover the evaluation of the key absorption here. Indeed, once the key is selected and you absorb the key here, you make lambda permutations of pi. And the attacker basically wins the game if these lambda queries are already in a query history. So it's a weird game, right? It's not a security model on its own. But what happens if you look at typical key sponge proofs? This is typically a bad event. So if you look at the analysis, somewhere hidden in the analysis is a bad event, namely the event that the attacker accidentally broke this. However, in this work, we focus on this bad event particular, and that's why we call it the key prediction security. But it's not a security notion on itself. It should be seen as a part of a big security analysis of the key sponge or the key duplex or whatever. So how large is this key prediction security? So the attacker needs to make queries. And then the key is selected and the attacker wins if his queries cover the evaluation of k. Now, first consider the case where the key is one block. So here we change the picture. So the key is just one block. It's absorbed, then the permutation is evaluated, and then you start with message m1, et cetera. And this happens, for instance, in a full key sponge where c prime is zero. It also happens in the outer key sponge if the key is smaller than the, the key size is smaller than the rate. But for this, the security bound is pretty obvious. The attacker makes n queries. So it can make n permutation attempts. So it can make n queries of this permutation for different key guesses. And the attacker wins if any of them is correct. So basically, the key prediction security would be n over 2 to the k. However, for more than one key block, the analysis turns out to be significantly harder. And there is a work, there is an analysis of Ghazi et al, who considered this event as part of a big analysis. And they proved that the key prediction security is at most b to the lambda, b is the full state size of the permutation, times n over 2 to the k over 2. And it's tedious as a technical analysis. But it's used in many sponge proofs. Many follow-up works use this analysis of the key prediction security as a black box, even though it was not named key prediction security. But they used this analysis. This result is bound as a black box. But it should be obvious that this bound is not really tight. I mean, it's counterintuitive that you have a very bad bound. Here you have basically 2 to the k security. Here you add 2 to the k over 2 security. So if you look at a concrete example, so suppose we take the outer key sponge. These are some really arbitrary numbers, like a 320 bit per state size, a capacity of 256 bits, a rate of 64 bits, and a key size of 64 bits. If you, for instance, take these numbers, so an outer key sponge with these numbers, the security bound really behaves as follows. So here you get the key prediction security term. So these are the basic terms, which I'm not touching in this work. The key prediction security would be n over 2 to the k. So you basically get, I mean, it's a dominating term, n over 2 to the 64 bit security. However, if you now double the key size, so you take the same b, the same capacity, the same rate, but at twice as large key, you also get 64 bits of security. And you catch a key and norks. And these are the parameters. Note that key was a full keyed sponge. The other ones were outer keyed sponge. The red ones are the ones where the key is larger than the rate. One would be tempted to say that, in this case, the key prediction security improves the analysis. But there's a trick here, namely that these schemes, they were indeed outer keyed sponge. But they initialized the state as if it was a full keyed sponge. So if you look, for instance, at ASCON v1.2, this is just a print screen from their paper. You see you do full state absorption and full state outer state, outer part absorption and squeezing. But the initialization of the key is on the full state. And that saves them, well, saves them. I mean, that means that the analysis we did in this work does not improve the analysis of ASCON, but the original bound already applied in the same holes for catch it. So I don't want to oversell by saying that our results apply to ASCON and catch it. They don't apply to ASCON and catch it because the analysis was already, the scheme was already good enough so that we didn't need to do the work for ASCON and catch it. However, if you still look at, for instance, the ASCON parameter, so if you take the ASCON parameters with 322, 256, 64, and 128, which is the example which you saw a couple of slides back, then this would be the old bound, so m squared over 2 to the b, n over 2 to the c, plus n over 2 to the r over 2, so n over 2 to the 64. And the new bound would basically improve it to n over 2 to the 128. So intuitively, if you limit the unlike 2 to the power 160, the old bound to give security as long as the offline complexity is 2 to the 64. And the new bound to give security as long as the offline complexity is at most 2 to the 128. But once again, this is only for the parameters. It doesn't apply to ASCON itself. But a case where it does apply is TROPE. So TROPE is how they call the lightweight framework for network protocols. And they use the sponge for many things. So they wanted to have a simple, small code size, so they used the keyless sponge as a black box for everything. So also for message authentication. So they used the keyed sponge as a black box, and then the inputs are always absorbed as if it was an outer keyed sponge. And these are the parameter sizes of TROPE. So forget about the big ones. Now for the small one, it has a 400-bit state, a 256-bit capacity, a 144-bit rate, and a 256-bit key. So the smallest version of TROPE effectively absorbs the key in two rounds. So this means that if you would apply the bound, the analysis to the old analysis to TROPE, you would get a bound that basically looks like this. So the first parts don't matter in this work. So this is the security, 2 to the 128-bit security, even though you use a 256-bit key. But now we improved it to N over 2 to the 256. And intuitively, this means that if you limit the online complexity to 2 to the 100, in the old case, you only had security as long as the offline complexity is 2 to the 128, but now it gets to 2 to the 156. Of course, one may argue that 2 to the 128 is still quite big, but it is an improvement. So to conclude, this key prediction security was basically the last missing link in the keyed-sponge proofs. So somewhere hidden in this keyed-sponge proof analysis, there was this term, but it was not optimal for various results. It's close to the optimal bound. There is a small loss due to a proof technique, but there is no attack faster than a key recovery. It applies basically to every usage of the outer keyed-sponge with a key larger than a rate. There are other examples, like HMAC chat tree of Naito and Yasuda and the sandwiched-sponge that used the result of Ghazi at all as a black box, and now they can use the new result. Then there's strobe protocol framework and also in lightweight permutations, if you use a really small permutation, then you could run into problems where if the rate is smaller than the key. But basically what you should do in this case is just do full state absorption in the first round. So just initialize the key, the state using the key. That concludes my talk. So I'd like to thank you for your attention. One quick question maybe for Bat. So among all the keyed-mode for sponges, which one have a tight security analysis now? Does it close the gap for some modes, or is there room for improvements? Yeah, that's a good question. I mean, the bounds I gave in the slides are just I'm abstracting away a lot of things, right? But I think the last bound of Asia Group 2017 is pretty tight. I don't really see an attack that, I mean, you always have these small, I mean, that's a general analysis that covers many variants. So if you look at specific variants, sometimes maybe you can drive a better bound. But that bound I think is pretty tight. It's general, but it's pretty tight. Okay, so if there is no other question, let's thank Bat again.