 Okay, let's continue with the next talk, which is Mac, Alice Needs a Break, Solving Mac-Alyse 1284 and quasi-cyclic 2019-18 with Modern ISD, a paper by Andrei Esser, Alexander Mai, Floyd Svedinger, and Floyd is giving the talk. Yes, thank you for the introduction, and thank you for having me here, even though it's such a long title, somehow we had a little bit of luck. Okay, I think you all know why we're here. The list, round three selection process is finally closing down, hopefully, someone. And there are three code-based crypto schemes still left in the competition. As a finalist, Classic Mac-Alyse, and as two alternative candidates, Byke and HQC. And obviously for every of the candidates, but for the code-based schemes, especially we need exact security estimates to argue about the security, the performance, and everything. And in this talk, I want to give you these security estimations by answering two major questions. First, do we need to take into account modern ISD? ISD stands for information set decoding and is a class of algorithms, which are known to be the best attack on code-based crypto schemes. And the recent developments in this area produced algorithms which use a gigantic amount of memory. And obviously, if an algorithm uses like terabytes of terabytes of RAM, your application will slow down. And the question is, how do we modelize these memory accesses correctly? And that's the second question I'm going to answer today. What's the correct memory cost model for ISD? And in this talk, I'm going to talk about three different models. First, the constant one. Secondly, the logarithmic one. And third, but not least, the cube root, where in the first one, the estimation of our algorithm is not penalized at all. Second, obviously, as the name suggests, we penalize the runtime on a logarithmic amount of memory the algorithm uses. And for the cube root, well, we penalize it with a cube root. The memory uses. OK. So our results are the first public available implementation, high performance implementation of the MMT BGMM algorithm. So even though I'm only talking about binary codes today, this implementation is perfectly well designed to handle different codes over different prime fields, not only over F2. And with this implementation, we were able to state precise security extrapolations for the code-based crypto schemes I just mentioned. OK, cool. Let us directly dive into information set decoding. Well, before we can actually talk about algorithms, I think we should know the problem we want to solve. And that's the syndrome decoding problem. Given the parity check matrix H with n minus k rows and n columns and the syndrome S, the goal is to find an error vector of length n, which puts these two into correspondence via h times e is equal to S. Or in other words, as the picture already suggests, e is somehow selecting a subset of columns, which sum up to our syndrome S. And the whole problem is getting quite hard if we restrict the hamming weight of our error vector to an omega. In the binary case, omega is normally much, much smaller than n. OK, that's the problem we want to solve. Let's have a look into the algorithms. Information set decoding. Every ISD algorithm starts by applying a Gaussian elimination to our parity check matrix, which results in an altered parity check matrix where the first n minus k rows is the identity matrix. And the rest is an altered parity check matrix H prime. I symbolize the Gaussian elimination with a capital G in this presentation. Everything that's orange is known. Everything that's blue is unknown. So also note that I directly split up our error vector into e1 and e2. So this allows us to reformulate the parity check equation to e1 plus H prime times e2 is equal to our altered syndrome S prime. Now, let us assume for a second that the error weight, omega, is distributed as follows. P errors are shifted into the second half of e2, whereas the rest omega minus p error vectors is shifted into the first e1. Now also assume now for a second that we know the error vector of e2. By simply rearranging e1 and S prime, we receive the following formula. H prime times e2 plus S prime is equal to e1. Meaning if we know e2, we can simply recompute e1, meaning we can recover the full error and therefore the solution. And note also that because of the weight restriction of omega minus p on the error vector e1, this rate restriction must also hold on the left side of the equation. Meaning we have now a simple and fast, easy to compute formula or a check whether we found the correct e2 or not by simply calculating the hamming weight of this formula. Well, obviously such a weight distribution is not holding in general. Well, this is because every ISD algorithm must apply a random column permutation before head. This means every ISD algorithm is actually a three-step algorithm, first permutating the columns, second apply the Gaussian elimination, and third but not least try to solve the right part of this equation. How well the question is, how do we enumerate this e2 such that it's a valid solution to the whole problem? I think this is a good point to fill this whole thing a little bit with life with real numbers and stuff. So, and these are actual dimensions of the challenge we broke stated in a title. So we have 1,284 columns and 256 rows. Note that p was choosing to be four, which means the rest omega minus p is 20. So the overall weight of the challenge was 24. Okay. And as I already stated, all the different ISD algorithms differ in the way how they enumerate this red square, meaning how do we enumerate e2? And to understand this, we are now diving a little bit deeper into this parity check matrix H prime, which you're seeing currently on the top of the slide and just below the arrow vector E. And the first algorithm we are going to see is the algorithm by Prange from the 60s. And the idea of Prange was simply permute no arrow vector at all into our e2 vector. I want to remember, I want you to remember this name because this is going to be our baseline for the rest of the talk. The next idea, if you're now doing a little time skip into the late 80s, beginning of the 90s is due to Stern and Dumair, whose idea was, well, a simple meet in the middle technique by not just enumerating every arrow vector, but building up them in a meet in the middle fashion while enumerating weight p half on each side of the arrow vector. And if we are now doing the step into the modern era into the year 2012, 2011, 2012, we are coming to the algorithm of MMT and BGMM, named after their inventors, Maimauer-Tumor and Becker-Joux Maimauer. Their idea was actually also to represent the arrow vector as a sum of two different arrow vectors, while allowing not just this meet in the middle split, but to distribute the weight on the full length of the arrow vector. While simply doing this would be far too expensive, they are applying a lot of different tricks. And one of them is to build up each of these vectors again as the sum of two add-ins. And how they are doing this in a search tree-like manner. So we start with four baselists while enumerating Xi, which have a weight of p quarter. Well, the algorithm now starts to enumerate every pair in these lists, which are equal on a certain amount of coordinates, while these coordinate certain amount is an optimization parameter. So, and each of these pair is put into a new intermediate list. And note that now our Xi's has weight p half. Now the algorithm proceeds by again looking for pairs which are equal on the remaining of coordinates. And we restrict only valid solution to have an error weight of p. And this is actually everything we implemented which allowed us to get the following results. In total, we were able to break seven different cryptographic challenges which are publicly available at decodingchallenge.org. There are no self-cooked challenges whatsoever. We really had to break them. So we broke two challenges in the Gopah-McElise setting and five in the quasi-cyclic bike HQC setting. And as you already see in the red highlighted columns, in total, we spend roughly one month on breaking the McElise challenge and roughly three and a half days on breaking the quasi-cyclic challenge with roundabout 512 cores. To get into, to put this everything a little bit more into perspective, I want to have now a closer look into the quasi-cyclic setting and the challenges we broke. Okay, on the graph, on the x-axis, you see the code length of the challenges and of different codes. And on the y-axis, you see the logarithmic scale, the CPU time, we needed an expectation to break each of those challenges. How did we get these numbers? Well, we took the syndrome decoding estimator by Essa Bellini, which states an expected amount of permutations we need to choose randomly until we hit one, which permutes the weight exactly as we needed. And this number is divided by the permutations per second we are able to proceed per core on our implementation. So little example, if we have a look into the biggest challenge here on the top right corner, we see that the estimator tells us we need roughly two to the 32 permutations until we hit the correct one. And in total, we were able to process two to the four permutations per second per core, resulting in a total expected runtime of two to the 28. Okay, in the quasi-cyclic setting, the error weight is chosen to be equal the square root of n and the code dimension is n half. And now remember the first question I questioned in the beginning, do we need to take account modern ISD while estimating the bit security of code-based crypto schemes? And to answer this question precisely, one needs the result by Sandrea and Torres of the year 2016, which states that every algorithm, every ISD algorithm converges to the following runtime, two to the square root of n. Note, this is an asymptotic analysis, so this drops every polynomial logarithmic factor. And which means if we now analyze the runtime of our baseline algorithm by Prange, we only add a small O of one in the exponent because an implementation, an actual implementation will only add polynomial overhead. And the question now is if the algorithm of BGMM and its improvements somehow improves this bound, so do we get the plus minus small O of one? And to answer this question, we interpolated our expected runtimes on the graph to the function which is written in the exponent of our runtime formula of every ISD algorithm. And if we compare the slopes, so the question is, is A bigger or smaller than one? And the answer is it's exactly 1, 1.01, which means our implementation on our hardware already reached the asymptotic behavior of the BGMM algorithm, which means to answer the question, no, in a quasi-cyclic setting, we do not need to take modern ISD into account while estimating the PIT security. Prange is enough. Well, let's go ahead and look into the Macalese setting where the graph is exactly the same as before on the x-axis. You see the code lengths on the y-axis, the CPU time and expectation to break these challenges. To get this point, we did exactly the same thing as in the quasi-cyclic setting. The only thing that changes is the weight, which is now N divided by log N. And K, the code dimension is set to 0.8 times N. Again, the result by Sandrea and Torres states that the every ISD algorithm converges to 2.32 times omega. And Prange only adds polynomial overhead. There's nothing you can do. And again, we can question ourselves, ask ourselves, is the BGMM algorithm somehow improving on this bound? And to answer this question, again, we interpolated our expectations here on the left to the formula in written in the exponent of our runtime formula. And now again, we can ask ourselves, if rA is bigger or smaller than 2.32. And the answer is, it's smaller. It's 2.17. Meaning in the Macalese, in a Gopal-Macalese setting, our implementation is not reached as asymptotic behavior right now. Meaning, and to answer the question, yes, BGMM must been taken into account while estimating the bit security of Macalese. Don't get confused by this minus 22. This only means that we break the smallest challenges on this graph faster than one second. And this leads us to the second question. As I already said, we want to estimate the memory, we want to define the correct memory model our algorithm should use, our estimation should use. And for this, I quickly restate our three models, the constant, the logarithmic, and the cube root model. Now we read it the whole thing for every of these penitalization models. Meaning we are rerun our estimator while penitalizing it under the different models. And then recalculating the extrapolation slope, which results in the slope 2.04 in the constant model, 2.13 in the logarithmic model, and 2.24 in the cube root model. And one sees that the closest to our slope of our experience is the logarithmic model, which answers now the second question, to correctly modelize modern ISD algorithms one should use the logarithmic memory model. Cool, now we answered our two main questions. Now we can proceed to estimating the bit security. And I think we should start, we spoke a lot about Macalese, I think we should keep it that way. So we speak about Macalese. The next one's released three different categories which corresponds to the security of AES. So why do we have five of such categories on this slide? Well, the Macalese teams somehow published three different parameter sets for the highest security of AES 256. Note that the first two are designed to have equal security guarantees AES 256. And the biggest one is for very, very hard, very, very high security guarantees. Now, the table reads as follows. If we run our estimator in a logarithmic memory penalization model, but allowing unlimited amount of memory, it means that the first parameter set of Macalese is one bit harder to break than AES, the corresponding AES level. Or on the other side, if there's a negative number, it means that Macalese is two to the 23 times faster, faster to break on real hardware than to break the corresponding AES level, in this case, 192. So one sees clearly that only the first and the last parameter set reaches their security claims, whereas the rest falls off by around about 20 to 23 bits. Okay, an algorithm in this case would, we allowed unlimited amount of memory and unlimited means in this case, two to the 200 bits. And it's quite questionable that such an amount of memory will ever exist. So we restricted our extrapolations again by two to the 80 and two to the 60. And note that the overall images stays the same, only the first and the last parameter set reaches their security guarantees, where the rest falls off by 18 to minus three bits. For completeness, we also have the constant, which means the most conservative memory model, where things only get worse for the Macalese crypto systems. And the cube root model, which again, which is the only model, which is like really the weakest model in this case, only in this case, all of the Macalese parameter sets reaches the claimed security, except for the AES 192 parameter set. Okay, if we now look at bike and HQC, the quasi cyclic setting, again, we have our three parameters set, our three categories corresponding to different levels of AES. And as I already said, we do not need to take modern ISD into account and this reflects in this graph, under every memory, memory penitalization model, bike reaches its claimed security and the same holds for HQC. Whatever you do, we are secure under modern ISD. Okay, I think we are ready for the conclusion. As I already showed you, bike and HQC are secure under modern ISD implementations. The same holds not for Macalese, where we clearly saw that most of the parameter sets are below their claimed security and especially the AES 192 parameter set is always off its security and we encourage the Macalese team to readjust this parameter set to reach the claimed security levels. And also I want to note that the correct model while estimating these security, the bit security of the schemes is the logarithmic model. It's the most realistic model. And with this, I want to say thank you. If you want to dive deeper into this topic, the paper is publicly available at ePrint and the same holds for the implementation. Thank you very much. We have questions. Then you have to come to the microphone. Thank you for your talk. Do you have a physical intuition on why would the logarithmic model would be the most performant for the memory access? No, sorry. No idea. I mean, there are a lot of people claiming that the Q-Proot model is the correct one for their implementations. And we put a lot, a lot of effort in optimizing the memory accesses of our algorithms. And but I don't have any electrical engineering argument about why this should be logarithmic and not Q-Proot or the other way around. Sorry. Okay. If I got it right, you said you took 30 days to break McLeese for parameter set N equals to something 1,200. Yes. What do you expect for the parameter set N equals to 3,500? A lot of years. I don't know it exactly if you want. You can ask me after the talk and I can calculate it for you exactly. I don't have the numbers, so the stated security, at the stated challenge in the title is roundabout 65 bits of security. If we argue now that the smallest parameter set is roughly hitting 128 bits of security, you can take the difference and multiply it by the 35 days we needed. Do we have other questions? I have a question. Yes. You said that some parameter choices are below what they should be. Do you have an intuition of how it would affect the efficiency of schemes that are like, let's say you increase the parameters, how would that affect? To be honest, I don't think it's not that much of a panel class. You increase N a little bit and that's it. I mean, it's a lot of 20 bits, but I think it should be easy to increase and to reach higher securities. It should be not that bad. Okay, thanks. Okay, so with that, we conclude the talk. Let's thank the speaker again.