 Hello everyone, I'm going to present Saturna, suite of lightweight, symmetric algorithms for post-contour security. This is joint work between Anne Contour, Sébastien Duval, Gail Tendleron, Maïen Ayaplesensia, Léo Perrin, Thomas Pornin, and some guys behind the mask. So first I'm going to make an introduction and explain our design goals. Second, we're going to see the specification of the blog cipher. And finally, we'll see the modes of operation that we propose to use. All right, so we had three main design goals in mind. First of all, we want cipher with strong security arguments. So we're going to use an SPN cipher and a weight-ray strategy, just like in the AES. But we also want quantum security, which forces us to use 256-bit keys, but also blocks of the same size, and also carefully chosen modes with quantum security arguments. We also want the cipher to be efficient in hardware and software, which is why we have a bit size design, and we build a cipher, although it has a big block size, from very small components, like 4-bit asboxes and so on. So currently, in the lightweight crypto process, there are 13 second-round candidates that are based on block ciphers. And if you look at all the block ciphers that are used, Saturnine is the only one that uses 256-bit blocks. It's also the only proposal, including the cipher and the mode of operation, that claims security against quantum adversaries and to a position craze, where the adversary can basically encrypt the quantum state. So we think that Saturnine is also the most efficient transition of the AES design strategy to a bigger block size of 256-bits. But now in terms of security, because we obtain a very good balance using the weight-ray strategy here, or in terms of implementation, because it's going to be a bit slice by design. So about quantum security, first of all, we really need to use a key of 256-bits to avoid quantum exhaustive search with Clover's algorithm, which is also why AES 256 is often recommended for post-quantum security. Second, we wanted to use a block size of 256-bits to avoid also quantum attacks, especially on the modes of operation, at the quantum birthday bound, which is, in our case, 2 to the 85.3. So to understand that, using such a block size, we're going to simplify the design of most of our modes, especially of a hash function. So we're going to claim security against classical and quantum attacks. Quantum attackers can query the secret key cipher, otherwise, in superposition, as I said, they can encrypt quantum states. This is a very strong model. It's also the strongest available at its non-trivial, meaning that we can obtain security in such a model. It's also nice because it includes all intermediate definitions and possibly all use cases. For example, you think of, I don't know, implementing a white box version of Saturna. So about the name, first of all, Saturna is a famous French tech. It's a hero of the TV series Les aventures de Saturna, a series that was meant for the kids. It's made from real-life footage of animals, which are then dubbed. The main character, which is a duck, looks like the picture here, which is from Wikipedia. Personally, I find it a bit scary, but if you're not afraid of a duck that talks in French, you can still look up the episodes on the internet. We also know that ducks have been historically used as standard of lightness as reported in the movie Monty Python on the Holy Grail. Basically, a duck is lightweight because it floats, or maybe because it's made of wood, I'm not sure anymore. Also, the planet Saturn is associated to the cube in Kepler's cosmography, which is nice because Saturna's state is going to be represented as a cube. That was my transition. Let's have a look at the specification of the block cycle, and especially this cube state. The state of Saturna is represented as a cube, four by four by four nibbles of four bits, and there is an equivalent representation as 16 registers of 16 bits. The main thing to know is that the column in the cube is going to correspond to a column in the register, so one bit of each register. If you're familiar with the AES, the operations that we apply in Saturna look a bit the same. There are little differences everywhere. So we're first going to start with an S-box layer. We're going to apply an S-box Sigma 0 to nibbles of even index and an S-box Sigma 1 to nibbles of odd index. These are two different S-boxes, but they are actually the same up to a permutation of the output bits. Then we have a nibble permutation, which is going to depend on the round number. I'm going to go into the details right away. We have a linear mixed column that applies to every column in the cube, and this is an NDS mapping. We apply the inverse of this nibble permutation, and we have the subkey addition. So the nibble permutation depends on the round index, the round index which starts at 0, of course. If the round index is 1 modulo 4, then we shift rows in the slices of the cubes. The slices are here on the left. If the round index is 3 modulo 4, we shift rows in sheets of the cube, now here on the right. Shift rows, like in the AES, we are like this. If R is the 0, 2 modulo 4, we do nothing. So these shift row operations are only going to intervene every two rounds. If we look at the register representation, all of these operations have good bit slice implementations. The S box and the mixed columns are actually going to be very simple. Mixed columns are going to apply on 16 bits, on 1 bit of each register here, because this is a column in the cube, if you remember. S boxes are going to apply on 4 bits of each register, because this corresponds to a nibble. And the shift rows in slices and sheets correspond to rotations in the registers. Other rotations are different, of course, but this can still be implemented in this way. So for slices, we need to rotate inside registers, we need to rotate each packet of 4 bits, like this. And in sheets, we need to rotate each register by a multiple of 4 bits. The sub-key additions occur only at odd rounds, as I said. So every two rounds are going to absorb a key, either the master key key rotated by 20 nibbles, or the master key itself. And every two rounds, we have no key addition. There are round constants, of course, and there are going to be two 16-bit words, which are absorbed to the state, and they touch 30 nibbles in total. So one bit of one constant goes to one nibble. These round constants are generated by LFSRs, and they depend on the domain separator, which is another parameter of 4 bits, which allows to define independent variants of Saturn R to use for all modes of operation, which are going to be represented as tugs of different colors. Now let's go to the super-sbox representation of the Cypher. We're going to take this cube. The cube is nice, but two dimensions is better, so we're going to squeeze it. And the super nibbles in the super-sbox representation are going to be the columns of the cube, so there are 16 bits. Now let's have a look at four rounds of Saturn R. The first round is applying the S-box layer and mixed columns, and there is no shift rows and no key addition. Round one applies an S-box layer, and then there is shift rows, but it slices mixed columns, and shift rows slices inverse addition of the key. Then we have the S-box layer, mixed columns, S-box layer, and shift rows, and mixed columns in the sheets. So actually, this corresponds to a sequence of operations performed on this equivalent state where the nibbles correspond to columns in the cube. There is a super S-box which applies to the columns. So this is S-box, mixed column S-box. There is a linear transformation on the super columns in the cube, which means the super columns in the square, which means this slices mixed columns slices. There is a key addition, a rotated key addition. There is another super S-box, and then there is the same linear transformation as before, but on the super rows, because we are now transforming in the sheets of the cube. And then there is a key addition, which means that four rounds of Saturn R correspond to two rounds in some big AES construction. So two rounds of Saturn R are actually a single round of something that looks like an AES, operating on 16-bit nibbles, with a transposition instead of a shift rows. So it's a bit like the block safer square, and it also has a different key schedule. This is why we need to reuse 10 super rounds for standard Saturn R, because the attacks we're going to have on standard Saturn R actually look like the attacks on AES 128. For rotated key security, we're going to recommend 16 super rounds, which is a variant of Saturn R. And the best key recovery we managed to write target is 7.5 super rounds of Saturn R. So super round means two rounds, but it looks like a single round of an AES. A big AES. So most of the secret analysis of the AES that has been performed is going to be transferable to Saturn R. We also have whiter arguments that apply very nicely, and we can have, for example, we have 125 active S-boxes for 8 rounds. The 4-bit S-boxes that we just have has optimal differential linear properties. The super S-box has group properties that come from the NTS layer and also from the choice of small S-boxes. And we can have variants for differential and linear characteristics on 8-on-trace. Let's have a look at the modes of operation that we proposed. So the submission includes three modes of operation, counter cascade, Saturn R short, Saturn R hash. And we're going to use separate round constants, so separate values of the domain separator for all of these modes. So they are dictated by the quantum security proofs that we found in the literature. So encrypt and MAC is going to be a nice construction. The counter mode for encryption has approval security, the cascade MAC also. And there is a proof of indifferenceability of the Merkel-Demgaard construction in the quantum setting. Let's start with the simplest, Saturn R short. You want to encrypt a single block of less than 128 bits, or maybe of exactly 128 bits because it's only a matter of reducing the non-size. Just concatenate the nonce and the message and we encrypt. So the ciphertext and the tag are not two separate values. It's just a single value of 256 bits. And it's very efficient because it's only used to call Saturn R once. Saturn R counter cascade is our main proposal. So we combine with the encrypt and MAC construction the counter mode and a cascade MAC which looks like N MAC or H MAC. So in the counter mode, we have to concatenate the nonce and counter. We encrypt. In the cascade MAC, we use several different variants of Saturn R with different domain separators. We process the associated data, then we process the ciphertext and we produce a tag. Under an assumption that Saturn R is a quantum to the random permutation, the counter mode is indistinguishable but quantum chosen messages attacks and the cascade MAC is also unfortable. These are the security proofs from the literature. For the hash function, we propose to use a Merkle-Demgaard construction with the Mathias-Meyer-Ozeras mode. And for this, we need a cipher which is relatively secure. So we take the variant with 16 superans. Faturna. We're going to simply have a state of 256 bits which allows a hash value of 256 bits which allows a classical birthday bound at 228. We're finding classical collisions. Quantum birthday bound now is at 2 to the 85.3 but we're going to make a slightly higher security claim which is partially conjectural using the fact that quantum collision algorithms are usually memory intensive and that if you want to go to this bound to the 85.3 you need to use an algorithm that uses a lot of quantum RAM and quantum memory. So we're just making a stronger partially conjectural security claim that depends on the adversary's quantum memory which, of course, we assume to be at least 1 qubit. About performance. So the block cipher has a rather small gate count. In software, such a counter cascade performs as good as the AES but it has also a higher block size and higher and bigger analysis and bigger blocks and so on. Settler hash forms fairly well on the microcontroller benchmarks of rise-weatherlies and Settler short is also very competitive for short messages because it only requires to call Settler ones. So we have performed a preliminary study of the relatively security of Settler now but we need to know more about the 16-super-round version. We know that this has a simpler key schedule than the AES which may be exploited and we really want to know what are the best classical reduce-round attacks and quantum attacks. So not only because we use this in the Settler hash but also because in the updates we propose to use this with Settler QCB. So the QCB mode is a quantum Settler rate-one mode which is similar to TETA-CB based based on a tweakable block cipher and we propose to use for this tweakable block cipher Faturna in which you absorb the tweak with the key which needs of course to be completely rated key-seeker. So to conclude we wanted to show that post-quantum security and night-weightness are not too orthogonal constraint and that we may obtain the best of both worlds. So we chose a block cipher of 256 bits which is the only one in the lightweight process and we chose well-known modes with quantum security guarantees. And Settler now also offers a very high classical security and also has very nice whiter arguments. Now, overall Settler now, so the variant with 16-super-round is not used in the primary proposal and we would like to know more about its rated-key security for the hash function and for Settler 9 QCP. And we really want to invite people to perform third-party cryptanalysis and we're going to open a challenge soon it's going to be announced as a room session. So yeah, see you at the room session for the opening of the challenge and thank you for your attention.