 All right, good morning, everyone. The doors have been closed. Welcome to the last day of the conference of Asia Crypt. And welcome to the second session on mathematical analysis. And it's my pleasure to introduce the first speaker, Sonja Bogos, from EPFL in Switzerland. Good morning, everyone. Thank you, Peter, for the introduction. Sorry for my voice. I have a call, so it might fluctuate while I'm talking. So I hope you won't have problems understanding what I'm trying to say. So the subject of my presentation is how to improve the current state of the LPN solving algorithm. Before I do so, I just want to briefly say that our lab at EPFL is hiring, so if you want to combine your research with doing hikings in the beautiful nature of Switzerland, please send us an email. Now coming back to my talk, first I want to motivate why we study LPN when why we are trying to improve the algorithms to solve it. LPN stands for learning parity with noise and can be informally defined as a noisy system of linear equations when we work with bits. It is attractive, it is believed to be quantum resistant, and so far it has been used in authentication protocols and several crypto systems. Now, a particular aspect of LPN is the fact that it's a special case of LW learning with errors where we don't work in the ring ZP, but we work in binary. For LWE, we know that there are reductions from lattice problems to LWE, and this attests the hardness of this problem, but these reductions don't work for LPN, so it's hardened is not proven so far. So the best way to study its hardness is by improving the algorithms that solve it and by trying to improve these algorithms and specifying what are their complexity, we can actually afterwards state what are the secure instantiations of LPN when this problem is going to be used in authentication protocols or in crypto systems. So what we are doing in this work is that we analyze the existing LPN algorithms and we split them in building blocks. We further improve the theory behind the covering code problem, which was a new technique introduced two years ago with AsiaCreed by Go and others, and by studying the building blocks of LPN, we optimized the order and parameters and we managed to improve the existing algorithms so improve the results of AsiaCreed 2014 and of EuroCreed 2016. So the outline of my talk, first I'll introduce the LPN problem, then I'll tell you how we studied the code reduction and how we improved its study. This will allow me to present our algorithm and to conclude with the results. For the LPN problem, in the case of the LPN problem, we have an LPN oracle. This LPN oracle knows a secret random vector S, so S is uniformly distributed. And whenever I query it, this oracle is going to compute a bit value, which is the inner product between a uniformly distributed random vector and our secret to which we add some noise. And the output of this LPN oracle is this random vector and its noisy inner product with the secret. We can query it as many times as we need and the LPN problem says that given independent queries from the LPN oracle, find the secret S. Now for the algorithms, we say that an algorithm solves the LPN problem if M is able to recover the whole secret in more than half of the cases. This value one over two is one value that we fix ourselves, but this definition can be generalized and we can choose any other parameter between zero and one. And when we're looking at the LPN solving algorithm, we want to study its performance by its running time, its memory complexity, and the number of queries that we require from the LPN oracle. And actually the parameter that is the most important is the number of queries as this is going to dictate the time complexity and the memory complexity. Another aspect that is important when studying LPN solving algorithms is the noise bias. So this is the difference between having no noise and having noise. We can see that if we have no noise, then the bias is minus zero, so it's very far from, minus one, so it's very far from zero, and our problem is very easy to solve. And if the noise is just a random bit, then this bias is zero and it's very difficult. The LPN problem is very difficult to solve. So when looking at the LPN solving algorithms, we want to find a trade-off between the number of queries and the noise bias. We try to keep the noise bias as large as possible, this means less noise and this will help us solve the problem easier, and we try to keep as low as possible the number of queries as this is going to give us an efficient algorithm. And in the case where we are in an LPN instance, where we have to recover a secret S of k bits, the way we do usually is that we reduce an LPN instance, so another LPN instance where we have to recover a shorter secret and we do this through reduction techniques, and then afterwards we are going to recover that chunk of secret and by using a solving technique. We are going to update the queries and then repeat these two steps until the entire S is recovered. So the way we can see an LPN solving algorithm is that we start with our initial instance where we have the secret S, we run a reduction technique, we end up with another LPN instance with a shorter secret, we do this several times until we get to a shorter secret and then we are able to recover through a solving technique. And what we do in our work is actually we try to optimize the use of this reduction techniques. Now, starting all the existing LPN algorithms in the literature, there are several reduction techniques. By running our algorithm, we observe that some of them don't have a big impact on our algorithm, so I'm going to present only those that are essential. And when we look at this reduction techniques, we have to keep track of several parameters, we have to look at the size of the secret, at the number of queries, at the noise bias, and also we're going to see that the secret bias is also important. So remember that from the LPN oracle, you are given N queries. And these N queries, you have K plus one bit vectors where the first K values are uniformly distributed vector and the last bit is the noise in our product between that vector and the secret. And in order to explain all the reduction techniques here, I'm going to work on a particular example. Now for the sparse secret, the goal of this reduction technique is to change the distribution of the secret. Remember that at the beginning, I said that the secret is uniformly distributed. So this reduction is changing the distribution of secret from being uniformly distributed. We reduce to an LPN instance where the secret is constructed such that each bit has the same distribution as the noise. So for example, if we are in an LPN instance where the secret is very low, by running this reduction technique, we are going to end up having a secret that has a small hamming weight and we're going to see that later on we can use this in our advantage. And we do so by losing a couple of queries. The XOR reduced reduction was actually first introduced in the LF2 algorithm by Levy and Foucq. Here the idea is that we try to find collision on a window of B bits. In this case, we are going to take a B equals to three. So we are focusing on the first three bits of each of the queries. And what we are going to do, we are going to group them in equivalence classes. And two queries are in the same equivalence class when they have the same value on that window of B bits. And then what we are going to do is that we are going to XOR each pair of the queries from the same equivalence class. So for example, this query is going to be XORed to this query, then this query is going to be XORed to this one, and then this one to this one. And because they have the same value on the first B bits, when we XOR them we obtain zeros. So what we get with this reduction is that we reduce the size of the secret. But now the new queries are XORed of two original queries. So we have to pay a price in the fact that we are introducing, we have now a larger noise. And the number of queries is going to change, but we find that for a particular value of N, for the particular value of N, the number of queries is going to stay constant when N is larger than this. After we apply this reduction, the number of queries is going to increase, and we have to be careful about this. The drop-reduce reduction is what is used in the original BKW algorithm. Here the idea is to keep only the queries that have zeros on a window of B bits. So again, we're going to focus on our particular case where B is equal to three, and we can see that only these two queries have only zeros. So we're going to keep only these two. Again, we gain by reducing the size of the secret, but we pay a cost in the fact that we are losing a lot of queries. The last reduction, which we call code-reduce, it was introduced at Asia Crip 2014. Here the idea is to use a linear code, C, with dimension K, length K prime, and minimum distance D, and with the generator matrix G, and we try to approximate each vector V i to the nearest neighbor in the code, C. So if we rewrite the value of the noisy inner product, we end up having a new secret, which is shorter, but the price that we have to pay is that we introduce a new value for the noise. So we have to see what's the effect on the noise bias when we introduce this value. And the gain is, again, that we are reducing the size of the secret. While having all these reduction techniques, I'm going to present what solving technique we're using, and here the best one, the most efficient one, is using the Walsh-Hadamard transform. So if you have a function F and we apply the transform on it, we can notice that when we look at the transform at the point of the secret, then this should give us a large value. And all the other values should be close to zero. But in order to have such case, in order to be able to differentiate and to say that the largest value is S and all the others are very far from it, is we need a certain amount of queries. So we pay attention to this detail. Now, for the code reduction, as I said, we introduce a new term in the noise. So we have to compute what's the noise bias for this. And here for this reduction, we study several types of linear codes. We study the perfect codes. We study the quasi-perfect codes. And we study also some random codes that we analyze ourselves. So here I'm going to present the results only for the perfect codes where we're able to say exactly how much noise we're introducing by using repetition code, go-lay code or hamming code. We did the same for the quasi-perfect codes. You can find more details in the paper. Now, if we end up in an LPN instance, and in that moment we want to use a code reduction, we might be a bit restricted because not every code is a perfect code, a quasi-perfect code. So in order to solve this, we use concatenation. So we're going to concatenate code. When we try to apply a code reduce starting with an LPN instance, we look to see if we can speed that code in smaller codes and apply code reduction on those smaller codes. And afterwards we say that the bias is going to be the multiplication of the biases obtained from those independent code reductions. And we want to do this in an efficient way. We want to do and to look at the concatenation that actually is going to maximize the noise bias. So the way we are doing it is that first we are computing the bias for the basic cases where we know how to compute the biases. So we compute it for the perfect codes and for the quasi-perfect codes. And then afterwards for each possible code we look to see what's the best split in the concatenation that is going to maximize this bias. So having all this reduction techniques and the solving technique, we can go and say what is the general idea of our algorithm. First of all, I want to repeat that the way we see an LPN solving algorithm is a chain of reductions. And at the end we apply the Walsh Hadamard Transform. So now our goal, given that we have four reduction techniques that we can use is to try to see what's the best way to combine them. And the first step in doing so is that we're constructing an LPN solving automaton in which we say what is the obvious order in which the reduction techniques should be applied. So in this LPN solving automaton, the initial state is the LPN instance that we have to solve and then we can apply several reduction techniques. At the end we are going to apply the Walsh Hadamard Transform and we reach our accepting state. And for example, the most obvious thing is that we should apply the sparse secret before we apply any code reduce or any XOR reduce as this will maximize the secret bias. So we want to use it in an efficient way. Then afterwards we can see that we accept chains that use only drop reduce and XOR reduce or that use code reduce and here we analyze only those chains that use just one code reduce. And after we have this in mind, after we have in mind the fact that the chains of the reduction should be accepted by this automaton, what we do is that we construct the graph of all the possible reduction chains. So a graph is defined by a set of vertices and by a set of edges. What we are going to store in the vertex, we're going to store information about the secret size and the number of queries. So this tells us, given that we're at the point in a graph, this tells us in what LPN instance we are, how long is the secret and how many queries we have. And the edge is going to do, perform a reduction from one vertex to another. It's going to store information about the bias, how the bias is changes. And where again we want to make it in an efficient way so we don't want that our graph is complete, we don't want to have from one LPN instance vertices to all the other instances, but we want to do it such that we minimize, we maximize, sorry, the bias of the noise. So we are going to have, for two LPN instances, we are going to have a vertex from one to the another if there is a reduction that is going to maximize the noise bias in the reduction that we end up being in. So here we're trying to improve the noise bias and in the same time we try to improve the number of queries. So we try to make the number of queries as low as possible and the way we are doing this is by computing the time complexity. So a natural way to define the time complexity for a chain is that we take all the reductions that we use and we add up their cost and at the end we add the cost of the wash, how they are transformed. Now in order to simplify a bit our analysis, we use an approximation. When we have a chain with several reduction with the how they are transformed, we look at what's the maximum complexity and we call that their max complexity. And instead of looking at the chain with the smallest time complexity, we are going to look at the chain with the smallest max complexity. And after we find this chain, we are going to compute its total time complexity. So we can have a chain like this where each of the colors represent a graph like this where each of the colors represents a chain. And out of this, we look at the one that is going to give us the smallest max complexity and for this we are going to compute afterwards the total time complexity. So by doing so, we obtain the following results. Here I show you a comparison between the previous results and our current work. So the results of Goa and others from Asia Crypt 2014 and the results of Zang and others from Euro Crypt 2016. And here are the instances that we give here. We say what is the secret size and also we say what's the noise level. We can see that we prefer them better but I have to make a specification here. The values that we put for the Asia Crypt and for Euro Crypt are the ones that we recomputed because there were some missing terms but we are not cheating. For example, for this 512, which is the most studied instance, we actually perform better than also the original results that we find in these two papers. And a nice feature for our algorithm is that we can give him an instance where we say this is my secret size, this is my noise level. Find me the best chain in my graph. So we can play actually with several values for the size of the secret and for the noise. So here we have several results and it's nice as this allows us to say what are the secure parameters of LPN such that they can be used in those cryptographic primitives that base the security on LPN and we have a security larger than 80 bits. So to conclude, what we did in our work is that we create an algorithm such that we give us input an LPN instance and it gives us its output. What's the optimal chain and what are the steps that should be followed in order to solve that LPN instance and we manage to improve the best existing works. And actually a nice feature of this algorithm is that if in the future another reduction technique is going to appear, we are able to study it, we are able to see how this reduction chain is going to affect the size of the secret, the noise, the number of queries and then we can just plug it in in our algorithm and see what's the impact and maximize its use. So this concludes my talk, thank you. Thank you very much. Are there questions? So in your talk you mentioned that you use code reduce only once, you did not want to iterate it. I assume that this is because you are using concatenation codes so that several consecutive code reduce are equivalent to a single one. Is there another reason? So another reason would be that after we apply a code reduction we know what's the distribution of the secret. When we apply, afterwards if we apply on that secret another code reduction we are not able to say for sure what's the distribution of the secret and this is actually used later on in our success probability. But we did some tests where we tried to concatenate to see if it's more efficient just to use concatenations or to use one after the other and we didn't discover that it's not very formal done but we just to test it. We didn't discover that this improves a lot the algorithm. Another comment is that in some previous papers people have used random codes instead of concatenation codes and got slightly better results. The main problem with a random linear code is that you don't have an efficient decoding algorithm. But because you are working on fairly short blocks you can exhaustively search for the best code word and random codes are actually behaving very nicely in terms of the density of the code words and they are approximating the perfect codes even though we don't know how to construct explicit perfect codes. But you should look at using random linear codes. So yes, like as you said the advantage is that the decoding as you said as you saw it's based on decoding tables so it's very fast and this is kind of the main advantage and it's also can it's actually practical. People know how to use these codes they exist they have been studied you know the decoding algorithm very easily. So practically speaking it's we prefer more using this type of codes but the random codes but I agree that this can break some improvement. Any other questions? Actually I have a question. So you are optimizing in the end for time complexity. Can you say something about what happens to the memory complexity? Well for the memory complexity it's quite easy because usually the memory complexity is just the complexity to store those queries. So if you look in your chain and you see what's the evolution of your number of queries you choose the one you look at the one where you have the highest number of queries you multiply this by the space that the vector or a query occupies and that's your memory complexity. Okay, no further questions? Well then please join me in thanking Zonia again. Thank you.