 Thank you, Bat, for the introduction. So this talk is about constructing authenticated encryption schemes from two cable block cycles. So let me first give you the context of this talk, of this work. So the starting point is the ongoing CISA competition for authenticated encryption. And more precisely, the three candidates, Dioxys, Joltik, and Kessu, by the same team of designers, Jeremy Jean, Yves Saint-Nicolich, and Thomas Perrin. And each of these candidates is based on a dedicated three cable block cipher and two specific modes of operation. So the first one for the non-respecting setting, which means if you're not afraid that non-s will be repeated, you can use this mode, which was chosen as OCB. Well, the generic variant of OCB, which is called TitaCB. And for the non-smissive setting, they used a mode which is called COPA, which has been designed by André Vallard. And there were some problems with COPA. First, it provides only what is called online non-smissive resistance. So I will not enter into the details of what this is, but this is not the strongest non-smissive resistance that you can hope. And in particular, this security definition is a bit controversial. So there has been some problems also with some technique, which is called fix-LS, which COPA used to be based on, so which has been broken by non-D. So it has been fixed, but still there was this problem of online non-smissive resistance. And the designers wanted to find a new mode. So what were the requirements for the mode? So first it had to be based on a three cable block cipher. It has to offer some full, what I call full, is the strongest possible non-smissive resistance security notion possible, at least up to the birthday bound. And if possible, to get beyond birthday bound security in the non-respecting setting. So the rationale behind that is that if you use your mode without repeating non-sis, you should be able to use this property to get beyond birthday resistance, beyond birthday bound resistance. And in case something goes wrong with non-sis, you still retain some weaker bound, but still a good bound to the birthday bound. And if you look at existing modes for turning a two cable block cipher into an authenticated encryption scheme, none of these modes satisfy these two requirements at the same time. So we have TTA-CB, which is perfectly secure when non-sis are not repeated, but which is completely insecure, and the progress is completely broken as soon as a single nonce is reused once. So there was COPPA, but as I said, it only provides online non-smissive resistance, which is not the strongest form you can hope for. So there is the candidate AEZ, which you can recast as turning a two cable block cipher into something even stronger than a non-smissive resistance scheme. Namely, it offers what is called robustness, but only up to the birthday bound, even when the nonce does not repeat. And finally, there is a mode called protected IV, PIV. So the problem with this mode, so it achieved these two properties at the same time, but the problem is that it requires a very long tweak length, which was not possible with deoxys and Joltik. So the two cable block ciphers, deoxys and Joltik, they have short tweaks of the same size as the block size. And so this mode was not adequate for our goal. So what we came with is a new mode, which is called STT for synthetic counterintric, and this is a mode that I will describe now. So the outline will be as follows. So we use generic composition. So first I will introduce the new generic composition method that we use, which is called NSID, and which is very close to SID. And then I will describe the two parts of the mode, the authentication part and the encryption part. So first some quick definitions about two cable block ciphers and authenticated encryption. So the building block from which we are starting is a two cable block cipher, so which is quite similar to a standard block cipher. So it takes a plain text X and a key K, but it takes also an additional input, which is called a tweak, and which is here to bring viability to the block cipher. And the tweak is typically assumed public or even controlled by the adversary. And from a security point of view, each tweak should give kind of an independent permutation. So you can turn, there are generic ways to turn a block cipher into a two cable block cipher, but usually the security is only up to the birthday bound, for example, the XEX construction. And there are very few block ciphers which have been designed natively to be tweakable. So there has been some early designs such as hasty putting cipher, mercy, three fish, which is the underling, the hash function skin. And since the CISAR competition, there have been more and more designs of this kind of primitive. So in particular, in case with the XEX and JALTIC, but also in Scream and Ice Scream and in Min Alpha. So this is our building block. And what we want to construct is what is called a nonce-based authenticated encryption scheme. And so what is this scheme? So it's a scheme which takes a key, a nonce n, some associated data which will only be authenticated, not encrypted, and a message a, which will be encrypted, and it returns a cipher tax c, okay? And the encryption algorithm takes the nonce, the associated data and the cipher, and returns either a message or some symbol which indicates that the cipher is invalid. And so typically the nonce should not be repeated, but sometimes this is something that you cannot assume. So just one slide about how do you define the security of such a scheme? So you consider an adversary which has access to two oracles, an encryption oracle and a decryption oracle. And this adversary must distinguish two worlds, the world where it has access to the real oracles and the world where it has access to, so the encryption oracle is replaced by something which returns purely random bits of the adequate length and the decryption oracle is replaced by something which always rejects, okay? And so we'll say that the adversary is nonce-respecting if it never repeats a nonce here in encryption queries. So what we want to achieve typically in such schemes is what we call nonce misuse resistance which informally means that even if a nonce is repeated in encryption queries, first it should not harm authenticity and it should hurt confidentiality only in so far as a repetition of triplets NAM are detectable. So this is unavoidable but this is the only thing that the only bad thing that we want to happen. So in fact, this is quite close to what's called deterministic authenticated encryption. And notice that such schemes cannot be online, right? Because if you think about it, it's easy to see that each side of the text must depend on every input bit. So you cannot do this, you cannot achieve this security notion with an online scheme. So now I will explain the generic composition method that we use in this new mode, which is called NSID. So generic composition is just a way of taking a Mac or a PRF and an encryption scheme and to combine them to obtain nonce-based authenticated encryption schemes. So you can encrypt NMAC, encrypt NMAC and so on and so forth. And before I go further, it's important to have in mind that the syntax of the encryption scheme is very important. So in the wild, you have mainly two types of encryption schemes. You have what is called IV-based encryption schemes where the encryption function randomly chooses a random IV for each encryption. For example, in the CBC encryption. And you have what is called nonce-based encryption where the encryption scheme takes a nonce which in the security definition is chosen by the adversary, but should be non-repeating. So for example, you have what you could call nonce-based control mode, which is used for example in GCN. And this is very important to have this in mind when you consider a generic composition. So our starting point was a mode which is called SIV, which has been proposed by Ogaway and Frempton, and which allows to build a nonce-missues-resistant scheme. So how does it work? So you have a PRF and an encryption scheme and you first give your nonce, your associated data in your message to your pseudo-random function and this gives you a tag which will be used for authenticity. And this tag here will be converted. Well, you can forget about conversion. You can just usually take the tag and use it at the IV for an IV-based encryption scheme, okay? And you encrypt your message with your tag as IV, okay? And this gives you your sacred text. So this SIV construction provides you non-missues resistance up to the birthday bound if you instantiate your pseudo-random function and your encryption scheme with birthday bound secure constructions, okay? So it's a good starting point. But what if you want to add beyond birthday bound security in the nonce-respitting case? Well, actually for the PRF, it's quite easy in fact. I will explain in a few minutes how. But the main difficulty is how to obtain an encryption scheme which is beyond birthday bound secure when nonces don't repeat. And actually, if you think of it, what is hard is that the encryption scheme doesn't take the nonce as input. So our only modification to SIV is to reuse the nonce in the encryption scheme, right? And we will use, so we will be able to leverage on the non-repeating property of the nonce to build an encryption scheme. So if you look now closer at the encryption scheme now, it's a bit weird. Why? Because it takes both a nonce and a random IV, right? Which is quite unusual. And actually, I don't know any encryption scheme which is built like this for taking a nonce and a random IV. But actually, it's quite easy to come with a security definition for such a scheme, right? Cypher text must be indistinguishable from random, assuming nonce do not repeat and assuming the IVs are random, right? And actually, when nonces can be repeated, it's you recover the standard notion of IV-based encryption, more or less. And so what is nice with this construction is that you can prove that all your components are beyond the secure when nonces do not repeat, then your authenticated encryption scheme is beyond the secure when nonces do not repeat. And when nonces do repeat, you get the security of your two components when nonces do repeat, okay? So what we have to do now from this generic composition method is to build our two components here. So first, a PRF, which is BB secure when nonces do not repeat and which is secure up to the bus deban when nonces do repeat and an encryption scheme with the same properties, right? So for the authentication part, we designed something that we called encrypted parallel Vekman Carter. So I will not spend too much time on this design because this will be the main topic of my, this kind of design will be the main topic of the second talk I will give in this session. So just to give you a very small idea of what is going on. In fact, first we designed a PRF of the nonce by exerting two independent permutations of the nonce. Please give us a beyond the secure PRF. Then we XOR it with some kind of hash of the message, some kind of, so this hash is very similar to what is done in the PMAG scheme, so call it PHAG of the associated data and the message. So roughly this part here gives you a kind of Vekman Carter MAC, right? So this is secure beyond the bus deban when nonces do not repeat and to get nonce misuse resistance, we add an extra encryption layer at the end, okay? So I'm not entering into details and we'll give more details later. And so you can prove that this design here is secure beyond the bus deban when nonces do not repeat and up to the bus deban when nonces do repeat. Okay, so this was not so much innovative. In fact, we just gathered known techniques and known schemes. What is more interesting is how to design the encryption part. So this is what I will explain now. So we explored many design possibilities and we found out that what was more convenient was to start from a counter like mode. So a counter like mode just means that we do something with our two cable box cipher, which gives us a mask and we just XOR this mask with the message box to give us the cycle text, okay? So now the question is how do we, what do we give as inputs to our three cable box cipher? Okay, we have a nonce, we have an IV. This IV will be the starting value for the counters. So traditionally when you do a counter mode encryption, you give the counters with the initial value IV as input to the message block of your block cipher, right? So what we could do is, so we still have the tweak input of the block cipher. What we could do is put the nonce in the tweak input, right? The problem is if we do that, we don't have beyond both the bound security even when nonces do not repeat, right? Because the adversary can simply do one query with one specific nonce of length two to the another two message blocks. And here it can just look for collision in the XOR of the message blocks and the cipher blocks, okay? And this, since the same tweaks, the same tweak enters always the two cable box cipher, we always have the same permutation. And so this will be distinguishable from random because we won't see any collision in the XOR of messages and cipher texts, okay? So this does not work. And the simple idea to make it work is just to switch the inputs to that. This means to encrypt the nonce and to put the counters in the tweak input of the two cable box cipher, okay? And this is why we call it counterintrich encryption mode, okay? And the key observation here is that when you do counter mode encryption, you want the mapping from the counters to the masks to be a function, not a permutation because being a permutation is exactly the property that allows you to distinguish your cipher texts from random, okay? And if we put the counters in the tweak input, well, the simple observation is that for an ideal two cable box cipher, the mapping from the tweak to the cipher text is a function, it has no reason to be a permutation, right? So this is our design for the encryption part. So let me just give you a few ideas of how you prove the security of this construction first in the, so yeah, first the bound. So it's a bit complicated, but so n here is the block lengths of the two cable box cipher, t the tweak lengths, sigma is the total number of blocks in encryption queries, and m is the maximum number of nonce repetitions. So m equals one in the nonce respecting setting, okay? So what we can see first is that when nonce do not repeat this term here vanishes, and we are left with a term which show that it is secure up to the minimum of two to the n blocks and two to the n plus t blocks, two to the n plus t over two blocks. So assuming the tweak lengths is big enough, this is beyond the secure. And another interesting property is that security degrades gracefully with the maximum number of nonce repetitions, which means that if you only have two or three nonce repetitions, this term here, it will remain small, okay? You really have to repeat nonce, a lot of time to get a large term here, okay? Which I think it's an interesting property of this scheme. So how do you prove this bound? So first assume that the adversary never repeat nonces in encryption queries, and we want to show that the cycle text here are indistinguishable from random. So each IV, so each initial value here will determine the seconds of tweaks which are used in the TBC. And an important parameter will be for each tweak, what I call the load of the tweak, which is the number of time the tweak has been used through all encryption queries, okay? And actually it's quite easy to see that if you think about what a tricker box hyper is, actually it's easy to see that it is really equivalent to trying to distinguish each permutation associated to each tweak from a function. So actually you can prove that the advantage of the adversary is upper bound in by the sum of all the PRF, PRP advantages for each tweak with a number of queries which is equal to the number of times to what I call the load of the tweak, which is the number of times the tweak has been used in the encryption queries, okay? So now we have to just upper bound this the maximum value of the load of the tweak. And actually it's easy to see that it is a simple balls into bins problem. You can think of each tweak value as a bin and you can think of the non-cs as the balls. And for each query, the random IV, which is chosen by the encryption oracle, will determine in which bin I start and then I put my balls in the consecutive bins according to the counters, okay? And so for each nonce, I will choose a random starting bin and put my balls into it, okay? And so this is not exactly a classical balls into this problem because you put, usually you would put your balls independently in the bins, but it's easy to see that putting the balls in consecutive bins cannot help, in fact, in increasing the maximum load of the bins. So actually standard bounds on this problem apply and this gives us the final bound for the counter for the secretive. I will skip what happens when non-cs can be reused but it's quite easy to see that you will have a problem only when the same nonce is reused twice for the same tweak and it's easy to see that this gives you this parameter here in the security bound which banishes when non-cs cannot repeat. So to conclude, so I described an authentication mode, an encryption mode. When you combine these two modes using the NSID composition method, you get what we call the SCT mode. So synthetic counter and tweak. So synthetic here records from the, comes from the SIV mode, okay, because the initial counter is computed as a PRF of the nonce, the message and the associated data. And so as I explained, this mode is beyond birthday secure when non-cs do not repeat and it retains birthday bound security in the nonce misuse setting. So actually it's quite efficient so it's not online, but you cannot achieve nonce misuse resistant online. It's easy to parallelize and it does not need the decryption direction so it's quite good. So the final caveat is that about instantiating the two cable box IFR. If you want to get beyond birthday security when non-cs do not repeat, you really need to instantiate your two cable box IFR which is something which is beyond birthday secure which means that you cannot use, for example, the standard XEX generic construction, okay? You really need to use ideally some dedicated two cable box IFR without any known weakness. So for example, with deoxys and jolted kits, okay? Because these two cable box IFRs have not been attacked now, but keep in mind that you must be careful when instantiating the two cable box IFR in this mode, okay? So that's it from me. Thanks very much. Thank you very much.