 OK, welcome to my presentation. Well, we've seen on a previous slide what a block cipher is. So I can go over it quickly. It's a function that's essentially a permutation for a fixed key. If the key is secret, then the message gets encrypted to a ciphertext in a bijective way. In many applications, however, you want to have some flexibility. We saw this in a previous presentation, but there are many other applications. And a way to get flexibility is by using this tweak. And the idea is that for every key and fixed tweak, the scheme behaves like a permutation. But if you change the tweak, you get an independent permutation. And there are many applications of tweak called block ciphers. Formal preserving encryption is one. Another one that's very popular is authenticated encryption. I would like to give you an example of this. And this example is essentially OCB. So there are three versions of OCB, OCB 1, 2, and 3. But behind these schemes is essentially a tweak called block cipher based scheme. OCB is based on a block cipher. But if you look at how the proof is performed, how you can analyze the scheme, it's based on a tweak called block cipher, namely this tweak called block cipher based scheme. So it's a bit technical, but essentially we have a message. The message M is padded into several blocks. And these blocks are then encrypted to ciphertext blocks. Using not a normal block cipher, but a tweakable block cipher. And then also here, we have associated data and check some of the message, which get authenticated. But the important part to note here is that we have a tweakable block cipher that transforms the messages that does the cryptographic work. And the tweakable block cipher gets its input, of course, the key. But in addition, it gets its input a tweak. And this tweak consists of a nonce. The nonce N is a unique value for every evaluation. And it gets some tweak identifier, which identifies at which position in the scheme the tweakable block cipher is evaluated. This means that if you have two different evaluations of the scheme, the nonce will be different. But if you look at the same evaluation of the scheme, two different evaluations, for instance this one and this one, the tweakable block cipher calls occur at a different position. So they have a different tweak in such a way that every evaluation of the tweakable block cipher is kind of independent. And that's a way how the OCB scheme is generically proven secure based on the tweakable block cipher. The question now is how to design a block cipher. And there is a way of designing it generically. So we always refer to the hasty putting cipher as the first tweakable cipher. More interesting right now is, I think, the tweaky framework and Skinny and Mantis from crypto last year. Those are tweakable block cipher designs from scratch. Now the focus is on a generic design. So suppose we use a block cipher like AES, construct the tweakable block cipher on top of this. And then the first formalization of tweakable block ciphers by Liskov et al, they already gave two designs. So the first one is one that's based on two block cipher calls with a tweak excerpt in the middle. No one talks about the scheme anymore. I think there is a good reason for this because alongside this one, they also introduce another one which is more efficient. So it's a scheme based on one block cipher call where the key goes to the block cipher and the universal hash function evaluation. So H is the universal hash function. And the message just gets encrypted through this normal block cipher like AES, where the block cipher calls mask with the universal hash function evaluated on the tweak. So this is called LFW2. It's really similar, essentially it's kind of a predecessor of XEX. And XEX is used in OCB, in XES disk encryption, and many CSER candidates. So essentially it's used pretty much everywhere. It's an efficient scheme, but it only achieves birthday bound security. So 2 to the n over 2 security. What this means is that if the block cipher has a state size of n bits, then you can break the scheme in about 2 to the n over 2 evaluations. If you take AES, AES has 128 bits, you can break the scheme in 2 to the power 64 bits, which is usually OK if you refresh the key often enough. But if you take a lightweight block cipher or something like this, if you take a 64-bit block cipher, you only get 32 bits of security. And that's not enough. So what we look for is essentially a scheme that achieves security beyond the birthday bound. So beyond 64 bits or beyond 2 to the n over 2 bits security. And a notable way to do this is essentially to glue together various evaluations of LRW2. So the picture here is essentially a cascade of sigma evaluations of LRW2, where for ease of analysis, we have independent keys and universal hash function calls. At Crip to 2012, Landecker et al. proved that if you glue together two evaluations, this construction achieves security up to 2 to the 2n over 3. So beyond birthday bound security. And it was a small flaw, so it was fixed by Procter, but in the end, we know that if you glue together two of them, you get 2 to the 2n over 3 security. Lampets, who have went further than this, they looked at the general cascade of an even number of rounds and proved that you get 2 to the sigma n divided by sigma plus 2, acknowledging that it's probably not tied. So they conjectured, it's generally conjectured that you can get 2 to the sigma n divided by sigma plus 1 security. It also looks like this is the best we can get. So if you look at the table, what we see is we've got an efficient scheme, but only birthday bound secure. You can get to improve beyond birthday bound. You can even get to optimal security, but only asymptotically. So if the cost, the number of block-cypher evaluations, the number of universal hash function calls go to infinity, you get optimal security. And the question now is, can we do better? So can we get an optimally secure scheme which is reasonably cheap? And to do so, we look at a slightly different approach. So if you look at the original formatization of LISCOF at all on tweakable block-cypher, they suggested that, well, the key is secret. It's the same for a long time. The tweak changes a lot of times. So for efficiency reasons, changing the tweak should be cheaper than changing the key. But Jean-Arleau considered it the other way around. Essentially what they said is, well, the attacker doesn't have access to the key, but the attacker has access to the tweak. So looking at it from this way to make it secure, changing the tweak, the tweak schedule should be stronger than the key schedule. And inspired by this, if you combine the two viewpoints, you come to the tweaky framework, which essentially blends the key and the tweak. And there is a modular construction that already does this. Minamatsu did this in 2009. What it essentially does is the tweak gets encrypted to get a subkey, and the message is then encrypted with a subkey. And this one is beyond berthing by secure. If the tweak is short enough. So if the tweak length is less than n over 2 bits, you get beyond berthing by security. You can stretch the tweak a bit, but you can never get to optimal security, due to the 2n over 3 at most. Two years ago, we introduced two other schemes where the incentive was a bit different. So it was the goal to design a block-cypher-based scheme just with a single key. So not two keys, not a key and a universal hash function, just a single key. And we introduced two schemes. The first one is not that interesting for now. But they look similar. But essentially, the idea is that the key and the tweak get exored. This will be the key to the block-cypher. And the message is then encrypted using this block-cypher, masked with some value z, which is also coming from an encryption. So the masking and the key input to the block-cypher are a function of the key and the tweak. And we proved that this scheme achieves security up to 2 to the n. Optimal security, very efficiently, with only two block-cypher calls. And one at all generalized it. They found some other constructions that were optimally secure. But there is a twist. And this twist is that the security proof is in the ideal cypher model. So whereas the other schemes were in the standard model, this one is in the ideal cypher model. So if you look at the state of the art, the top five rows are not rekeying. So the key to the block-cypher is always the same. That's hence the last column. The key to the block-cypher is not influenced by the tweak. You can get optimal security only in the limit. In the other one, you can get optimal security fairly efficiently, but only in the ideal cypher model. The question always, can we get the best of both? So optimal security of an efficient scheme in the standard model. And to try to get this, we have to dive into a proof. I will not dive into the proof exactly, but essentially into the proof technique. So if you look at this optimally secure scheme, how the proof essentially goes is as follows. So we have this scheme. We consider this scheme with an ideal cypher. And we compare it with an ideal tweakable permutation pi tilde. And the proof then is essentially a probabilistic argument in saying that if an attacker wants to distinguish these two schemes, so the scheme based on an ideal cypher E, from an ideal permutation, it succeeds with probability at most q over 2 to the n, which means that the attacker has to make 2 to the n evaluations, which means optimal security. Now suppose we want to prove the scheme in a standard model. This means we start from a third box, or the first one, which is this scheme based on any block cypher E. And now we want to prove that this scheme based on any block cypher E is indistinguishable from pi tilde. And the question now is, how can we prove this? Well, if you look in the literature, if you look at fairly any symmetric key security proof, at least any proof I know of is done in a hybrid argument. So we just go from the first box to the second box, and then from the second to the third. So there is a slight inaccuracy here in the picture, but that's just a minor thing. It's just for the sake of argument. This is how it's usually done. So the first step is we start from a normal block cypher. We replace the block cypher by its ideal equivalent at the cost of the security of the block cypher. So if you assume that the AES is a secure block cypher, replace it by a random cypher at the cost of the AES security. And then we do a probabilistic argument, and it gives, say, Q over 2 to the n. OK, that's essentially every proof has this generic step. But now for our scheme, the key input to the block cypher is key plus t, the key plus a tweak. The attacker has influence on the key. And effectively, it is related key security what we need. So in this case, the attacker can make related key attacks on the block cypher. So in this case, we have the related key security of the block cypher. And it can prove that for any block cypher, how good it is, you can break the related key security in the birthday bound. So whatever block cypher you take, you can find a related key attack, an extra related key attack, in about 2 to the n over 2 queries. And this means that if we use this generic step, you can never prove optimal security of this scheme. It's even worse, you can only prove birthday bound security. And this is weird if you look at it, because the attack here, this attack on the related key security of the block cypher, cannot be used to break this entire scheme. Because this attack only focuses on this isolated block cypher here, essentially. And in our case, it is masked. And this mask really frustrates the attack. So it looks like this generic step seems unnecessarily loose. So what we essentially have, we have two extremes. The bounds get a bit more complicated. But essentially, what we say is this is the conjectured bound for cascaded LW. And this is what we call the tweakable block cypher security of this mode, against any attacker that makes Q evaluations and has T time or can make T offline evaluations. And the typical bound we see in a security proof then is like the block cypher security, which in this case is against an attacker with sigma Q queries and about T time. Plus this probabilistic argument, which is non-optimal. Actually, this is the conjectured bound. It's not even proven yet. But it is non-optimal. This one, if E is a very good cypher, then it's fair to assume that this is of the order T over 2 to the n. So it's kind of optimal. So the first term, the block cypher step is optimal, but the probabilistic step is not optimal. On the other hand, for men, too, it's the other way around. In this case, the probabilistic argument is optimal. But the block cypher security is the related key security, and it's only birthday bound. So that one is not optimal. And what we want is we want to have security. And it looks like this generic step is unavoidable. We want is that both terms are optimal. And if you look at the picture, we want to sit. Well, these are the two extremes. You want to be somewhere in the middle. So we want to look at, can we design a block cypher? And where tweak re-keying, so changing the key using the tweak, is allowed, but only in a limited way. So here, the attacker has full freedom. And in this case, the attacker has no freedom. So essentially, it looks like we should go somewhere in between. So the goal now is to design, essentially, a tweakable block cypher, T e tilde, where we have the same inputs, key input, tweak input, message goes to the cypher text. Internally, it uses a block cypher, where the key input to the block cypher is a function of the key and the tweak, and it may change. So there is some tweak influence to the key, but it's limited. Essentially, suppose we have left that different instances of the e. So essentially, left that different keys that can go to the block cypher. And then we expect to get a bound, hope to get a bound, essentially, of this form. So the tweakable block cypher security is upper bounded by the related key security of this underlying block cypher, which will probably be, at most, left at t over 2 to the n, where left as the number of different instances. In the paper, there is actually a proof that this is the bound that could be achieved, then. If e is very good, you can do the analysis. So if left as constant, if you have only a very limited amount of different instances, then this one is fairly optimal. And then you hope to get an optimally secure probability term. So this is quite a fake. So left at different e instances. Let me give you an example, and this is a very silly example. So this is a tweakable block cypher. We have a block cypher. We have the message. It gets encrypted through the block cypher to get cypher text. And we have the secret key everywhere. And we have a tweak. And the key input to the block cypher is, in this case, the key plus the first bit, key plus the second bit, et cetera, of the tweak. So this is a tweakable block cypher. If you change the tweak, you get a different permutation. One expects to get a bound of this form. So this is the bound I copied from the previous slide. How many block cypher instances do we have? We have two different instances. Namely, the key is secret and fixed. And in this case, we have the key or the key with the last bit flipped. So we have two different instances of the block cypher. And essentially, one can then show that if e is a very good block cypher, like AES, and this would be around lambda times c over 2 to the n. Lambda is 2, so 2 times t over 2 to the n. I think it's quite optimal. So 2 is almost 1, so this is quite optimal. Unfortunately, suppose we have replaced the block cypher by a random permutation. The scheme is, of course, completely insecure. I mean, this is a very naive example. I mean, if the attacker makes two queries with the same message, with the tweak only changed at the last bit, and then you can make two forward queries and then two inferences. You can play around them with forward queries. You can break it. But essentially, I tried to get the message here that if you have only a limited amount of different key inputs, you can have some more flexibility, and hopefully, you can design a scheme. But this brings me to my negative result, namely that it's not possible. So that you can never get any scheme, whatever you do. Any scheme that's optimally secure. And how we do this is, essentially, we look at the generalized scheme. So this looks very technical. It is also very technical. But this essentially covers fairly any tweakable block cipher that is based on row calls and row plus sigma block cipher calls. So we have row block cipher calls to do some pre-processing. These are independent of the message, row calls. And then we have sigma calls, essentially, to transform the message to get the ciphertext. So row plus sigma for any row and sigma. And there are some mixing functions, like ai pre, bi pre, ai's and bi's. They need to satisfy certain conditions. I mean, the ai's need to be invertible here, because you want to be able to invert the ciphertext. We also require the mixing functions bi to be uniform in a certain way. So there are some conditions, but they cover fairly any tweakable block cipher design. And I think it's quite a strange result to a certain extent. Essentially, we prove that if we use this generic reduction, so if we use this generic standard 2 ideal reduction that everyone uses apparently, then achieving optimal security in the standard model for a scheme that does tweak receding is at least as hard as achieving it for a scheme that does not tweak receding. So stated differently, assuming that this reduction is necessary, assuming that this bound on cascaded LLW is the best we can get, so it is 2 to the sigma n divided by sigma plus 1, that this is the best we can get without receding, then it's impossible to get optimal security with receding. So it's a conditional result. I assume that the proof technique is necessary. I assume that cascaded LLW only achieves suboptimal security, then you cannot get optimal security. And the proof is very technical. It's a probabilistic argument. But intuitively, it sounds quite easy. And essentially, intuitively, it corresponds to the idea that the bound always consists of two terms. So the block cipher security term and a probability term. That either of those two is too high in whatever approach you take, in whatever scheme you take. More generally, consider any possible tweakable block cipher scheme of this form, so any possible scheme of this form. And now we put some labda. Labda is essentially a threshold on the number of block cipher instances that occurs in the scheme. So if labda is high, this means that there are many different key inputs possible to the block ciphers. If labda is low, this means that there are only a few different key instances to the block cipher. Now what we prove essentially is that if this labda is too high, there are many different key inputs to the block cipher. And this block cipher security term, this at the related key security term, dominates the bound. And you can never get optimal security. On the other hand, if labda is too low, then this means that there is a large set of tweaks for which there is no tweak rekeying. So if labda is very low, there is only very few different blocks cipher instances. And you can identify a very large set of tweaks for which you don't have tweak rekeying. And this large set is large enough actually to perform an attack. So essentially to consider this specific scheme for the specific set of tweaks for which there is no rekeying. But that scheme only achieves suboptimal security. So you cannot get optimal security. And essentially it turns out that even the best trade-off is not optimal. So whatever tweak rekeying scheme you take, it gives a potentially different value of labda. And whatever labda it gives, you cannot get optimal security. I would like to stress again, I do not claim that optimal security is impossible. However, I claim that if we use this proof technique we are aware of, then it is at least as hard as achieving optimal security using, for instance, cascaded LRW, which looks impossible. In general, it raises the question, what does a security proof essentially mean? I mean, we have different models. What does a security proof in a model mean? The simple answer is it means nothing. Because I mean, it's just a model. You have a different assumption on a scheme. I mean, if we assume the block cipher to be ideal, you can prove it to be most secure. But of course, you have an ideality assumption. But that's also the case for a standard model proof. If you assume that AES is an SPRP, then you can prove security. But you still assume that AES is an SPRP. And as far as I know, no one knows what's the SPRP security of AES. Of course, it's a different assumption. Ideally, we would like to have a weaker assumption, like the standard model assumption. But it looks like for some schemes, the ideal cipher model bound could be closer to what's the actual security than the standard model bound. I mentioned this LW2 conjecture. I think it's a very interesting conjecture. And the final problem is this standard production, this generic reduction of replacing any cipher by its ideal equivalent. Can we do better? There is a simple way of doing it better. Namely, instead of just isolating the block cipher with the key input, just isolating the block cipher with key input and the masking. So instead of looking at SPRP security, looking at something like masked SPRP security, which is, of course, also a standard model assumption. But then the reduction is trivial, because you get the exact same scheme. Another approach is the thing what's done, for instance, last year at Asia Crip by Shrympton and Teresim, and they looked at a different approach where they kind of weakened the ideal cipher model. But ultimately, it's still an ideal model. Now, what we would like to go is to a standard model proof. That concludes my presentation, so I would like to thank you for your attention.