 So, actually I'm going to start by talking a little bit about history instead of cryptography, to tell you where the name Geondal comes from. So, Geondal was the sword of a knight called Roland in France during the 8th century AD. And the story tells that when Roland was about to die in a battle, he did not want the sword to fall into enemies' hands. And so, first he tried to break the sword onto a rock and the sword actually broke the rock, effectively creating the bridge of Roland. You can look that up on Google if you want and you can see it in the Pyrenees in France. So, he decided to throw the sword away and he ended up in this rock in Roca Madur in France, about 300 kilometers away. So, because of all of that, Geondal actually means the one which lasts. So, I hope this is a well suited name for our crypto system. Now I'm going to start with some motivations for this work. So, in code-based cryptography in general, we have pretty good results for public encryption schemes and key exchange mechanisms. We have several security and performance trade-offs, reductions to well-known problems, things like that. But signature schemes are much more difficult to grasp. And in the rank metric in particular, we had this rank sign proposal to the first round of the NIST PQC standardization process. And it was broken because rank sign was an ashen sign signature scheme. And so, what you do is that you ask your message and you need to invert the syndrome you obtain with a trapdoor that is in the keys. And it turned out that the structure could not be hidden in the public key. So, the scheme is in the broken. And midwine, in the lattice-based cryptography, you have this Schnor-Lubasevsky framework kind of approach that has a really nice property that does not rely on this kind of hidden structure. So, this work is about adapting this framework to the rank metric, plus adding a new idea, because as I will show, if you do a straightforward adaptation to this approach, it turns out that the scheme is broken in the rank metric. So, what is the rank metric? During the talk, we are only going to consider codes with coefficient in FQ to the M. And to define the rank weights of vector x of length n, what we are going to do is that for each coordinate of x that lies in FQ to the M, we are going to unfold it in a basis of FQM over FQ. And this will give us a column vector of length n. So, by doing that for each coordinate, we obtain a matrix of size m times n over FQ. And we will call the rank weight of x the rank of its associated matrix, and the distance between x and y, the rank of the difference of the respective associated matrices. Another important notion is the notion of support of a word. So, we still have our vector x of length n. And we will call the support of a word denoted support of x, or capital E in this slide, the FQ subspace of FQM generated by the coordinates of x. And by definition, the dimension of support of a word is exactly the rank weight of this word. We are going to consider FQM linear codes. So, these are more well suited for cryptography than FQ linear codes in the rank metric. The definition is pretty similar to the one in the Amic metric, except that the scalars lie in FQM instead of F2, usually. So, an FQM linear code is an FQM subspace of FQM to the n of dimension k. And to represent such a code, we can even do that by a generator matrix or party check matrix. This can be really expensive, and not really, it can lead to large keys. So, we are going to add an additional structure to this code. The structure is called Aldiol code. So, what we are going to do is that we have some vectors of length n, and we are going to associate a polynomial of degree n minus 1 to these vectors. So, here g1, for example. And there is an isomorphism between these polynomials and... Thank you. So, I was saying that there is an isomorphism between polynomials and n times a square matrices. So, what we are going to do to build such a matrix from a polynomial of degree n minus 1 is that on the first row, you just write the equations of your polynomials. And then for each row, you multiply it by x. So, this shifts the polynomial kind of, and you reduce it modulo p. p is a polynomial of degree n with coefficients in fq, and the fact that we take the coefficients in fq ensures that the rank weight and the support of the word is kept the same between each line. If you know about quasi-circuit codes, taking p equal to x to the n minus 1 is the same definition. You get quasi-circuit codes. And what's interesting is that now to describe the matrix g, we only need to describe the first row. So, this would lead to smaller keys. All right. So, now I'm going to talk about odd problems for our scheme. The most well-known problem in the rank metric is the wrong syndrome decoding problem. So, we are given h, a parity check matrix of a code, s, a syndrome, and an integer w. What we want to find is an error vector e such that h times e equals s. And we have a constraint on the weight of e. So, if this constraint is low enough, the problem will be odd. But if you take w to be high enough, the problem becomes easy actually. So, this has to be well-chosen in the parameters such that the problem is odd. Of course, this could be specialized for any family of codes. For ideal codes, we will denote this problem i, r, s, d. Now, this is a more recent problem, the RSL problem. It can be seen as a generalization of the RSD problem. So, this time we are still given h, a parity check matrix of a code. But this time, instead of being given a syndrome, we are given access to an oracle that will output syndromes each time we do a request. And the particularity is that each error vector e has its coordinates laying in the same support capital e. So, this is kind of a variant on the RSD problem where instead of having only one syndrome, you are given multiple syndromes. And you know that there is some kind of structure in the support of the errors. All right. So, now I'm going to recall quickly what is a signature scheme. So, it consists of four algorithms, the setup one that gives the parameters, the key gen that gives the public key and the secret key. You can sign a message mu under a secret key sk. And you can verify the signature sigma to check whether it is valid or not on mu. And the security we are targeting is formally EUFCMA. So, if an adversary obtains valid signatures over some messages, it should be hard for him to output a valid signature on a fresh message mu. So, a mu that was not requested during the first phase. Now, this is the straightforward adaptation to the rank metric of the Ljubaszewski framework. So, to generate the keys we choose h, a random parity check matrix of a code. And we choose a matrix s that we call homogeneous matrix because each of its coordinates lie in a secret support e of dimension r. And another part of the public key is t, the product of h by s. And this is an instance of the RSL problem because each column of s can be seen as an error vector of the same support e. And each column of t can be seen as a syndrome. All right. So, to sign a message, you first choose a random vector y of weight w. You then compute a challenge using a hash function. So, you hash h times y and the message mu. Actually, this hash function gives challenge of small weight. And we will denote f, the support of the challenge. You then compute z equals y plus cs. And zc is a signature. The verify step is pretty simple. You check that the weight of z is low enough. So, this ensures that the signature wasn't forged by an attacker. This has to be chosen low enough such that the RSL problem is hard. And then you just check that hz minus tc equals hy, basically. The correctness is pretty easy to understand because when you complete hy, you get hz, sorry, you get hy. And then the second term cancels with that because t equals h times s. So, this is a pretty simple and efficient scheme. But, as I said, it is broken. So, we will see why. We are going to look at the support of z. So, because z is y plus cs, the support of z is included in w, which is the support of y, plus the product space of e, the secret support of the secret key, and f, the support of the challenge c. Actually, we will consider that the support of z is exactly w plus ef, which happens with a really good probability. And this support has, you can write a basis of this support this way. So, x1 to xw is a basis of w, and then you have this kind of product space here. So, because of this structure, you can actually use techniques from the decoding of low-rank parity check codes to recover the support e. So, what we are going to do is that you take a basis of f, and for each element, you invert it, and you multiply each of these by the inverse of fi. And because of the product space structure, e will be included in all of these supports. So, we just have now to intersect all of them, and we recover the secret support, which means that signatures leak information from the secret key, and actually you only need one signature to recover the whole secret key. So, we need a new idea to counteract this attack. All right. So, now I'm going to present you our scheme with the new idea I just talked about. The key gen is essentially the same as before, but you can, the matrix s is now split into two matrices, s and s prime. And what's more interesting is the signing process. So, the first two steps are the same, but now in the first step, we are going to add this term ps to the signature, p as the same support as the challenge c, and as a signer, we get to choose the value of p. And this gives us some, sorry, gives us some degree of liberty to choose kind of a subspace of the space w plus ef, and we're going to change the support of z such that it lies in a subspace of the present support. And actually because we get to choose p, we can target a specific support, and we're going to choose support carefully so that the attack does not work anymore. So, now the signature consists of z, c and p, and the verifier notation is pretty straightforward. So, you add lambda here because you just reduce the weight of the support, and you add this term tp in the adjunction. So, why does that work? When we're adding ps to the signature, we are choosing support for z such that there is no element of the form ef, where ef lies in the secret support, and ef lies in the support of the challenge in the support of z. And if there is no element of this form, we can not choose the decoding of LRPC codes anymore, which does not mean that signatures do not leak information from the secret key. So, we defined a new problem called the PSSI problem. The definition here is pretty wordy, but it's actually pretty simple to understand. You have e, the secret support, and then each time you make a request to an oracle, you have f of weight d and w of weight w that are chosen randomly, and ui is actually a subspace that has the same property as the support of z during the signature phase. And this problem asks to determine whether samples are generating from the signature scheme or where z are just random of the right weight. So, this is pretty technical, but in the paper we give arguments that signatures are pretty close to random. So, just check the paper if you want more details. And this is the main theorem of our work. So, under the PSSI assumption, the decisional RSL assumption and the ideal RSL assumption, our scheme is efcma secure. So, again, I'm going to skip the proof for now, but you can check the paper if you want. Alright. So, what does it give in terms of parameters? We gave two sets of parameters in the paper. As you can see, we have public key sizes of order 20 kilobytes and signature sizes of respectively 4 and 5 kilobytes. So, the scheme is really efficient. These are reasonable signatures sizes in particular. And in terms of timings, so, key gen and verification are really fast. The timings here are given in milliseconds, but as you can see, the signature phase is kind of slow. But an interesting feature is that you can split the signature phase into an offline signature phase where you don't need your server to be offline, sorry. And you don't have to know what message you are going to sign to perform this phase. So, you can do that all the time. And then, if you've done all that, then the online signature phase is really efficient. So, to summarize, we built a new efficient signature scheme that is an adaptation of the Ljubasch's key framework in the rank metric. We have a new idea to counteract the basic attack for the straightforward adaptation. It is proved here EUFCMA secure. And as an open question, we tried to adapt this to the aiming metric, but because there is no equivalent of the RSL problem, it does not seem to work. Or at least this is not that easy. Thank you. So, do you have any questions for Nicola? Please use the microphone on the side. What's the security level of the parameters that you proposed? Because that ... 128. 128? Yeah, classical or quantum attacks? Classical. What would you get if you do like this security level five or three? Actually, the limiting factor for attacks is the distinguish for the PSSI problem. So, I don't think there is a quantum attack that would really target that. So, I don't know. This would need more analysis, I think. Okay. Thanks. What's the second question? Okay. So, if there's no more questions, let's thank Nicola again. Thank you.