 Thank you for the introduction. So I'm Romain Poussier from the University Catholic de Louvain, and I will introduce you a new key enumeration algorithm. So for the outline, I will first do a brief introduction about decision and attacks. I will explain what is key enumeration and rank estimation and what is important. Then I will introduce in particular one rank estimation algorithm, which I need to then introduce our key enumeration algorithm. And I will show the experimental results, and then I will conclude. OK, first of all. So there is this picture that shows the global idea of how it works such an attack. Actually, you've seen it at the previous talk, but in Belgium we like recycling. So on the bottom left, we can see the beginning of an AS execution. So you have a plain text value x, which is called with a secret s. And it goes through an s bot and gives a value z. And I also assume that as an attacker, I also have access to the power consumption, for example, of the device, which is running the AS. And in particular, I have this sample leakage L, which corresponds to the manipulation of this value z. What I will do is I will try to modelize how this value z leak in practice for all the different secret values s. And then when I want to go to the attack phase, I will do a comparison between my model and my actual leakage. And I will maybe, if my model is good enough, get some information on my secret. OK, now let's say I want to attack an entire key, which is here shown in red. In the case of a block cipher, what I usually have is that this key will be divided in small independent parts, which I call subkey. Here I have n such of this. And what I will do is I will do a divide and conquer attack. I will do n independent attack on each one of the subkeys. So let's focus on the left. I want to attack key 0. Here I assume an 8-bit subkey. So I have in total 256 possible values. And after my attack, for all these values, I will get a probability that this value is the actual one. So in the end, what I have is I have n different lists, each one containing 256 different probabilities. And what do I do with that? I have mainly three cases. Let's first look on the left. It's where I have enough such information, which means that my actual key has the biggest probabilities in all the different subkeys. In that case, well, actually I'm done. I just have to concatenate all the best subkeys, and I directly recover the full key. I have the case in the middle where I don't have enough such information, which means that each at least one of these lists, the actual subkey is not ranked first. But I do have enough computational power to output all the key from the most probable one to the least probable one up to the good one. And that's what we call key enumeration. And the number of keys that I output before the actual one is called the rank of the key. And basically as an attacker, that's what I want to do. And the last case, it's where I don't have enough such information and I don't have enough computational power as well. For example, if the key rank is 2 to the 100, there is no way I can compute up to this. But what I can do, if I know the real key as an evaluator, I can estimate the rank of this key. And this is very important because if I'm only stuck with the direct recovery case, it's kind of a binary situation. Like, either I succeed, either I don't, but I don't know how close I was to succeed. For example, if the key rank is 2 to the 10, actually, direct recovery, we say, will tell, OK, I didn't succeed, but 2 to the 10, it's nothing. So actually, the attack worked. On the other side, if the key rank is 2 to the 100, I can say, OK, I'm secure against this attack. OK. Now, about rank estimation. So let's give a quick look on the literature. We have many algorithms in a few years. And mainly, we have 3-1 from Glowals, Bersa, and Martin, which are very, very efficient in less, in a few seconds, I give a very good estimate of the rank within one bit of accuracy. And here, I will describe the algorithm of Glowals at AL, because we build our key numeration on their rank estimation algorithm. So mainly, it works in three steps. First, it builds histogram from the Sachin attack results that I've shown before, which are the endless of 256 probabilities. Then it will combine this histogram and count the rank. OK, first step, building histograms. Let's look at the left picture. This is an histogram that I've built from all my 256 probabilities for the subkey 0. So basically, on the y-axis, we have the number of keys that have log probabilities given by the x-axis. I will explain afterwards why I do need log probability. And since I'm in the case of rank estimation, I'm an evaluator. I know the real key. So I know what is the probability of the real key. So I know in which bin it will fall. This is given by the red curve here. And basically, if I want to know the rank of the subkey, I just have to count how many elements I have in the green zone, that is all the bin on the right of the actual key. And so I can do this for all my subkey. OK, and what do I want to do next? It's to combine all this histogram. Here, this is the combination of the two histograms that I've shown earlier. These two histograms were for 8-bit subkeys. So it was only 256 elements. Now, if I combine all the possible combination of subkeys, I have this histogram, which contains two to 16 elements. And again, I'm an evaluator, so I know what are the probability of the two real keys. So I know where the combination probability falls, which is again given by the red curve. And again, if I want to know the rank, according to this combination, I just count how many elements I have in the green zone. But in practice, how do I do this combination is I will use histogram convolution. And actually, this is why I need log probabilities, because convolution does exactly what I want. But it works with additive property. Of course, my probabilities have a multiplicative property. So I have to go to the log domain to get an additive relationship. So we have our n-basic histogram from h0 to hn minus 1. When what I do is I just iteratively do a histogram convolution until I get my final histogram h. And here is an example of such an histogram. So actually, it was a real one from an actual attack on EAS. It's a blue curve. And so if we count the number of elements in old bin, we have two to the 128 different elements. And again, since I'm an evaluator, I know the probabilities of all my 16 subkeys. So I know in which bin it falls. So this is given again by the red curve. But actually, what I didn't mention is I've done some errors in the building phase. When I first built the initial histograms, actually, I lose information about my real probabilities. It's like I was rounding the real probabilities. So I lose some information. But I can bound this last. Actually, if I want to get the higher bound, I have to go to n divided by two bins on the right and to get the lower bound n divided by two bin on the left, where n is the number of compilations that I've done. OK. So now I will present the key numerical algorithm. So first, again, let's have a quick look on the literature. I will first talk about the algorithm of Vera Charvignon et al, which has been presented in 2012. This key numerical algorithm was optimal, which means it was 100% sure to output the key from the most probable one to the least probable one with no errors. But it has two drawbacks. The first one is that it's very memory intensive, meaning that, for example, if I want to enumerate more than 2 to the 36 key, it was consuming gigabytes and gigabytes of frames. It quickly becoming feasible. And also, it's completely sequential, which means I cannot enumerate more than one key at a time. Then we have many other key enumerations algorithm recently. Specifically, I will focus on the one from Martin et al on the bottom left. This algorithm is suboptimal, which means I'm not totally sure to enumerate the key in the right order. But I can compute bounds on this list. It's memory efficient, which means I don't have any more memory problems to enumerate, and it's fully perishable. And then we have our key enumeration algorithm on the middle right, called histogram enumeration. It's also suboptimal. And what is very nice is that we can compute very easily the bounds. These are the exact same points that I've shown for the rank estimation, like when I count bin on the left and bin on the right. It's also memory efficient. You have no more memory problem as well. And I can very easily parallelize this. OK, first steps. First steps, first two steps are actually the exact same steps as for the rank estimation. I built histogram from my list of probabilities, and I combined them with histogram composition. Same I need to do what I call a bound search, which basically is I have to find where to begin my enumeration and where to end it. It can be seen as counting the rank. And then I do the actual enumeration with the technical backtracking. I will explain it with a simple example of two subkeys with a 4-bit itch. So I first, on the top, compute the first phase, which is I build histograms. So I have 16 elements because I have a 4-bit subkeys. And I have the second phase, which is a combination. So I do the convolution between these two histograms, and I get H01 on the bottom. Then I have to do the bound search phase. Let's say, for example, I want to enumerate all the keys, which are ranked between 10 and 100. I have my histogram H01 on the right. And what I do, I have to count from the end of the histogram on the right up to the left, how many key do I have in the bin? For example, in the last, you have the number on top. So in the last bin, I have only one element. It's not 10. I continue on the left. In the bin before, I have five elements, 1 plus 5 equals 6. I'm not up to 10 yet, so I continue. Then I get the bin with 30 elements, 13 plus 6 equals 19. OK, I got my first bin. Then I continue up to 100. This gives me all these green zones. And I know that in these bins, all my rounded ranks are the keys between 10 and 100. But actually, again, I did some errors when building my histograms, and which was the number of convolution divided by 2. Here, I've done only one convolution because I only need two subkeys. So I have to add one bit on the left and on the right if I want to do the real ranks with no errors. OK, now the backtracking phase, which is the actual enumeration. I first do an example with only two subkeys. So again, I have my H01 on the top. And let's say I want to enumerate all the key which are in the bin 7. What I do is I go back to H0 and H1. And I try to find all the possible combination of non-empty bins, which are equal to 7. For example, if I take the two green bins for H0 and H1, I have non-empty bin for 2, non-empty bin for 5, 5 plus 2 equals 7. OK, it's a good combination that works. And I do this for all the possible bins. But in practice, I have more than two subkeys. So how do I do? I will do some kind of recurrence. In this example, I have four different subkeys. So on the right, I've done the first phase, which is the histogram building. So I got my H0, H1, H2, H3. Then I've done the covalent phase that we see on the left. So I first take H0, H1, I got H01. Then I took H2, I got H02, and I took H3, and I get H03. And let's say I hope to see well because it's very small. But if you want to look at the black bin in H03, it's a bin 16. And let's say I want to enumerate this bin. What I do is I look into H3, and I see, oh, my bin 5 is non-empty. And oh, the key, my bin 11 in H02 is unlucky as well. 11 plus 5 equals 16, that's a combination that works. So I take all the keys that are in the bin 5 of H3, and I store them. Then I'm left with H02 and the bin 11. So now I take H2. I see, for example, I have the bin 4, which is non-empty. And H01, I have the bin 7, which is not empty, for the 7 equal 11. OK, another combination that match. I take all the key in the bin 4 of H2, that's my possible candidate for K2, and I continue. And then I'm left with the example that I showed earlier with only two sub-keys. And here, for example, I take the bin 5 for H1 and bin 0 for H2, 5 plus 2 equals 7. OK, I got my key candidate for K0 and K1. And this gives me something like this, which we call a key factorization. In this example, I have two possible values for key 3, 3 for key 2, 2 for key 1, and 4 for key 0. And so it gives me four lists of respectively two and four elements. And this actually corresponds to 2 times 3 times 2 times 4 complete key candidates, which are shown here on the bottom to take all the possible combination of these four lists. This is what we call the de-factorized list. And of course, in terms of memory needs, more efficient to store the factorized list than the de-factorized one. OK, that's what the idea of how the algorithm is working. Now I will show some experimental results, not all of them. First, let's have a look on the accuracy, which is linked to the error bound. What I didn't mention on the construction phase of the histograms, of course, one parameter that you do need is how many bins do I use to compute my histograms. And this has a significant impact on how accurate I will be. So this graph on the Y coordinate are representing the number of key I need to enumerate to guarantee an enumeration up to an exact key rank given by the X coordinate. So for example, let's focus on the top left figure for 256 bins. We have the black curve, which is the curve X equals Y. Basically, it's just an optimal enumeration, like for example, with the algorithm of Rache-Arvigno et al. In blue, I have my algorithm enumeration sampled over 1,000 experiments. And this is the average bound that we got. In red, we have the extremum, that is the maximum bound we got and in green, the minimum one. First of all, what we can see is that the more bins I take, the more accurate I am. But also, what we can see is that when the key rank is small, like 0, 10, I have a huge gap between the optimality and my bounds. But when the key rank is high, this gap is getting lower and lower. Then we can also look at the speed. So in these graphs, I show the time in second it takes in the Y axis to enumerate up to the X axis. Again, in black, we have the enumeration optimal algorithm of Veritas. In red, we have our enumeration algorithm sampled over 1,000 experiments and the blue crosses are just a sample of these thousand experiments. And this time what we can see is that the more bin I get, the slower I am. And by the way, if you look at the graph on the bottom, anyone actually, I cannot use the algorithm of error at all more than at this point because I take too much memory. So I'm left with the question, should I take a lot of bins to maximize the accuracy or should I take a small number of bins to maximize the speed? And actually, it depends. So when you want to go to the key testing phase, like what a real attacker have to do, you will have to take the keys that are outputted by the enumeration algorithm and to test them on the block cipher to see if they are good or not. And actually it will be a trade-off between precision and your testing capabilities. Let's consider two different case. First of all, on the left, I assume that I'm a low-color hacker, let's say I'm in my garage and I want to attack the ID, electronic car of my neighbor for some reason, and I only have my laptop, so I'm limited in computing power. But on the right, we assume that we have a big organization, we have a huge computing power infrastructure. Okay, first on the left, what I will do is I will use my laptop to do both key enumeration and key testing. And what will actually happen is that I will have to do the key testing on the fly, which means I will have to de-factorize the list on the fly and test all these complete keys. And if I take a small number of bins, I will output too many keys at a time, I will output more keys than I can test them, so I will lose some accuracy for nothing. So in that case, I'm better maximizing the accuracy. However, in the case of a big company infrastructure, I can imagine like I have a software computer for the key enumeration part and I have like many hardware areas for the key testing phase in Poland. And in that case, there is two things that I want to do. Since I have a separate enumeration and separate key testing, I want to, first of all, to minimize the bank points needed for the communication between myself too and my hardware. And also, I want to use as many hardware areas as I can. So actually, I want to take a low number of bins. I will lose accuracy, but I want to test as many key as I can in Poland. And moreover, as we saw in the accuracy results, when the key rank is very high, I have a smaller gap between the optimality and the bound. Okay, so as a conclusion, we have developed yet another key enumeration algorithm with some cool features. We have very simple bounds. We have this key factorization, but actually we're not the only ones. The algorithm of Martin et al. also can do this. We have a very easy way to parallelize it, but I didn't have time to talk about it, so you should read the paper for more information about that. And we believe that it's pretty much simple to understand. It's just Instagram, convolution, and backtracking. You can find an open source code written in C++ of this algorithm along with the rank estimation algorithm which can be downloaded on this link. And if you want to try it, you should read the paper because there are actually more parameters that are not described here. Thank you for your attention.