 Okay, welcome to my presentation. Janik already gave a very nice introduction on how important and useful 3-core block ciphers are. Let me nevertheless give you a brief introduction as well. However, I will do it a little bit quicker then. So a normal block cipher is just essentially a permutation. For every secret key it's a permutation which means that if you encrypt the same message you get the same cipher tags every time. And to add some flexibility people used tweaks and a tweak randomizes the scheme in some way. It's a public parameter associated with every tweak. It gives an independent looking permutation. And the relevance of it already became clear in this picture in this scheme of SCT. To give you an other example, let me discuss this. Well, I called it OCBX. I learned that I should have called it TataCB. So this is essentially the generic design of OCB1, OCB2 and OCB 3. And I think it's one of the pioneering designs in using tweak-core block ciphers for such applications. And I think it also shows how why tweak-core block ciphers are interesting and important for security analysis. So what we see here, so again authenticated encryption scheme. A is associated with data, M is the message, you get a cipher text and a tag. But we use a tweak-core block cipher everywhere where the tweak is a consist of a nonce and some position identifier. So the nonce is a unique value for every encryption. And the position identifier uniquely determines at which position the tweak-core block cipher appears. And because it is a tweak-core block cipher, every new evaluation of this tweak-core block cipher is done under a different tweak. You get independent looking tweak-core block ciphers everywhere and you can easily prove security of the scheme. Note that by changing the tweak, you're essentially changing the function. So there is a site condition here, namely that you want that changing the tweak should be very efficient. So it should be very efficient to go move from one tweak to another one. So the question is how to design tweak-core block ciphers. Janik showed already that there are various approaches to do it from scratch. And the most recent one is this tweak-key framework, which kind of blends the key and the tweak. In this work, I focus on generic design where we use an existing primitive like a block cipher and build a tweak-core block cipher on top of this. So in the first formalization of tweak-core block ciphers, where it is called at all, they also introduce two tweak-core block ciphers based on a normal block cipher. Those are these two actually. The most interesting one for us is now the right one. So what we see is that it has a normal block cipher, which is masked by some universal hash function on the left and on the right. And it's similar to what was proposed by Rockaway two years later. Rockaway improved this scheme specifically for the usage in OCB2. And the idea of the new scheme is that the masking is not based on a universal hash function, but you use the same block cipher. And the tweak consists of a nonce, of course, and alpha, beta, and gamma. And alpha, beta, and gamma are used to represent the position in the OCB scheme. So the mask is then computed in this case as 2 to the power alpha times 3 to the power beta times 7 to the power gamma times the encryption of the nonce. So it was introduced for OCB2, but there are many Caesar submissions that adopted this idea. So this is block cipher based approach, but it appears like there is a current trend towards permutation-based designs. This was already apparent in the SHA-3 competition with Keitschak, the permutation-based hash function. Also, in the Caesar competition, there are quite some permutation-based designs. And it is possible to transform this to a permutation-based setting. As a matter of fact, in 2014, the MIN offer team introduced the tweakable Evan-Monster reconstruction. And it is similar. It uses a public permutation. But it uses a public permutation, and the masking is done in the form of 2 to the power alpha times 3 to the power beta times 7 to the power gamma, times the key-exort with a permuted version of the key. And the tweakable Evan-Monster got generalized a lot by Koliati at all last year. And it is clear that there is a relation between this scheme and the XCX scheme of the previous slide, because if we take, for instance, XCX with non-zero, and we take the normal Evan-Monster construction, this one, and we plug it into XCX, we get a disconstruction that very much looks like XPX. So there is a relation between these two schemes. So I already mentioned that in the Caesar competition, there are quite some tweakable block cycle-based designs. And as a matter of fact, we can group these directions in three approaches. So we have this dedicated tweakable block cipher design. We have XCX-inspired designs, and tweakable Evan-Monster-inspired designs. And if you check the list of initial Caesar submissions, there are 57 submissions, 18 of them are based either explicitly or implicitly on tweakable block ciphers. Actually, I have the one that only participated in the first round. I put it in plain text. Both is the second round. I didn't manage to update it to the new results from this last night. But it turns out that six of these schemes went to the third round. So six of the third round candidates are tweakable block cipher-based. In this work, we consider permutation-based designs, so we effectively generalize this tweakable Evan-Monster approach. In more detail, we consider XPX. And XPX is a public permutation in the middle, masked by, on the left, T11 times k, X or T12 times pk, and on the right, T21 times k, X or T22 times pk. So the idea is that the tweak is also formed T11, T12, T21 and T21, which comes from a certain pre-described tweak set at T. And this tweak set depends on the use case of the tweakable block cipher. So for now, the tweak set can still be any set. However, it turns out that the security of XPX strongly depends on the choice of the tweak set. At a high level, we will essentially make a separation, so we synthetically analyze all possible tweak sets, and we'll make a separation between weak tweak sets for which XPX is completely insecure, normal tweak sets for which you get single key security, and normal tweak sets are essentially the ones that are not weak. And if you put slightly more conditions on the tweak set, it turns out that you can get related key security. And surprisingly, there is no much efficiency difference among these three cases. So it's very easy to get related key security for a scheme if you have normal single key security. I will come back to this later. So what now remains to do is to essentially formalize what we mean by weak, normal and strong. And let me start with weak tweak sets by giving an example. It's XPX again. Suppose now that the tweak 0000 is allowed. So the tweak set, the set of allowed tweaks, contains tweak 0000. I think it's trivial to see what happens if you use this tweak set, this tweak 0000. For any message M, the output of the XPX is just B of M. It's independent of the key, and you can break it trivially. So this tweak should not be allowed. There are different tweaks, like 1011. If this tweak is allowed, the attacker can use this tweak for message zero. Then we see that the input to the permutation equals K. The output equals P of K, which cancels out with P of K from the mask and the output is K. So if this tweak is allowed, you have a key recovery attack. There are more advanced cases like 1002. There are also cases where we have couples of tweaks that should not be allowed at the same time as the rest of the week. So there are some silly cases in a certain way, and it makes sense to limit the tweak set to exclude these cases. This brings me to the first definition, which is the definition of valid tweak sets. It's a technical definition. I will not go into detail, but it's a technical definition, but it's easy to verify whether or not a tweak set is valid or not. We actually proved that it's a minimal definition. We showed that if a tweak set is not valid, then a tweak set, then XPX is completely insecure. So it's really a minimal definition of validity. And these are effectively the weak tweak sets. We will show the opposite, too. In fact, we will show also that if the tweak set is valid, then you have security, then XPX is secure. And this is done in the normal, well, strong tweak opposite to random permutation security model. So the attacker is given access to either the construction query, either to the construction XPX or a random equivalent, tilde pi, and the attacker is also given access to the underlying primitive P, which is assumed to be an ideal permutation, and the complexity of the attacker is countered by the number of queries. So it can make Q construction queries and R primitive queries. And then we proved that if the tweak set is valid, then we get birthday bound security of this construction, where Q is the number of construction queries and R is the number of primitive queries. So this is just plain single key security, but we also consider related key security. And in related key security, the attacker has more power. What the attacker can do is it can query the construction, not only for the tweak and the message, but for every query to the construction, the attacker chooses a function phi, which is the construction evaluation for key phi of k. So it can choose for every query a function to transform the key. And this gives the attacker extra strength. It makes sense to restrict the set of key-deriving functions in some way, otherwise you can trivially break it. And there is a well-known function, it's a function that consists of the set of XOR differences. This was already considered a long time ago in the formalization of related key security of Balara and Kono. And so what we defined by phi XOR and consists of all functions that map k to k XOR delta. The attacker can choose delta for every new evaluation. And it has some relation to silly implementations where a key is, for instance, refreshed by adding a counter. In this case, you would facilitate attackers with such sets of key-deriving functions. And we also look at a slightly stronger set, which we call phi p XOR, which consists of the set of all functions that map k to k XOR delta. Or the set of functions that, abusing notation, map p of k to p of k XOR epsilon. So the attacker can always choose delta or epsilon. The second set looks a bit contrived, but let me recall that the masking in XBX is of the form t i 1 k XOR t i 2 p k. So in this respect, it makes sense to look at these two sets of key-deriving functions. And now for these sets, we define and we prove the following results. So first we show that, so first for normal PRP security where the attacker can only make forward queries, we show that if the tweak satisfies this condition, it doesn't contain silly tweaks. And t 1 2 is always non-zero. So in the use case, t 1 2 is never zero. Then we get XOR related key security. And if you also condition that t 2 2 is always non-zero and you have this tactical side condition, then you get even strong related key security for XOR differences where the attacker can make inverse queries. For the more involved set, we have similar results. So for instance, for the last one, we have that if the tweak set is valid and t 1 1, t 1 2, t 2 1 and t 2 2 are always non-zero, then you get strong related key security for this strong set of key-deriving functions. So I will not go into detail in the proof. Instead, I would like to give you some examples of how this result can be used, what it means and how it can be used for certain applications. And let me start with a very simple example, which is the normal FM monster scheme. So on the left, we see XPX. On the right, we see this normal, this well-known FM monster scheme. And FM monster is covered by XPX taking as tweak set just a singleton, just the tweak value 1 0 1 0. I mean, if the tweak set consists of one tuple, the user always has to take this as the tweak, which effectively means that it's just a normal block cipher. The tweak set is valid, which means that this result, which means that our result shows that FM monster is a secure block cipher. Well, this should not sound as a surprise to you because this has been proven many times already. But it's just to show that, well, what it means. And in general, XPX for any possible, so if you take any tweak set of size one, XPX is a normal block cipher. So as a side result, it essentially covers a wide range of even FM monster-ish block ciphers. XPX also covers this XEX with FM monster. So if you take XEX with FM monster installed into it, it's covered by XPX, so it's a more involved set, a more involved tweak set. So what we do essentially is we take alphabet and gamma, just any possible XEX tweak, and we define T11, T12, T21, and T22 on top of this. So the Tijs are functions of alphabet and gamma, and that's the way we can define XPX to cover XEX with FM monster. And this set is valid, and as a matter of fact, it also satisfies that the values are always non-zero, because in XEX, 2 to the alpha, 3 to the beta, 7 to the gamma is never one. It's never zero, of course. So this one is never zero, of course. XEX has the condition that this 2 to the alpha, 3 to the beta, 7 to the gamma is never one, so you always never have a zero here, so you have very strong related key security for this very strong set of key-deriving functions. And to show you how this can be used, let me go to the COPPA Authenticated Encryption Scheme. So COPPA is a design by Andreva et al. 2014. It has associated data, the message, using some magic, you get the ciphertext and the tag. For now, it's not important to look at how the scheme works, but what it does is that COPPA is implicitly based on XEX, in which internally AES is used. So COPPA is based on, is XEX based on AES, and there is a variant of this that's PROSCOPPA, and PROSCOPPA differs from COPPA in that it doesn't use AES, but instead it uses F and Montserr construction. So PROSCOPPA is COPPA based on AEX, XEX based on F and Montserr based on APRometation. And it makes sense to question to what extent can we use the existing security results of COPPA to guarantee security of PROSCOPPA. So to what extent do the results carry over from one scheme to another one. And for single key security, that's quite a straightforward question. It's a fact, almost a trivial question. And to see this, let me look at how the COPPA security proof works. So what's done for COPPA is essentially as follows. The first step is a reduction to XEX. So one reduces the security of COPPA to the security of XEX up to the birthday bound. That's the existing proof. Rockaway analyzed XEX and Rockaway proved that XEX based on the blocks of E is birthday bound and secure. So you reduce the security of XEX to the security of blocks of E. Then you plug in XEX and you hope that AES is secure. That's how the COPPA proof works. Now for PROSCOPPA you don't stop at the blocks of E, but we have an additional step. We have a monster construction based on A permutation. So we make one more step, namely that every monster is secure up to the birthday bound. And that's for a single key security. So this is nothing surprising. Now for related key security it turns out that for COPPA you can do the same trick. So if you dive into the proof of COPPA you see that you can do the same trick for related key security. So the related key security of COPPA reduces to the related key security of XEX up to the birthday bound reduces to the related key security of E up to the birthday bound. And then you assume that AES is related key secure. But what if we go for PROSCOPPA? For PROSCOPPA we need to make an additional step. And this step is the related key security of F and monster. And F and monster is not related key secure. You can break the related key security of F and monster in two queries. So this approach does not work for PROSCOPPA. It doesn't mean that PROSCOPPA is secure. It just means that this naive straightforward reduction doesn't work. And now we can use XPX. Because XPX is essentially covers XEX with F and monster. So we just skip the step through E. We make a direct step and we get related key security. Similar idea can for instance be used to MinAlpha which uses this tweakable F and monster. And so MinAlpha was defined to use tweakable F and monster. But you can also see it as based on XPX with quite a simple tweak set. And using similar techniques you get related key security. A final example which I think is interesting is the chess key design. So it's not an authenticated Christian scheme but it's a Mac function. And so we have of course a secret key. We have the message and then we do some magic with the key. And then you get the tag. So we have two pictures. The top one is for integral data. The bottom one is for fractional data. And the scheme is introduced by Mua at all in 2014. And the proof went as follows. So the proof essentially reduces the security of chess key to the security of three even monster construction. So it's not clear from the picture but somewhere in this picture there are three even monster constructions hidden. And the proof reduces the security of chess key to the security of these three constructions. But if you now look back at this proof, this is equivalent to XPX with a tweak set of three tuples. Namely 1-0, 1-0, 3-0, 2-0 and 5-0, 4-0. Because the attacker can choose every time which monster construction to query. Which is essentially equivalent to saying that the attacker can choose a tweak every time. This tweak set is valid. Which means that we get single key security of the XPX construction and we get birthday bound security. So we've redone the security proof of chess key. And the tweak set is valid but no more than that you cannot get related key security. And actually you can break related key security of chess key. If you have X or related key difference you can undo it with M1. You need to do some tricks here too but that doesn't harm the attack. But now if we adjust chess key, so I left some blank space here. I did this on purpose because now I'm going to plug in a permutation here. And this is, so what we do is we permute the state. We first X or the key, then we permute the state. And effectively this adjusted chess key is based on XPX with a tweak set, T prime, by consisting of these three tuples. And if you redo the exercise now, this tweak set is valid. It gives related key security and you get related key security of chess key. And you see the change is not expensive. You just have to pre-compute P of K once. And you get related key security. That's a simple fix of achieving stronger security. And similar techniques could be applied to key sponges and key duplexes because chess key can be seen as a member of these schemes. It can also be applied to various sponge-based C's or candidates. I said 10 candidates, these are the initial candidates. I think there are still three left in the third round which it could be applied. So to conclude, we introduced XPX. It can be seen as a generalization of tweakable ever monster and not a generalization the way Koliati had all did it with a number of rounds. But instead, looking at a single round and checking what level of security can we get. We achieved various levels of security ranging from insecurity to single key security to related key security. We showed that the result is various applications. Many C's or candidates, many initial C's or candidates could be covered by XPX and also various Mac functions. For further questions, it would be interesting to see what happens if we go for multiple rounds that you can get beyond birthday bound security, which could be of interest if you have small permutations. If you use the scheme with a big 1024-bit permutation, it makes no sense to look at beyond birthday bound security. But if you have small permutations, it makes sense. Another question would be to look at other settings where related key security is important and this would also give different sets of key deriving functions. That concludes my presentation. Thank you for your attention. Thank you very much.