 Thank you, Michel, for the introduction. So this talk is about constructing trickable block ciphers. So first, let me give you some background on trickable block ciphers. So a classical block cipher takes as input a key k and a plain text x, and it computes a cipher text y. A trickable block cipher will take an additional input called the tweak t, which is here to bring variability to the block cipher a bit in the same way as an IV brings variability to an encryption mode, for example. And as an IV, the tweak t in the security model for a trickable block cipher is assumed to be public or even controlled by the adversary. And so from a security point of view, each tweak should give an independent permutation. So this is a very useful primitive. For example, if you try to design an authenticated encryption mode, it's much easier to start from a trickable block cipher than from a classical block cipher, for example. And it's also very useful for disk encryption. Unfortunately, there are very few natively trickable block ciphers. So there are some early examples. So hasty pudding cipher or mercy. There's three fish, the block cipher, which is underlying the hash function, skyn. And from the CISAR competition, we have seen some proposals like kiasu, deoxys, gelatin, scream and ice cream, and min alpha. But that's roughly all there is. So instead, cryptographers have tried to design generic trickable block cipher constructions, which mean a generic way to turn any conventional block cipher into a trickable block cipher in a black box fashion. And so the main construction of this type is called the LRW construction, which has been proposed by Liskoff, Rivas, and Wagner. And so you start from a classical block cipher, and you just do pre and post whitening, trick-dependent whitening, okay? So you simply hash your trick with XOR universal hash function, and you mask your input and your output with this, okay? So a classical example of XOR universal hash function is simply field multiplication, and this is the example that I will use in the rest of the talk. And it has been proved by Liskoff and Rivas and Wagner that this is secure up to two to the N over two queries where any block size of your block cipher, so this is the so-called birthday bound. And this is, so there are other generic constructions, but this is the most practical one, okay? Actually, there is a related construction called XEX by Roguere, which uses the block cipher instead of an independent XOR universal hash function. It's a bit more complicated than that, but it doesn't matter. And it's used, for example, in the XTS disk encryption mode. Okay, but the problem is that it's only secure up to the birthday bound. So if you have a 128 block cipher, it might be a bit low. So if you want to get beyond the birthday bound, if you want to obtain beyond the birthday bound security, what you can do is to chain this construction with independent keys, okay? And so the total key lengths increase linearly with the number of rounds, but it has been proved by, so this has been proposed for the first time by Landecker, Schrington, and Terashima, and they have proved that this is secure up to two to z to n over three queries for two rounds. And if you increase the number of rounds, that's been proved that it is secure up to the n over at least two queries, which asymptotically goes to two to the n queries. And the security proof only assumed that E is a pseudo random permutation. There is no, doesn't require to assume that this is an ideal cipher also. Okay, so what's our contribution in this work? So our goal was to provide some provable security guidelines to design trickable boxifers from scratch rather than from an existing conventional boxifers. So since we want provable security, we cannot start from nothing. So when I say from scratch, it means from some lower level primitive. And there has been some previous work from, for example, there are two papers that have shown how to construct a trickable boxifers from a pseudo random function using five style schemes. And what we do in this paper is that we focus on the other class of block ciphers, which are SPN substitution permutation network ciphers, or more generally key alternating ciphers. So what is a key alternating cipher? It's a very simple class of block cipher where to encrypt your plaintext, you first go around key, then you apply some public permutation P1, then you go another run key, you apply another public permutation, et cetera, et cetera. And the run keys are derived in some fashion from the master key. So for example, this is how AES is designed and so on. Okay, and if you want to do security proofs for this kind of constructions, so sorry. So this is a classical key alternating cipher, okay? And if you want to get a trickable box cipher, a simple idea is to derive your run keys, not only from the master key, but also from your trick, okay? So this is the most natural idea you can have to trick a key alternating cipher. And if you want to do security proofs for such a construction, you can do, you can use analysis in the random permutation model. And so this is something that has been done for the first time by Ivan and Mansour for the so-called Ivan Mansour cipher, which is a very, so it's just a key alternating cipher with one round, okay? And so for this reason, I recall this type of construction, trickable, even Mansour constructions. So one word about the random permutation model, what does that mean to analyze such a construction in the random permutation model? Simply means that the adversary, so he will have black box access to the construction as always in a security experiment involving a block cipher. But it will also have black box access to the internal permutations, and there will be modeled as public random permutational records, okay? So the adversary can only make black box queries to the internal permutation of your constructions. So in fact, we are only giving security proofs against generic attacks, where generic attacks mean that these are attacks that don't use any specific details about the internal permutations, okay? And so we measure the complexity of the adversary by the number of construction queries it can make to the construction, and by the number QC, and by the number QP of queries that it can make to each internal permutation, okay? So you can see QC at the number of data, it's a courier's, and the number of queries to each internal permutation, in some fashion it represents the time of your, of the adversary. But otherwise, the adversary is assumed to be computationally unbounded. So we are doing, in fact, an information theoretic proof of security. So it's a bit like using the random oracle model in public key cryptography. So once you instantiate your public permutations, you only get heuristic security, okay? But if they are sufficiently complicated, you can hope that your construction is secure up to the bound you have proven in the random permutation model. Okay, so there has been one previous result about such a construction, which is given here. So this construction here, where you absorb the key and the trick between each permutation, has been proved secure up to the birthday bound for three runs, by two recent papers, one by Kogliatti and myself, and the other one by Fashim and Proctor. And for two runs, this is not secure. So three runs is a minimum number of runs you need so that this construction is a secure two cable block cipher. But in fact, if you increase the number of runs, you will not increase security. Why? Because this construction here can be written like a conventional block cipher with a key which is equal to Kx or t. And in fact, any two cable block cipher which can be written like this, can be attacked with a birthday attack, very simple birthday attack. So no matter how many runs you do with this construction, you are stuck at birthday bound security. So the question we want to solve is, how can we obtain a construction with provable security beyond the birthday bound? And so the natural idea here is, we have the LRW construction that I described previously and we know that this construction is provably secure beyond the birthday bound if you increase the number of runs. And on the other hand, we have the conventional even more so cipher and we know that if we increase the number of runs, it also has provable security beyond the birthday bound. So the natural idea is to combine these two constructions. So what do we get if we do this? So we go back to the LRW construction with one run here. So it's simply the block cipher with a trick-dependent masking here before and after. And now we will instantiate the block cipher here with the one run even more so construction, which is depicted here, okay? So P is a public permutation and you simply absorb your key K prime before and after the public permutation, okay? And so if we instantiate E with this one run even more so construction, we get a trickable block cipher, which is constructed from one single public permutation, okay? And we absorb before and after two quantities which depend on the key K, K prime and on your trick T. And it's quite simple to prove that this construction here is secure in the random permutation model up to the birthday bound, okay? The bound is given here depending on the number of construction and permutation queries. And actually it's also simple to see that if you forbid the zero trick, then the key K prime here is not needed because key times, K times T is already uniformly random if your trick is non-zero, okay? So what we get is this construction here and this is more or less the simplest trickable block cipher construction you can get from one public permutation, okay? And we will simply call this the trickable even more so construction, one run. So the natural idea to get beyond the birthday bound is simply to chain this construction with independent keys, okay? And the main result of this paper is that if you chain two independent, trickable even more so constructions with two independent keys K1 and K2, then you get security beyond the birthday bound so more specifically up to the two N over three queries, okay? The exact bound is given by this formula here. So I will try to just give the main ideas of the proof for two runs and then I will explain, we also have results for longer cascades, okay? But the result is not tight and I will just explain this after but first I will focus on the proof for two runs. So how do we formalize the security experiment? So it's very simple. So we simply have a distinguisher which has access either to the construction with a random key or to a random trickable permutation, okay? So a random trickable permutation, it's simply a random permutation for each trick, okay? So for each trick it implements an independent random permutation, okay? And so since we are working in the random permutation model, the distinguisher also has access to the internal permutation, okay? And the goal of the distinguisher is to distinguish the real world here from the ideal world with a random trickable permutation, okay? And so to get the security bound, we use what is called the hash coefficients technique by Pataran and so the main idea is to consider the transcript of all queries of the distinguisher to the construction and to the permutations and from this we will define so-called bad transcripts and we show that the probability to get a bad transcript is small in the ideal world and then the other transcript will be called good and we will have to show that they are almost as likely in the real and in the ideal world. So this is the recipe for the hash coefficients technique. So first what will be bad transcripts for this construction? So we will need to avoid two fold collisions. So for example, if the distinguisher makes a query to P1, U1, V1 and a query to P2, U2, V2 and if the construction, a construction queries collisions with these queries here and these queries here, this will count as a bad event, okay? Why? Because if this happens, then the answer of the construction is not random anymore, okay? Because the distinguisher knows the values here of P1 and P2 and you can upper bound the probability very easily of these bad events. Another event would be if one construction query is here and another one T prime X prime collision at P1 and P2. And again, if this happens, the answer of the construction for the second query will not be random anymore, okay? And if you do this cautiously, you will end up with 10 bad collision cases, okay? And you can upper bound the probability for each of these cases. So I don't have time to get into the details but I guess you'll see the idea. So in fact, this is the easy part of the proof because then you have to handle good transcripts and so you have to show that, so you have to show that the answers of the construction for good transcripts are distributed almost like with a random two-cable permutation, okay? And the main idea here is that you need to show that for each query, there will be a fresh value of P1 or P2 which will randomize the output. So for example, for one query, for one construction query, it could collide with permutation query made by the adversary to P1 but because of the definition of good transcripts, it cannot collide with a permutation query at P2. So P2 will in some sense randomize the output, okay? And so it's kind of a case and a tedious case analysis but well, that's the hard part. And once you've done all of this, you just apply the hash encryption mainly mind and you get your security bound which shows that it's secure up to the two N over three queries. So as I said before, we also have results for longer case case. So what we show is that if you have error runs where error is even, then the construction is secure up to the error N over R plus two queries, okay? So this is not as tight as for two runs. Actually, we think we conjecture that the real security bond is that it's secure up to two to the error N over R plus one runs. And we think that we get the worst bound just because we cannot apply the same technique as we just don't know how to apply the hash coefficients technique. It becomes a bit too complicated. So instead, we use what is called the coupling technique which has been applied for other constructions before. And so this is kind, this is good for handling non-adaptive attackers but as soon as you have to adaptive attackers, this doesn't give you tight results. So this is what we have for longer case case now. But at least it showed that if you increase the number of funds asymptotically, you get to the optimal bound of two to the N queries. Okay, so it's time to conclude. So what we did with this work was to, in some sense, to analyze the public permutation variant of the LRW construction. And in particular, we proved tight to the two N over three security for two runs. So in some sense, we get some similar security level at the LRW construction, but we use an idealized model that only gives heuristic security, okay? For LRW, you don't need any idealized model. It's only used the assumption that the underlying block cipher is a good PRP. We have a number of open problems. So first, as I said, we think that our bond for LRWs, for LRW greater than three is not tight. So the first open problem would be to prove tight security for anyone, any number of funds. Another problem is to remove the assumption that the keys here are independent. Can we maybe derive key one, key two, key a from some master key and still have the same probable security level? It's a natural question. And another open problem is, can we avoid this nonlinear mixing here of the key and the tweak and still get beyond burst day security? The only construction we have right now that don't make this nonlinear mixing is the construction I gave right at the beginning when you absorb key and you absorb key, okay? So you don't multiply key and key, but this is only secure up to the burst day bound. And what is interesting is that it's kind of related with something that has been proposed quite recently, which is called the two key framework by, that has been proposed by Jean, Nikolich and Perin in the context of their CSAR proposals. And so the two key framework is a very broad framework to design two cable key alternating ciphers. And in particular, they have what they call the superposition two key constructions, which are morally this construction here, where the key and the tweak are scheduled independently, okay? And they are not mixed, they are not multiplied or anything, they are just scheduled independently and absorbed into the state, okay? And I think it would be very interesting to find sufficient conditions on F and G so that you get provable beyond burst day security in the random permutation model. It would give at least some guidelines about how to design a simpler two cable block ciphers in a key alternating fashion. And just note that if you take the same function for F and G and if this is linear, this cannot work since it will have the form of a block cipher with kx or t as a key, okay? So if you take F and G the same, this cannot be secured beyond the burst day bound. So you really need to schedule your key and your tweak in two different fashion to get beyond the burst day bound security. So I think it's quite interesting and for now we don't see how to, which condition would be good enough to get beyond the burst day bound security. Okay, thanks for listening. You sure I have questions?