 Hello, I'm happy to be presenting some joint work with Kiri Godri and Cecil Perot on lattice enumeration for the tower number-filtered algorithm, a 521-bit discrete logarithm computation. So as we all know, cryptography gives us means to communicate in a secure way between two entities, of course, even in the presence of a needs dropper. And in order to do so, cryptographic protocols are going to rely on some building blocks, which are cryptographic primitives, that rely on hard, intractable mathematical problems. These problems can be factoring integers, computing discrete logarithms, or even problems related to lattices, for example, or isogenous. In this talk, I will focus on one of these mathematical problems, which is the computation of discrete logarithms. So first of all, what is a discrete logarithm? The setup is quite simple. We are given a finite sacred group G of some order n, a generator G of that group, and some element h in the group. And so the target, the discrete logarithm of the target element h in base G is going to be the element x, the exponent, such that G to the x is equal to h. Now, this definition brings forth the following problem, which is known as the discrete logarithm problem, where we are given a target element h in the group, and we are asked to find the element x, the exponent, such that G to the x is equal to h. Now, this problem, the discrete logarithm problem, is known to be hard, but of course it depends on the group G that is being considered. And for cryptographic reasons, we want to choose a group G for which the discrete logarithm problem is as hard as possible. And so groups that are often chosen in cryptography are going to be prime finite fields, finite fields of the form FPN, elliptic curves over finite fields, or genius to hyper elliptic curves. Again, in this talk, we will focus on a particular group G, which is going to be the multiplicative group of finite fields of form FPN. So why do we care about discrete logarithms? Well, many cryptographic protocols are going to use modular explanation in their algorithm, where the exponent is going to be a secret. So a modular explanation is going to be computing a quantity, for example, G to the x in a group G. This is the case, for example, in the Diffie-Hellman-Key exchange protocol, where as public data we have elements of a group G, G, generator G, G to the a, G to the b, and we have a shared secret key G to the a, b. And now one can see that if it is easy to recover either a or b from the public data, so solving a discrete logarithm problem, basically, then one can compute G to the a, b. The Diffie-Hellman-Key exchange protocol is not the only example. In Perry and Gray's protocols, we have identity-based encryption or signature schemes, short signature schemes, where the security is going to be based on some assumptions that would become false if the discrete logarithm problem is broken. Now, evaluating the hardness of DLP over a finite field FPN is not something which is easy. First of all, because many different algorithms exist to solve DLP and FPN. Not only that, but also the complexities of these algorithms depend on the relation there is between the characteristic p and the extension degree n of the finite field. And in order to talk about these complexities, we need to introduce the following notation, which is known as the L notation expressed by the formula given on the slide. This expression, this formula uses two parameters, alpha, which varies between 0 and 1, and a constant c, positive constant c. Now, one can see that if alpha goes to 0, then this expression gives some polynomial time complexity. On the other side, if alpha goes to 1, we have an exponential time complexity. Now, whenever alpha is in between 0 and 1, we talk about sub-exponential time complexities, which is the complexity of all the algorithms we'll be talking about in this talk. Now, the L notation is not only used to talk about the complexities of these algorithms, but it is also used to characterize families of finite fields, and in particular, to separate finite fields into three different families. So if the characteristic p of the finite field is expressed using L of alpha c, as soon as alpha is smaller than 1 third, we talk about small characteristics. If alpha is in between 1 third and 2 third, we talk about medium characteristic finite fields, and if alpha is greater than 2 thirds, then we talk about large characteristic finite fields. Now, different algorithms are going to be used in different, in each of these areas, and also algorithms are not going to have the same complexity depending on which area we're looking at. Now, we have a lot of algorithms with self-DLP for finite fields. In small characteristics, the most efficient algorithms come from a family known as quasi-pollinomial time algorithms, and in medium and large characteristics, we are going to have, as most efficient algorithms, the number field sieve and its many variants. Now, we focus on medium and large characteristics, mainly because these are the finite fields that are being used in practice. So in this work, we are going to present a record computation done with a variant of the number field sieve, which is the tower number field sieve algorithm. And so why do we care about record computations in general? Well, for a protocol, for a cryptographic protocol, it is important to choose the right key size. Of course, if we're choosing something too large, a key size which is ridiculously large, we are performing needlessly expensive computations, and on the other hand, if the key size is too small, of course, our protocol is not secure. Now, the running time of discrete logarithm algorithms is something which is hard to predict. And record computations are thus going to give us useful information for key lifetime, for example. So this motivated us to perform a record computation with a new variant which had never been implemented before, which is the extended tower number field sieve algorithm. And so why did we choose XTNFS? Well, this can be seen with this table, which I will now explain. The first thing to see, to notice, is that extended X in XTNFS comes from the fact that N is composite. So we are going to be considering finite fields where the extension degree can be written as eta times capital. Now, the table on the slide gives the asymptotic complexities of the variance of NFS in medium and large characteristics. Now, all the complexities of these algorithms are expressed using the L notation, and the constant alpha is equal to one third. This is the same for all the algorithms. What we'll change is the second constant C, where we can see that in meridium characteristics, for example, the C is equal to 48 for XTNFS. Whereas for the number field sieve algorithm, the classical NFS, we have a much larger C value, 96. So XTNFS seems very promising for medium characteristics finite fields. This can also be explained or seen intuitively if we look at how we can see or interpret the finite field FPN. Because N is composite, FPN is equal to Fp the eta times kappa. And this finite field can be seen similarly as a finite field F capital P kappa, where capital P is of the bit size of P to the eta. So what has happened here is that we have increased the characteristic of the finite field from P to P to the capital P, which is P to the eta, and we have decreased the extension degree from N to kappa. And this means that the finite field can be seen similarly as a finite field where we would use an NFS computation at the second boundary case, where the constant is also equal to 48. Now, in order to have a record computation with XTNFS, we had to focus on the most expensive step of the algorithm, which is the first step of any index calculus algorithm, which is collecting algebraic relations. And the difficulty of XTNFS is that this relation collection is going to happen a dimension greater than two, whereas in NFS, for example, this relation collection happens in dimension two. So let me focus a little more on relation collections in TNFS. So if you know the number of fields of algorithm, you have probably already seen a diagram such as the one on the slide. And so here we start at the top of the diagram with a ring Rx. R in the specific case of TNFS is Zyota, co-sciented by a polynomial H. In our computation, H is a polynomial of degree 3. Elements of Rx are then mapped to two intermediate number fields, where we just evaluate X into the roots of the two polynomials, X4 plus 1, AX2 plus BX plus C. And then elements of these two intermediate fields can be mapped to the bottom target finite field, Fp6. And so this diagram, in particular, the polynomials X4 plus 1 and AX2 plus BX plus 6 plus C, sorry, are chosen such that the diagram commutes, meaning that we have two different paths that brings elements from the top ring Rx down to the target finite field Fp6. More precisely, the elements on the top ring are going to be polynomials in Yota and X of the form AYOTA minus BYOTAX. These elements are going to be mapped into K1 and K2. So for example, if we look at the right side, K1, we have an element phi of YOTA alpha 1. These elements are then going to be tested for something which is known as B smoothness, meaning that if we look at the norm of the element phi YOTA alpha 1, seen as an ideal, we can see, we can test whether it decomposes into prime factors of smaller than B. So we test whether all the factors of the norm of phi are going to be smaller than a smoothness bound B, which is chosen while when we run the algorithm. If this is the case in the finite field K1 and also in the finite field K2, then these elements are mapped down to the bottom finite field Fp6 and the equality that we get in the bottom finite field actually corresponds to what is known as a relation. These relations are products of prime ideals. And so the idea of relation collection, meaning finding algebraic relations between elements of what is known as a factor basis is given by this diagram, which gives us some sort of equality between products of prime ideals. And the factor basis that is being considered are a set of prime ideals of small norm. So we can look a little bit more in details into relation collection in the specific context of TNFS. So recall at the very top of my diagram, I had polynomials in YOTA x of the form A YOTA minus B YOTA x. So relation collection actually narrows down to finding a set of linear polynomials of this form with two conditions. We want bounded coefficients and we want the norms of A YOTA minus B YOTA alpha i, so in both number fields for i1 and 2, to be B smooth. Concretely, A and B are going to be polynomials of degree 2. And so we are going to be looking at vectors where we have six coefficients, three corresponding to the coefficients of the polynomial A, three corresponding to the coefficients of the polynomial B. So vectors in Z6, such that we have bounded coefficients, this will mean that our vectors C are going to belong to a region, which is usually known as a sieving region. And we want the norms to be B smooth, meaning that the vectors C are going to belong to the intersection of some suitably constructed lattice as L, which I will now explain. So first, let's me focus on the sieving region. So we've narrowed down relation collection to finding vectors C in S intersect L. So what is S? In our case, S is a six-dimensional sieving space. This differs a lot from previous work, where in the classical NFS setup, we would be looking at a two-dimensional space, because in NFS, we are looking for pairs A, B, which belong to Z2. And in order to efficiently sieve in dimension 2, Frank Euclignon provided a very efficient algorithm that is used in NFS computations. NFS can also sieve in higher dimensions. There has been work in that direction from Grémy, Laurent Grémy, and also from McGryan Robinson more recently. And the common point between all of these algorithms is that the sieving space that is being considered is a direct angle, whether it is 2 or 3, they sieve in a direct angle. Our work differs from that choice of sieving space in the sense that we consider a six-dimensional sphere. Now, we have looked at our sieving space S. Now, what is the lattice L that is being considered? Well, L is a lattice that is constructed in such a way that it describes the divisibility of the ideals by, first of all, an ideal Q, known as a special Q ideal, and a prime ideal P in the intermediate number fields. So the idea of these lattices is that elements belonging to the lattices are going to correspond to ideals divisible by Q and by P. So the output of the enumeration are going to be vectors corresponding to our polynomial A and B, A yota B yota, such that the norms A yota minus B yota alpha i are going to be divisible by the norm of Q of our special Q ideal and the norm of P. And I talked about intersection of many suitably constructed lattices because we want the divisibility by many prime ideals P. Why? Because we want a high probability of our elements to be B smooth. So now that I've narrowed down enumeration to actually looking for vectors at the intersection of a sphere and a lattice, we can look at enumeration algorithms, in particular Schnur-Erschner's enumeration algorithm, to efficiently look for these vectors. So Schnur-Erschner's enumeration algorithm takes us an input to lattice basis and outputs the shortest non-zero lattice vector. In order to do so, they're going to construct an enumeration tree, consider projections of their lattice, and at each level of the tree enumerate in an interval. And in the end, a depth first search is done in the tree in order to output the shortest non-zero lattice vector. Our setup is slightly different in the sense that, first of all, our lattice basis are, we are considering six-dimensional lattices, so we're looking at very small lattices. And also, we are not interested in the shortest vector of the lattice, but we are looking at, we are interested in all the vectors C, such that the norm of C is smaller than some parameter R, which can be seen as the radius of our six-dimensional speeder. But the idea of the enumeration algorithm remains the same. We heavily rely on Schnur-Erschner's construction in the sense that we do construct an enumeration tree, consider projections of our lattice, and then exhaustively search for all the coefficients V i, such that our vector C satisfies a norm of C smaller than R. So we actually adapted Schnur-Erschner's algorithm to the TNFS setup by slightly modifying their algorithm. And we also optimized the computation of the vector C by reducing the number of computations. We reduced the number of operations that is being done in our algorithm. And this seems like a very small optimization, but because enumeration in TNFS is done many, many, many times, then this actually provided us with a 10% improvement on our total sieving time, which is non-negligible. So now that we have enumerated our vector C, we can look at the relation collection altogether. And relation collection can often be seen as a sequence of filters where sieving, the first part in our case enumeration, is just the very beginning of the whole process. So how does our relation collection happens altogether? Well, we started with a sieving step, in our case enumeration, where we did find AB pairs in our sieving region S, so in our case in our six-dimensional sphere, that intersected many lattice LP. And so these AB pairs correspond to potential relations, meaning pairs which have a high probability of being B smooth. The second part of our relation collection would be to actually test for B smoothness for these potential candidates. And this can be done using different algorithms, for example, a batch algorithm or ECM. Or the idea is to run these expensive algorithms on a smaller set, so our potential relations, and the output of these algorithms are going to be WB smooth elements, which correspond to our relations. So by going through these different filters, we actually obtain a set of relations. Now, there are some important details that I have left out of this talk. One important contribution of our work is the removal of duplicate relations in the context of TNFS. So duplicate relations, meaning relations that appear twice, so AB pairs that give the exact same information, is not something which is new. It also exists in the number fill sieve algorithm. However, in TNFS, duplicates of a different nature appear, and removing them is a big and important step of the algorithm. So towards the end, what do we actually need for a record computation? Well, first, we focus on obtaining a fast-sitting algorithm that happens in dimension higher than two, so in our case in dimension six. Then we focused a lot of time on actually identifying and removing duplicate relations specifically in the context of TNFS. We actually also had to adapt other notions from NFS to the context of TNFS. This is the case, for example, of shirokara maps, virtual logarithms, and we also had to branch ourselves to KADO NFS, so some pre-existing code for NFS computations. So we did not rewrite the entire code for TNFS. Linear algebra or the Sun step, for example, we simply branched ourselves into KADO NFS. We chose a nice target, FP6, as mentioned at the very beginning, motivated by the fact that the finite fields of this form are used in practice, and this allowed us to compute this 521-bit record computation. So our finite field is more or less between medium and large characteristics if we use this separation into three families of finite fields with the L notation. We can see that the total computation time of our record is about a little less than 25k core hours. The relation collection step, obviously, taking the most time, so we have a relation collection step of a little over 23,000 core hours. And we also were able to compare ourselves with previous algorithms that also serve in higher dimension. In both these cases, they served in dimension three. So this is where they use the algorithm of Lohan Kemi and McGuire and Robinson, where they do use NFS, so they don't consider the tower variant. They consider finite fields of size much smaller than ours, around 422, 423, whereas we consider a finite field of size 521. As I just said, their sieving dimension is three, whereas we use six, but we can still see that our sieving time is significantly faster than theirs. So they go up to 270k core hours, whereas we are down to 23,000 core hours. So we were pleasantly surprised by how fast our sieving algorithm works. And in the end, we ran a logarithm, and this allowed us to output a discrete logarithm. So again, in the finite field FB6, where P is an 87 bit prime, we chose a target where you can recognize the digits of Pi, and this is our beautiful logarithm, the discrete logarithm of our target element in the finite field. So thank you very much for your attention, and I will be happy to answer any questions during Asia Crypt or even remotely. Thank you.