 Hi, I'm Andre and I'm going to present our paper, Syndrome Decoding Estimator, which is joint work with Emanuele Bellini. The NIST standardization effort for post-quantum secure cryptographic schemes is approaching the end of the third round and as we know this round will end with a selection of schemes to be standardized, which makes it an increasingly important task to understand the exact security guarantees given by the proposed parameter sets. Since we want to standardize the most efficient, meaning the smallest, parameter sets that actually achieve the desired security levels. In this talk we focus on code-based schemes. There are still three remaining in the third round, that is Classic McElise as one of the finalists and bike and HQC on the alternate list. So the goal of this work is to establish precise security estimates for the parameter sets of these schemes under different metrics, whereas these metrics especially target different memory models. So code-based schemes are usually based on the hardness of the syndrome decoding problem, which we define in a minute and the best known algorithms to attack this problem are information set decoding algorithms and the landscape of information set decoding algorithms is quite diverse, meaning there are a lot of different algorithms of this class and this makes it a difficult task to estimate precisely the complexity of each of these algorithms to then find the minimum over all these estimates to finally derive the security guarantee of a proposed parameter set. So in this work, we observe relations between all major ISD improvements, which allows us to unify them in a kind of framework. So we find that all of them are internally solving some kind of nearest neighbor routine or nearest neighbor problem and their biggest difference is how they solve this problem. So by substituting the routine used to solve this problem, we obtain the different formulas, the different estimates for the complexities of these algorithms and we provide these formulas in a tool called syndrome decoding estimator written in Python, which allows to estimate the hardness of arbitrary instances and using this tool, then we obtain precise security estimates for the different schemes. The talk is structured as follows. In the first half, we will investigate this framework and see how the different ISD algorithms fit into this and in the second half, we will then talk about the different memory models and the precise or concrete security estimates. So let us start with the definition of the syndrome decoding problem. So for the syndrome decoding problem, we're given the parity check matrix of a code. It's n minus k times n matrix and the syndrome s, a vector of length n minus k and integer omega. So everything is binary here. We are working in F2 and we are asked to find an error vector e of length n, which fulfills the identity h times e is equal to s and has an hamming weight of omega, so meaning it has exactly omega coordinates equal to 1. So visually, we will represent this as follows, h times e is equal to s and note that e is basically a selection of columns of h that sums to s. Before now diving into the details of the different ISD algorithms, let us make some basic observations. So we can permute an instance and still maintain this identity here. So this means we can permute the columns of the parity check matrix as long as we apply a similar permutation to the error vector. So this basically models the fact that we can multiply the parity check matrix by a permutation matrix from the right as long as we multiply the error vector by the inverse permutation from the left. And this allows us to redistribute the weight of the error on the full coordinates. So we can achieve a random weight distribution on e. So now we have here our permuted instance and we can apply another transformation by still maintaining the identity, that is we can multiply both sides with an invertible matrix. And we can craft this matrix such that we diagonalize the left part, the left n minus k times n minus k sub matrix of the parity check matrix. And of course this changes the syndrome, but we maintain the identity. And as I said the permutation allows to redistribute the weight on the error. So in the following we will assume that this permutation distributes the weight such that we have a weight omega minus p on the first part of the error and weight p on the second part where p is an optimization parameter of the algorithm. And we can write this identity as h prime times e2 is equal to s prime plus e1. And it's noted that the error weight in general is small compared to the length of the vector. So e is a small weight vector, meaning that this identity here is we can somehow define an approximate identity between h prime times e2 and s prime approximate in the sense that it holds up to the addition of e1, but e1 is small or of low hamming weight. And ISD algorithms then work in a quite similar fashion. So all the algorithms work in a quite similar fashion. They first permute the instance to redistribute the error weight hoping for weight p on e2. Then they apply the Gaussian elimination to diagonalize the left part of the matrix. And finally, they try to solve this almost identity. So finding an e2 such that h prime times e2 is close to s prime. And note that the optimization parameter p allows to shift either more or less work into this third step. So for example, for p equal to zero, this third step becomes trivial because there's only one possibility to check. But the higher p gets, the more costly the search for e2 becomes. But on the other hand, the more weights we shift into e2, the more likely it becomes that we permute the error weight as desired. So should the third step not result in a solution, the algorithm starts over with step one, so a new permutation because the permutation did not distribute weight p on e2. Now let us look into different ISD algorithms and how they approach this third step. So here we will skip the original ISD algorithm by Prang, which basically chooses p equal to zero and dive directly into the improvements made by Stern and Dumair. So here we have the identity h prime times e2 equal to s prime plus e1 visualized. And both algorithms, the one by Stern and the one by Dumair, start by splitting e2 in a meet-and-the-middle fashion. So they split e2 into vectors where the first one has weight only on the first half and the second one only on the second half. Together they form a vector of weight p. Now we label both parts of the vectors with x and y accordingly. And then by splitting the matrix in the same fashion we can move the dependence of x and y on different sides of the equation. And this allows us then to create two lists, one containing h1 times x for all possible choices of x and another list of containing h2 times y plus s prime for all possible choices of y. And now we can find e2 by finding actually e1 close pairs between those lists. And this means we are basically interested in finding close pairs between those lists which are nearest neighbors, which is the nearest neighbor problem. So now both algorithms do not solve the nearest neighbor problem directly on all coordinates. They work on a projection of coordinates. So for example, let us take the last l coordinates of the vectors and then try to solve the nearest neighbor problem on these coordinates and finally checking if for the found solutions they are short on overall on all coordinates. So the algorithm by Stern now simply assumes that for the chosen projection the weight of e1 is 0. So e1 is 0 on the chosen projection. This then allows us to perform a simple search for equality on this projection between both lists. And for all matching pairs it then checks if the sum is short on the remaining coordinates. And of course we do not know if this if the projection of e1 is 0. So we have to repeat this procedure for several projections until we might assume that one of them does for one of them is the whole set e1 the weight of e1 is 0. And some of you might have noticed that this procedure of finding near elements between two lists by projecting them to random coordinates and searching for equality on these coordinates is actually known as a procedure called Indic Modvani Locality Sensitive Hashing. So Stern's algorithm is solving this nearest neighbor problem by using Indic Modvani nearest neighbor search. So now Dumer's algorithm differentiates in the way it solves this problem. So it does not no longer assume that e1 is 0 on this projection but it has some weight on this projection. And of course we cannot search for equality anymore because the identity now depends on e1 again and we did not account for this. Now the algorithm splits the weight on the projection of e1 again in a meet-and-the-middle fashion similar to how we split e2 and x and y and moves one of these parts to the other side of the equation. This then allows to not only perform a meet-and-the-middle on e2 but also on the difference. Meaning we do not only enumerate x in the list but x and the difference and y and the difference respectively. And this of course increases the lists but we also can search for equality on this projection again. So this is basically a meet-and-the-middle algorithm for solving the nearest neighbor problem which is how Dumer solves this nearest neighbor problem. Next let us investigate how most recent ISD improvements work and how they employ nearest neighbor search. So most recent ISD improvements usually split e2 not only in two but in four or even more add-ins. And we find that for the cryptographic setting four add-ins is almost also splitting into four add-ins is almost always optimal so let us stay with four for the moment. And then the algorithm again similar to the algorithms by Stern and Dumer create multiple lists here containing h prime times xi and adding the s prime to the last list so that they are now need or they are now searching for one element from each list which such that they sum together to something that is small. And they find these elements by combining two lists at a time and first again on a projection searching for some vectors which are close or add up to something small and then in a final step they search for vectors that are small on the other coordinates. And as they were already small on the projection they will add up to something that stays somehow small. And of course to create those lists the algorithms need to employ nearest neighbor search algorithms again. We find that by using the kind of meat in the middle technique to solve this nearest neighbor problems we obtain variants of the improvements known as MMT and BJMM named after the inventors Maimoyer and Dumer and Bekha Jew Maimoyer. And now by substituting these subroutines for nearest neighbor search we obtain different IST algorithms. For example by if we exchange the meat in the middle strategy on the last level by a nearest neighbor technique by Maia and Odzorov we obtain an IST algorithm similarly known as Maia Odzorov IST algorithm. Unfortunately the nearest neighbor search technique by Maia and Odzorov is not very practical so it inherits huge polynomial overheads such that in our practical considerations we exchanged it by the Indic Modvani procedure which gives the first practical variant of the Maia Odzorov algorithm. And now by exchanging the subroutines on both levels by the nearest neighbor search technique from Maia and Odzorov we obtain an improvement made by both and Maia. Again since Maia Odzorov nearest neighbor search does not yield good practical complexities we exchange it by the Indic Modvani variant. So this gives a simple framework to determine the practical complexity of different IST algorithms. Of course the time complexity formula shown here is further simplified but it boils down to the number of permutations needed to ensure the correct weight distribution times the time it takes to compute the diagonalization of the matrix plus the time for the tree computation. And the time for the tree computation is mainly dependent on the chosen nearest neighbor routines which determine the time needed to construct the intermediate and the final list. Before we look into what this means for the security of the proposed parameter sets let us investigate the cost of memory because all algorithms we've seen in this talk so far rely on some enumeration procedures which involve lists of large size. Here we see a timeline of ISD improvements and when they originated. So please note that this is just a selection of improvements there are plenty of others omitted here and as we said in the beginning we also omitted in our presentation the original algorithm by Prange and also an improvement by Lee and Brickel. So note that these ISD algorithms would actually only require a polynomial amount of memory so they do not rely on enumeration procedures but all algorithms we've seen use an exponential amount of memory and as a rule of sum you can say if going from left to right these algorithms use more and more memory and the access to these amounts of memory will definitely slow down the computation of the algorithm. So the question is how do we account for this in our security estimates where the conservative answer is probably we don't but the more realistic answer is we introduce a time penalty. So an algorithm with time complexity t and memory complexity m is set to have cost t times f of m where f is some penalty function. So for example we obtain quite directly the conservative setting if we set f of m to 1 so or some other constant which is why this setting is known as a constant access setting. There are other established penalty functions such as the logarithm or the cube root or even square root which are then known as the logarithmic the cube root or the square root memory access setting and we will investigate these three settings here constant logarithmic and cube root in our in our considerations. Now I said that the algorithms have an exponential amount of memory usage but this is only half the truth because it depends on the on the weight omega so exponential is the memory usage only if the error weight is a constant fraction of the code length so of the length of the vector but for cryptographic applications this is usually not the case. So let us investigate how relevant the memory usage is for cryptographic sized parameters. Here we see the the memory usage for the bike and HQC setting where which use a very low error weight omega of just size square root of n and on the left we see the plot where we have on the x-axis the code length ranging from basically zero to parameters offering about 250 to 300 bits of security and on the y-axis we see the logarithm of their memory usage for the exemplary algorithms or by bgmm stern and prange. We see that all algorithms for all parameters use a quite moderate amount of memory so no memory so no algorithm actually exceeds the memory usage of two to the 45 bits of memory so for bike and HQC memory seems not to be the relevant factor. The picture changes a bit if we investigate the meccalese setting. For meccalese we have an error weight which scales with n over log n so it's higher than in the bike and HQC setting and this translates to the memory usage of these algorithms. We see for prange still we have very low memory usage but for the improvements which rely on enumeration so for stern and bgmm we have a drastically increased memory usage where stern uses roughly two to the 100 bits of memory and bgmm almost two to the 200 bits of memory for parameters that offer about 250 to 300 bits of security. So for the meccalese parameters besides the question if such amounts of memory will be ever available the the excess timings to these amounts of memory will certainly slow down the computations of the algorithm. Equipped with this knowledge let us now investigate the security level of the proposed parameter sets again starting with bike and HQC. NIST provides three categories security categories that relate their security to AS meaning set is set to be secure in category one three or five if it is at least as hard to break as the respective AS instantiation and let us start with a conservative model so this constant x setting where we do not account for the memory usage and we find that bike already matches all security levels under this metric and here in the table we see the security margin that bike has over breaking AS meaning in bike category one is three bits harder to break as AS 128 for example and the negative number would therefore correspond to a security deficit. Of course if we now introduce memory access costs then we can only increase these security margins and the same holds for the HQC for the HQC scheme also here HQC matches the security levels already under the conservative in the conservative model so we recall that bike and HQC both use a very small value of omega so for all instantiations we see here the memory usage is quite low with only two to the 40 bits of memory so a maximum of two to the 40 bits of memory we see again for bike and HQC memory is definitely not the most relevant factor. Let us next investigate the meccalis the classic meccalis parameters so the same categories hold for the meccalis scheme the only difference is that the meccalis team provides three parameter sets for the category five five a and five b parameter sets roughly giving the same security and category five c set meant to provide very high security guarantees starting with the constant access model we find that only category one and the category five c set are matching their security levels but to be fair this is known to the meccalis team and they say that the algorithms used to obtain these security estimates use high amounts of memory and the access timings to these amounts of memory will make up for the difference and they are somehow right these algorithms use a high amount of memory which ranges from two to the 90 to two to the 200 bits of memory and as I already said the their existence of these amounts of memory are already questionable so before looking into memory access timing or memory access costs let us investigate how the complexity behaves if we limit the memory so if we employ some memory bounds so remember that the algorithm has this optimization parameter p which allows them to shift more or less weight into the enumeration part and by decreasing this value of p they shift less weight into the enumeration part which allows them actually to consume less memory and we see that we decrease the deficits a little bit and we increase the margins but overall the picture stays the same the same we observe if we impose logarithmic memory access costs so here the algorithms are penalized by the logarithm of their memory usage but they still have the same memory usage as in the constant access setting depicted by the same color here so the memory usage as a memory cost is actually too low to make the optimization choose a different strategy if we then go to the cube root access setting we see that the picture changes drastically so that here the memory access cost is so high that the algorithms optimization actually tries to avoid the use of memory meaning we see that the memory here ranges only the memory consumption ranges only from two to the 25 to two to the 47 bits of memory and most of the parameter sets are then able to match their their security levels even if not equally well and the category three set seems to be somewhat an outlier here which is not able to match the security level under any of the employed metrics so what does this mean for the code-based cryptographic schemes for bike and hqc we have seen that they match their security levels already under conservative metrics meaning in the constant access model where we do not impose memory access costs which is the result of the very low error weight they are using and as a rule of sum one can say that the more or the higher the error weight becomes the more memory these the more memory these algorithms use and hence the more relevant it becomes or the more necessary also to precisely model the memory access costs we've seen this especially for the McElise submission but also for the bike and hqc team we suggest to decide for metrics under which the parameters should be proposed and then to ensure that all proposed parameter sets match the security levels equally well so our paper is online thank you very much and for details please give it a look