 So, what is OTR? OTR is a system of submission by Katsuhiko Minamatsu that was presented based on trivial block ciphers. And this can be seen as an inverse free version, because it only needs a forward way of block cipher, not the inverse. It can be based only on the PRF. And to do this, Minamatsu used this nice two rounds of FaceTel. And in the paper, this construct... So really quickly, what is a trickle block cipher? Well, this input will add variability. More formally, for each tweak we'll define independent pseudorum or random permutation. So you have this formal definition here. I will not go over it. And it's really useful to define... So really quickly we'll define OTR, so this is the main message. You separate blocks by two, and then each pair of blocks goes through this round. It's defined with a tweak, so you have different... And for the last blocks, well, it's a number of... And then to compute the tag, you have this tag from here that is taken over in blocks, and you encrypt it. So in the original paper, Minamatsu showed that if Tali is a tweakable PRP, then OTR exists in front of the door, and also unfortunately. And this is not something we're going to study here because we're not attacking this block. What we are interested in is the way the tweakable works. So really quickly, before going on, I want you to remind that we're, as usual, working on a binary field represented as a polynomial field, or F2, cushioned by... And P is often like... So in Minamatsu and as in other... And considered the XOR encrypt construction that was... So the idea is to encrypt the message with XOR with a mask. And then this mask has to be computed, often using the nonce and other... So in another way, where delta is the encryption of the nonce, so essentially you shift delta by I, and then you shift and XOR delta by K. And the reason why you consider something like this is that it's really easy to incrementally compute the delta IJs, like it's really easy to compute the delta I plus 1J from the data. In Minamatsu or in the version 1 and 2 of OTR, also for efficiency reasons, the masking scheme has been modified. Now you have something that looks like this for masks that are used in the encryption part, so in the festival construction. So you shift and maybe you add... B is equal to 0 or 1, so you first shift delta and then you might have to add delta. And this more complicated mask here is used for... And here you can see that again you can incrementally compute the delta as 1 from each other, and that's what makes OTR. So you can see these are elements that are generated and here are the elements generated. The problem is that this is not true in general. The voice is not true in general. Well, again we should take a look back at what's done in our OCB. The OCB paper, Rogaway, bounds I and J so that this quantity I plus alpha J are all different where alpha is the log of X plus 1 in basis X. And well, if you know that these elements are all different, then you'll know that these polymolds here will be all per voice instinct. And this is exactly where the flow in the Minamatsu paper comes in. The point is that polymolds in this set are not necessarily distinct. And that's even worse. For some values Q, even for really small values Q, this is not true. And for example, if you consider P, which is a trinomial with only three coefficients, then you will really easily find a collision between X to the N and X to the J plus 1. When your binary field is defined like this. So you have a trivial collision for some values P, from some values of P. And the point is that this happens quite often. For more than half of the N's, less than 10,000, there is an irreversible polynomial P that will define such a field. And for efficiency reasons, efficiency reasons, sorry, this is the polynomial you're going to choose to define your field. So in many cases, this collision will happen. But you might ask, well, okay, what about like standard block sizes, N equals 64, N equals 128? The point is that when 8 divides N, then you will not be able to find a trinomial defining the field. You have at best a pentarnomial, so something with five non-zero coefficients. So in general, you don't have an immediate collision. The other point is that for software and hardware efficiency, we usually choose P such that the non-zero coefficients are regrouped on the least significant bytes. So you can take those two examples here for N equals 64 and N equals 128. So these are the usual polynomials we use to define all the modes and the algebra on these fields. And you'll see that all the coefficients are regrouped towards the end of flow degrees. And this is interesting because for N equals 64, you see that you will have a collision among some polynomials we define. So this is some tweak polynomial that's going to be used for the inclusion part and this is going to be used for the authentication part. Again, you have a collision here because of the definition of the polynomial and you have a collision in the tweak polynomial. So this shows you that essentially the proof for TR is float even for practical parameters. This does not really imply that there is a concrete break or a confidentiality break or an internality break. So let's study the kind of collisions we might encounter. So again, this is the set of the polynomials or the polynomials used for tweaks. We're going to have three types of collisions, either inner collision in this subset or in this subset or collision from this subset to this subset here. And we're not really considering the end, the remaining term, because this only happens because you have incomplete blocks and so on. So you have these three types of collisions and we showed in the paper that you will either break confidentiality and for durability or both depending on the type of collisions you have. We'll not go over this in the presentation. I quickly looked at the full paper but essentially the idea is to combine blocks according to those collisions so that you know what's going to get into the block ciphers and because you already know what's going to be into the block cipher you'll be able to get collisions from the block ciphers and you will be able to replay either the tag or find repetitions in your psychotext and break the CPI secure game. Something really important is that this attack can be mounted with only a single query to indignation oracle and with a single message of a size max of ij blocks, like the biggest degree of this polynomial here. And for n equals 64 you will be able to break unfamiliarity using a single 1 kilobyte message. So this completely breaks the whole encryption scheme. So we studied the n equals 64 what about n equals 128? So again usually for 1 equals 128 we choose this polynomial and again there is no trivial collision as I showed you for n equals 64. Something important to realize is that this is not true for any polynomial of degree 128. You could choose this polynomial here which is reducible and you will again have a collision of the same type that the one we had from n equals 64. So more generically can we find a collision above the tweak polynomial? Something really important to realize is that we are only interested in collisions with i and j that are less than 2 to 64 because the proof of the scheme is only holds up to the burst response and you are not really interested in what happens after this 2 to 64. And this is important because we cannot really have some algebraic way to find collisions by finding them in f2 to 64 and then lifting them to 128 because those collisions will have all degree at least 2 to 64. So our only hope is to have or to do some kind of inclusive search. This is quite easy to do because we just have to generate all the polynomials, sort them and try to match them and this is embarrassingly unbrusable so if you have a like a GPU or a big machine you can do it extremely easily. Yet you'll need a lot of memory and also a lot of time so you kind of have to make some choices in the way you're implementing things and we actually made some time memory trade-off to do this and we search... we look for any collisions where i and j are less than 2 to 45 and we didn't find any. So essentially what we have in the end is that because there is no collision among these polynomials here RTR is secure when RTR as defined in the original paper is secure for any call 128 as long as your messages are less than 2 to 45 blocks so that's long messages. So it took us quite a lot of time to get this so the question is what's going to happen after these 2 to 45 blocks can we make any conjecture about what's going to happen? So something interesting is that if tweak polynomials behave like random ones essentially we should have a collision just before the burst event but we saw that for some primitive polynomials that were using the definition of binary field like collisions happen right away so it's quite... I mean supposing that these polynomials behave randomly is might be quite often an assumption so that might not be good so something we did is that we looked at all irreversible polynomial over F2 for n equals 32 and 64 and looked for all the first collision that was happening and these are the results so here you have the logs of the degrees and you can see this is for n equals 32 so you can see that you have a few collisions happening at really low degrees and then most of the collisions happen like 2 to 13 between 2 to 13 and 2 to 17 and this is even worse for n equals 64 for n equals 64 we have like 6 polynomials that create collisions at really low degrees essentially trivial collisions and for all the other ones I mean there is absolutely no collisions between 2 to 6 and 2 to the 26 for also polynomials and most of the collisions happen just at the birthday time it's really strange because it means that we have two kind of behavior either we have collisions extremely soon or we have a collision that happens like if everything was happening or behaving randomly so that's kind of funny so we made this conjecture that there shouldn't be any collisions before 2 to 60 so we hope that OTR is secure with messages less than 2 to 60 blocks and to conclude we showed that OTR is insecure from many block sizes as defined in the original paper that it's secure for n equals 128 when the mess excellence is submitted to 2 to 45 blocks that it's probably secure almost up to the birthday balance and something really important is that the last version of OTR that was like tweaked for the last round of the CISA competition fixes the issues after our paper and I mean we now use this mass from the original or CB2 paper so there shouldn't be any more issues on that side that's it, thank you very much if you have any questions and you can find our paper on Ibrans