 We'll move on to the second talk, so the second talk in the session is entitled Towards the Nursinging the Non-Key Security of Block Fiber. The paper is by Elena Andreeva, Andrei Bogdanov, Bart Menink, and Andrei Stiminthotov. Hello everybody, I will be talking about non-Key's accent. There are possible formalizations, at least for some idealized cyphers. It's indeed joint work with Elena Andreiva. So, non-Key's attacks will be considered here in the sense of what Knozomint Danen proposed at April 2007. Here's our contribution. So, we put forward a notion of non-Key security that has been known to be quite a difficult problem, but we'll see about the limitations of this notion. Then we show that non-Key differentiability is meaningful, meaning that attacks on the existing primitives that fall into our model actually imply violations of the security with non-Key in that model, which would suggest that it's meaningful. And then the notion is constructive in the sense that it's possible to actually prove non-Key security for some constructions. More specifically, we'll be dealing with vice networks and universal cyphers to show constructiveness. Okay, so I will start with a very brief background on security models for block cyphers. The classical model for block cyphers was instability, where you try to distinguish the block cypher from fixed random permutation and show that the key is secret. This sort of disregards the online structure, that's why people came up with extended instability, which is quite the same, but additionally you get access to the underlying primitives as pattern survey, which reflects the structure, maybe slightly better, than just plain indistinguishability. Then there is indifferenceability. So here we are distinguishing block cypher not from a single random permutation, but actually from the set-up permutations, from ideal cypher, where you draw the permutation and you work every key from the set-up permutation, so that's what the ideal cypher means. And this also assumes some idealized underlying constructions and some type of simulator, but we'll see that in much more detail. And here the starting observation that even this taxonomy, if we want to model the known key in taxon, it might be not that reasonable to deal with those, because we actually know the key we are computing with and this immediately leads to the tax on this set-up, because indistinguishability implies key recover security. So we might want to deal with the indifferenceability instead and try to find ways how to include a non-key setting there. So once again our goal is to incorporate the knowledge of the key in the model, some ideal and like primitives such as amoracos or random permutations, the knowledge of the key to the adversary actually and the knowledge of the key of course also to the block set in the compose setting. And this is resulting in the so-called non-key indifferenceability, which I will now introduce starting with the classical notion of indifferenceability by Marwark et al. from DCC04. So here we have two worlds. This is the so-called compose world where we have the actual structure of your block set for that might depend on some unlikely permutation. And in the rise world we have the ideal setter and some algorithm which is called a simulator, which simulates the behavior of this permutation. So this simulator actually works on the side of the construction. We're trying to pretend that this world is actually composable, though it's not. And the task of the adversary is actually to distinguish between those two. And for that the adversary is given two interfaces. The left interface to the big oracle and the right interface to the smaller. And now in the classical setting the adversary is allowed to choose the key and to forward some queries backwards and forwards for the societically online permutations. Again we want the adversary to distinguish. And this model is pretty generic. It allows to model chosen or basically any keys because in many cases this is not even formulated explicitly for chosen keys. So now what we want to modify in that setting is that the key is known and fixed, but not by the adversary, some days. And it's public, so every entity here actually knows that key. Including the simulator, which is important, which is not necessarily the case in the classical simulation setting. And then again the adversary is given two interfaces. And then there's nothing which will work. And then we need to distinguish between those two. So it's important that the key is here known and fixed and that the adversary is not the one chosen key. So let us have a look at how some notions are connected. So the general inferentiality as it runs out actually implies the known key inferentiality. In other words the advantage the known key inferentiality adversary might have is not more than the advantage the general inferentiality adversary has. But in the other direction of course it doesn't hold and we do have a counter example. So this basically says that there are constructions which are not the chosen key in the inferentiality secure. But those constructions are known key secure. Because known key security is a wicked notion because it doesn't choose. And here is an example of such construction. So as I will show later it seems to be known key and differentiable. But in the chosen key setting it's clearly differentiable. So one way to see it is to observe that if you have two different keys then the underlying permutation still remains the same. The adversary can actually exhort those keys out and for two distinct keys they will be dealing with the same permutation. So this is one way to see it or to use some details of our model but there is also another way to see it. And it also involves here composing in cypher. But here we are using the fact that in the chosen key in inferentiality setting the key is actually not necessarily known to the simulator. So that the simulator cannot easily compose. But it's perfect enough just to have one counter example. So then we can have a look at actual constructions where known key infertibility makes sense. For instance those are crystal ciphers and we are generalizing the results of Nusseld and Bremen published for Balanced Fist in H.Critter 7. So here we are dealing with a generalized crystal cypher without lines. For example those are people widths and then it will be over phyciliteration using one line updates but that one then rotates. So it's something like type 1 or type 3. But with some explicit key input. It's one construction and another construction is the other one that people usually consider when proving general infertibility or chosen key infertibility. So here you don't have the input of the key or external. Basically here instead you have a function that sets some round key and this input from the line. Basically the contracting random model is how you can simulate the explicit key input for this construction. And this has been well studied at least for the Balanced Fist. To my example Balanced Cypher. Now we want to generalize the attack on Balanced Fist. So here we have the details of their attack. I will skip most of them but it's important to see that you basically over 7 rounds of the Balanced Fist can construct a relation on Glen-Tex and Cypher-Tex given the knowledge of it. A is defined in some way depending on your specific construction. So people here can choose some values. It's important to see that it's possible to construct such a relation between Glen-Tex and Cypher-Tex that wouldn't be possible for an ideal permutation. And now it's basically the relation. Now we can construct a similar thing for more than two lines. So we are generalizing how Fist in the sense that we are taking more lines. And this also increases of course the number of rounds. So it's now 4L minus 1L is the number of the lines in the Balanced Cypher. And it holds for the Balanced case as well. And it actually generalizes. The overall idea is pretty much the same that you construct some relations on parts of inputs and outputs that you wouldn't be able to construct in the ideal case. Now we want to see that the existing non-key effects, at least on those Cypher's that have some idealized components, that they do translate to the valuation of the security under the non-key interchangeability notion. And how do we do that? So we basically absorb that the distinguisher in those cases defines predicate phi. And then the distinguisher in those tags makes queries, yeah? From some query list and then the distinguish outputs 1 if the predicate holds and 0 otherwise. And then the non-key interchangeability advantage is defined as a difference. So we bring those two values for the real construction for the predicate to be satisfied and for the ideal construction. And since the tag works we know that this will be one for the actual Cypher. And for the real Cypher we can see what if there's the bound on the probability will be. And here you can see an example of a predicate. Basically, we have some properties on the inputs and outputs. So this basically implication that you have then evaluation of the model in some more concrete form. So here we have the statement, yeah? That we show that the advantage of the non-key interchangeability distinguisher is actually at least 1 minus. The value where QES is the number of queries the simulator makes to the ideal Cypher, yeah? To the big one in the right form. It's always important to include this number of queries for the simulator because if you allow this number to be high then you are not necessarily getting informative statements, yeah? But here the number of queries the simulator makes can be actually very small. So this is about that. Now we want to see that non-key interchangeability is actually constructive. And here we have two examples. We have the example of a balanced file still with contracting, which is more powerful as your ad function basically. We know from stock 11 that for 14 rounds you have this bound on the general interchangeability which translates as we know to the bound on non-key interchangeability. Which means that at least one way to prove non-key interchangeability is to prove the general interchangeability. So that the same bound at least holds also for the non-key interchangeability. That was easy. Now I want to see some integration of how to prove even Mansoor secure on the non-keys. And this is specific proof so we're not using the proofs of general interchangeability for this construction though there exists some. And the intuition to see why it's secure is that one way to see it is to absorb that if the simulator knows the key then it can always absorb it to the queries and to the input and to the output of the query the simulator makes to the big oracle. And in that sense it will always conform so this is at least the reasoning for one round of even Mansoor. Similar reasoning holds for more rounds but the idea is here to see that once the key is fixed and the permutations are different you are basically dealing with one readily drawn permutation. And then it's not easy to distinguish it from another readily drawn permutation. So this is the idea. Okay this brings me to some conclusions and open problems. So in this work we have presented one way to argue non-key superiority but it has some limitations. So we don't know how to formalize non-key attacks for non-black box and blank permutations. So for instance for something like AES or some other constructions with SP structures inside. And it's also some independent limitation that the ideal model and the differentiability is an example of an ideal model is that in the ideal model the sense of your security actually becomes void for small scale underlying primitive. So if you again switch to AES and you have your APS box then the proof in the ideal setting does not go much about the security because it will be in most cases bound by the size of your underlying primitive. So we don't know how to deal with such cases. And yeah it will be interesting to see new ways also to argue non-key security for non-ideal unlike components maybe also for smaller size. That will conclude it. Thank you. So for the Wunstein with the general system structure for the 16 rows, yes. So the Wunstein result is on... So you put on 14 rows? It was proven for 40 rounds I think. Okay. But it's 16 in about there. Okay, so I actually missed it. So my question was that Wunstein is in random oracle model. So the round functions they consider it as random oracle. Exactly. And it's exactly the same construction we call here G, F and R. So that you can have the contracting random oracle if you want to account for explicit key input. So your F function in one round is going from N over 2 plus K to N over 2. Yes, so it's where you input your key. But the proof by Wunstein et al was not conserved that explicit input but it's easily transparent to that case. Okay, thank you. Any other question? Now let's thanks this paper again.