 So good afternoon, everybody. First, I would like to thank Vincent and Yuval and their PC for this very nice invitation. I'm going to talk about cryptographic implementations, meaning sectional attacks and leakage resilience mostly. And beforehand, I would like to give a few words of introduction about the first part of my title and this idea of open approach to secure implementations. So the general background is this idea that transparency can be viewed as a measure of maturity. And if you think about block ciphers and symmetric encryption, I would say in 2019. And if you need to do symmetric encryption in a vast majority of the case, the right thing to do is to use a standard like DAS and to use a mode of operation for which we have proofs and good analyzers. And probably not anymore, unless exceptions, but to appropriate our ciphers. I believe the reason for that is that we have reached a good level of understanding of what symmetric cryptography and symmetric encryption actually is. And roughly, there have been three ingredients that have pushed this understanding. One is cryptanalysis, which is starting in the early 90s with these nice results on linear and differential cryptanalysis and all the follow-ups. Next designs, like new block ciphers designs, starting with a duck and then more and more formal. And finally, and especially when it comes to modes of operations, definitions, and proofs. What I would like to argue today is that regarding cryptographic implementations, we are more or less reaching this level of understanding. And of course, if you go back 30 years in the past, like in 1998, when Paul Kautcher published his DPA paper, I think at that time, trying to have a practically secure implementation by making all the implementation details public was pretty much impossible. But 30 years have passed, so we now have a lot of results about the same ingredients, cryptanalysis, designs, other contra-mojures, leakage resilience, and so on. And we also start to have definitions and proofs that we can use in this setting. So my view and what I would like to argue is that at this stage, security is more a problem than a part of the solution. And in a foreseeable future, we should be able to design practically secure implementations with all implementation details released. And I think we can even hope that this implementation will be more efficient than the ones that we can reach in a black box setting. So for this, of course, it will be a more technical talk. I would like to browse a little bit of these different ingredients, so cryptanalysis, designs, definitions, and proofs. Since it's a topic that is multidisciplinary, I would also like to speak a little bit about the practical aspects and the more theoretical aspects. So the first two parts will be more grounded to practice. Definitions and designs will be more related to theory. And I hope that I can make good connections between these different parts of the field. Before to start, I think it's a good time to say thank you to a lot of people. So these are just co-authors who helped me to understand many things in this leakage field. And I obviously forgot many people who are not co-authors. And it's also a good time to say a few words, of course, and really note, it's a topic that is really spanning many areas. So in some sense, it's nice because it allows you to discuss many different questions. It can also be frustrating because it's hard to have the perfect level of formalism for all the different parts of the talk here. So next, I'm going to mix very different abstraction levels. I hope I will do that in a more or less consistent manner. And be forgiving if I'm not. So let's start with the technical part. So the first thing I would like to discuss a little bit is what are these situational attacks at a very high level and what are the challenges that they raise. And introduce a kind of attack taxonomy that we can use in order to extract intuitions that are useful in cryptography. So this is a representation of the DAS finder, yes, which I assume everybody knows. So we see the 10 rounds. And the gray scale is showing more or less how easy or how difficult it is to exploit any information that you can have on the intermediate values. So of course, if you're close to the plain text or close to the cipher text, it's gray scale, much easier to exploit. If you are in the middle, then the cipher starts to behave more like a random permutation. And it's more difficult to exploit. What is the problem with leakage? The main problem is that this AES, we are not going to implement that as one single access in a huge table. In fact, we are going to use a device with limited computing abilities, and we need to perform the AES in many, many clock cycles. And that means if you do a power consumption measurement, like I represent here, you will see information related to the 10 rounds. And typically, if an adversary has information at this stage of the cipher, he can use this information, even if it's not perfect, maybe it's noisy, and so on, to attack the AES exactly where it's extremely weak in the light gray part of the cipher. And that's the main problem that we face. So what are leakages? Leakages, in the first place, they are vectors. And they are vectors made of many, many samples. I would say you have between 1,000 and 1 million samples in a leakage vector. The second point is there are noisy functions. So a simple model is to say that the leakage depends on the deterministic part, which depends itself on the plaintext x and the key k, and a noise vector n. And very frequently in the literature, what we do to measure the amount of noise is to measure a kind of signal to noise ratio which can be viewed as the ratio between the variance of the deterministic part divided by the variance of the noise part. And I would say most importantly, the shape of this delta nn is completely unknown. It's technology dependent. It's even device dependent. So we can measure them, but we don't have a nice analytical formula for these functions. And that means, in particular, we cannot say that these leakages are in some complexity class, as would be very convenient. We have no clue what it could be. Based on this, I would like to state three facts that are, I believe, important. The first one is very natural and simple, but quite important. It's that computing less means leaking less. And I will give this example in imaging that you have a 32-bit device, like an ARM Cortex 32 thing. And for simplicity, we assume that every intermediate value is going to leak the humming weight of the intermediate value. In this case, the AES has 10 rounds. Let's say the software implementation has more or less 100 operations per round. We measure five samples per operation with the oscilloscope, with the measurement apparatus. Every 32-bit value will give me five bits of information. That's kind of related to the humming weight leakage model. And that means if we ignore the denominator, so if we ignore the noise at the moment in total, the amount of information that I have in one trace is more or less 25,000 bits of exploitable information, which is much, much more than the key size. If we compute less, so first, what does it mean to compute less? It means that we use a larger implementation. For example, we use a hardware implementation where we manipulate all 128 bits in parallel. In this case, we could have one operation that does the AES round in one cycle. So we have still 10 rounds, one operation per round. Let's say I measure five samples per operation as before. Every sample gives me log of 128, because I this time see 128-bit humming rates. And that gives me, without the noise, 350 bits. So it's much less. We see that computing less helps. But it's still more than the key. And this has big consequences for theoretical analysis, because in particular, it means that if you have a game where you give the adversary the ability to compare the leakage of two identical device states, this is going to be trivial to win. And the example that I would like to give is this one. So we pick up a key at random. We pick up a bit at random. The adversary can choose two plaintext, x0, x1. He receives the leakage trace of xb. And this adversary can use this offline keyed leakage or wrackle, so he can produce leakage trace corresponding to whatever he wants and the correct key. In this case, to win the game, what the adversary does is just compare the leakage of xb, which the leakage of x0 and the leakage of x1 that he can produce. And because of what I just said, you have so many bits of information, this is something that will be won with probability 1. In the following, that's what I will denote as a state comparison attack. And I give it the red color, because I assume these are attacks that we cannot prevent. It's impossible to solve that problem. And if I anticipate a little bit the rest of the talk, of course, that means that anytime we will plan a distinguishing game without anything that is fresh and secret in the challenge, we will be in trouble. So that's a kind of negative fact. A more positive fact is that it's not always that we face these very difficult attacks. For example, something that is very well studied in the literature is key recovery. And in the case of key recovery, it's not trivial for the adversary to exploit all the leakage samples in the implementation. And that's exactly because of the great scale of my first AES figure. The leakage samples at the beginning and at the end we can easily exploit that. The leakage samples in the middle, maybe it's much less easy. And as a result, many times in practice, we don't use the full total amount of exploitable bits. We use a number of effective bits, lambda. And to give you one, I think, reasonably relevant example, we could imagine that we exploit the leakage samples in the first round. So only one round this time, two independent samples for operation. Let's put a decent noise value here. And I end up with 0.14 here. And I think the details are not important. What it means is that essentially, you will recover one byte in 1,000 of measurements. And that's, I think, more or less what you will face in practice. So this is already harder. And the good news is we can even make it very hard, because we have something called masking that I will detail next. And masking will have the impact that we can raise this 0.14 to something very big, so making the amount of information very small. This, by the way, is a 128-bit example. I think if we were trying to do that for a 32-bit device, that would be much harder. And I think trying to secure an 8-bit device is more or less impossible. Last fact, and that is important, all these attacks, they are continuous attacks. And that means we call them q-air bounded. That means that an adversary can measure for q different message blocks per key. And each measurement can be repeated air times. And as a result, the typical probability of success will have this shape. So this is the probability of success of the key recovery adversary. What's important is the power of 2 here. It's 2 to the minus 128 plus q lambda. And that really shows that every time you measure a new plaintext, you reduce the security exponentially, which is why these attacks are so devastating. In the chess literature, you will have a kind of jargon that you will see frequently, so we'll sometimes use it. We call SPA, an attack where q is a small constant. And SPA stands for Simple Power Analysis. Typically, this is because we do ranking. And we call DPA, so DPA stands for Differential Power Analysis, an attack where q can be large and is chosen by the adversary. And finally, this lambda, the number of bits that you exploit in one leakage trace, it depends on air, the number of repetitions. That would be pointless in a black box cryptanalysis setting, because then there's no noise. But in a physical setting, you have physical noise. The measurements, if you repeat them, it's not always the same. And it can allow you to improve the SNR. So based on these three facts, what I would like to propose is this taxonomy of attack that I will use a lot in the following. On the top, we have key recovery attacks. And these are the attacks that can be made quite difficult to succeed. I will use the blue color code when it's a DPA. So in this case, the adversary may require a large amount of measurements to succeed. I will use the green color code when it's an SPA. And in this case, we can even hope that the adversary will have a bounded probability of success. So that's the top, these attacks that can be difficult. At the bottom, we have the state comparison attack, where the adversary has the key to wrackle. This I already said, I will assume it's game over. It's impossible to prevent. And what's interesting is the middle point, what I will denote as message comparison attacks. So the goal of message comparison attack and state comparison attacks is exactly the same. So I have to distinguish the plaintext. The only difference is that here, the adversary doesn't have a key to wrackle. He can measure the device, but not for the correct key. And as a result, this trivial attack where you just compare the full state is not possible anymore. What the adversary can still do is try to compare the messages. And that means, first, it's in between, right? It's significantly simpler to win this game than to perform key recovery, but significantly harder than the state comparison attack. And the probability of success depends on the similarity between the messages that you manipulate, meaning that for some messages it will be trivial to win and for some messages it can be difficult. So that's, I would say, a very brief state of the art of how the attacks look like. When the attacks appeared, the first thing that people wanted to do is to prevent the DPA thing, so prevent key recovery. And I guess, I think the main ingredient we have to face this today is the masking countermeasure. So I will spend a little bit of time describing masking and what it means in terms of security and in terms of cost. So maybe before to start, I have to tell you why we need masking and why it's not enough that we have asked hardware designers to tweak a little bit the hardware and prevent the attacks. So the reason is, I will need to say a little bit, so I will not say much about how the attacks proceed. The only thing that I'm going to say is all these attacks, they proceed by distinguishing key distribution. So here, I want to recover one bit, why? If the y is zero, you have the left distribution. If y is one, you have the right distribution. And that's a very simple case, right? In one single sample, you can probably tell if you're in the zero or the one case. What happens if we add noise? It helps, of course, right? We are going to flatten the distribution. So in this case, we start to be a little bit confused. If we add a lot of noise, maybe we can make the attack reasonably difficult. The problem that we face is that the way noise is managed at the moment is essentially additive. So that means that if you double the noise, you double the security, but you also double the cost of your implementation, which from a cryptographic point of view is not what we want in general, right? We would like to something that scales much better. And I believe this type of observation holds for more or less all the hardware level countermeasures. I'm not meaning at all that they are useless. In fact, I will insist again next that noise is super important and that any kind of hardware that can improve the SNR is strictly needed. But I believe it's never going to be enough if we want to have security in the cryptographic sense. So how do we solve the problem? Essentially, we are masking. So masking can be viewed as noise amplification. So what we are going to do is essentially we don't manipulate Y anymore in the device. We are going to manipulate shares of Y. So we split Y in the different shares. D minus one are picked up at random. The last one is computed to be correct. And masking has first been analyzed in the abstract probing model. So this is a paper by Ishae, Sahai, and Wagner, which is very convenient and very nice to analyze all the masking schemes. And in this case, what we have as a model is the adversary can directly probe the values. If he sees D minus one probes, it doesn't reveal anything about the secret. If he sees all the D probes, then we have the secret in full. And so that is still a very convenient model. The problem is it's not exactly what we want at the hardware level, at least when we speak about differential power analysis, because in this case, we rather want something that was formalized by proof and revenge as noisy leakage security. And it's a setup where we assume that all the shares are manipulated by the device, and we will see the leakage of all the shares in the leakage trace. And formally, what this means or what we hope is that we can bond the mutual information between the secret that we want to recover and the full leakage vector by the mutual information between one share and the corresponding part of the leakage samples, raised to a power D, and that's where exponential security is expected. As such, a thing for quite a long time, at least for me, it was not clear how these two abstractions can be connected, because in the probing model, you exclude something from the adversary's view, while in the noisy leakage model, you give everything to the adversary in a noisy fashion. And there's a very nice and beautiful result by Duke, Jemvowski and Faust, five years ago, who showed that actually probing security implies noisy leakage security. Under two conditions, first noise, so this I explained already, so noise is important, we need the leakage samples to be noisy, and independence, which is tricky. And essentially, we assume that when we manipulate a share here, these leakage samples depend on only one share. And that's a great result because now we have this situation that we can use the very convenient probing model, and we know that this is going to have practical impact if we want to prevent DPA, so this is really great. I'd like to say a few words about performance and security. So performance, if you do MPC, it will be very simple for you. If you have to do linear operations on secret shared values, you just do it bit share by share. And for the multiplications, we are going to proceed in three steps. First, anyway, we represent the circuit as a sequence of additions and multiplications. And then the three steps are, this is an example with three shares. First, you do all the partial projects. Then you do a refreshing, meaning you add some fresh randomness that sums to zero, and finally you compress so that you don't explode the number of shares. We need refreshing because if we don't, then a single probe on C1, in this case, reveals something about B because C1 is essentially A1B1 plus A1B2 plus A1B3. That is A1B. If you work in GF2, it's an gate. And if you see a one, that tells you that B equals to one. I will not go into detail. So what's important here is essentially, you have quadratic overheads and randomness. And you have many, many published optimizations. I mentioned here the work of Reparath and Belayet at Eurocrypt, Gross and Mangato. You have a huge literature trying to improve that. That's for cost, for security. I'd like to say one word about why we can hope for exponential security increase. And I can again use this simple example where we want to distinguish distributions. So I still have a Y value, a bit value Y that I want to recover. It can be zero or one, zero on the left, one on the right. And this bit is encoded in two shares. So here it can be zero, zero or one, one. Here it can be one, zero or zero, one. Obviously, I guess you can directly see that you can distinguish the distribution. So the attack is still possible. The cool thing is if I ask you to compute the mean vector for this, you will see that the mean vector is 0.5, 0.5 in both cases. And that means contrary to previously, the unprotected case, if the attacker wants to exploit these leakages, it has to estimate a second-order statistical moment. If you go for three shares, the variance will become independent of the secret you will have to estimate a kurtosis, a skewness, I'm sorry, and its scales like this. And of course, if you combine this with noise, then you can feel where the exponential security comes from because you will have a noisy sample that you raise to a certain power and that gives you exponential security. This, by the way, is for the serial operation. If you imagine a parallel implementation where you manipulate the shares in parallel, it's all the same. What does it mean in practice? This is a case study that we did two years ago. So it's really experiments running on an arm cortex. The x-axis is the signal-to-noise ratio. The vertical line is the actual noise level that we measured in the experiments. The y-axis is the security level, measured as mutual information. I think the dark gray line is 128 bits of security. The light gray is 64 bits of security. And the blue curves corresponding to masking with 32, 16, and 8 shares. And what we see is that with 32 shares and the level of noise that we have, we can reach 128 bits of security. With 16, we reach 64 bits of security and that's it. So that's nice. We can reach very high security levels. It has a cost. So if you look in linear scale, you see that the cost is quadratic in the number of shares, as I mentioned before. So this is the cost measured as cycles per byte. What's very important is to plug in log scale because then you see that when you move from unprotected to two shares, there's a big gap, like nearly one order of magnitude. The reason is that there are many optimizations that you can do for the AES unprotected that are not possible anymore, at least at the moment when you mask, typically table-based and so on. The first reason is that most of the time to do masking, we have this circuit-based representation where everything is represented as additions and multiplications. Yeah, that's all I want to say for now. It sounds easy. I would like to insist it's really not. Implementation of all this is super complex. We'll give three examples very shortly. So first, you have the problem of independence. So physical defaults can completely ruin the independence. Problems have been shown, for example, by Mangard Pop and Gamel, solutions by Nikova Rehmann and Schlaffer. So it's a difficult problem, again, with many papers. You have the problem of horizontal attack, so that's very simple to explain. When you increase the number of shares, you have cost overhead, so you have more cycles. But remember, computing more means leaking more, so you need to compensate for that. And that means you need more noise or more randomness. This is beautifully showed by a paper by Battistello and co-authors. And finally, scalability and composition. So even if you work in the probing model, which is much nicer than working with noisy leakages, testing probing security exhaustively for a big circuit is very difficult. It scales exponentially, too. So either you use verification tools for that, but you're limited in orders, or you use stronger definitions with composability properties, and all this is initiated by papers by Gilbert and co-authors. So that could be another invited talk. I'm not going to discuss that because I want to discuss the impact for cryptography, but I would say the conclusion at this stage is high security against DPA we can reach. But on the one hand, it requires very big performance overheads. And in this respect, it's interesting because my understanding is that at the moment, industry will use typically between two and four shares. And my figure started with eight. So there's a gap. I assume it could be because they have performance constraints and therefore it really shows performance improvements could be very relevant in this field. And the other problem is it only protects the key, right? The plain text, they don't arrive in your device in a shared manner, so we need to deal with that, too. And by the way, SPA securities, of course, expected to be much cheaper to reach because then the adversary is much more limited. So that's what we have. We have attacks. We have some solutions that are very nicely analyzed for DPA. The next question or what I would like to discuss it, what does it mean for cryptography? And I will take the example of authenticated encryption which I believe is a relevant primitive to study nowadays. And to make things easier, we'll start with the non-respecting setting so the nonce is non-repeating. And in this context, I guess a good starting point could be Hager and Shrypton, all in one definition. So their definition for authenticated encryption asks the adversary to find out the difference between a real world and an ideal world. In the real world, the adversary can send encryption and the encryption queries to the algorithm. In the ideal world, the adversary can send the same queries to idealized objects that are either sending random ciphertext or bot in the case of decryption. And of course we ask the adversary not to do trivial things that can break the game. What's important here is if we try to add the leakage to this definition, this seems very challenging. I mean, on the left side, in the real world, it is easy because we have algorithms so we can build implementations and implementations define what is the leakage function. On the right side, it would require to define what is the leakage function of an idealized object for which I have no implementation. And that seems very difficult. So remember the background, the leakage function, the only way we know this function is via a concrete implementation, a real piece of silicon. So since idealized implementation, they don't have silicon implementations, that seems at least challenging. I'm not claiming it's impossible. But from there, we thought maybe it would be a nicer path to start with composite definitions of security where we separate requirements for integrity and requirements for confidentiality. And as I will show later, there are other good reasons for doing that. So this at least makes things a little bit simpler. This is ciphertext integrity. So in this game, the adversary can send encryption queries on the left, decryption queries on the right, and at some point we ask the adversary to produce a fresh ciphertext. If we want to add leakage, we can first add leakage only in encryption. That's what we call CIL-1 for ciphertext integrity with leakage in encryption only. We can also add the leakage in encryption and decryption. That's what we call CIL-2. And I would say these are natural extensions of the definitions. I don't see particular challenges and I believe there are many applications, but typically secure bootloading is a place where you really need something like that. CCA security is more tricky. So first, what is it in the black box world? In this case, we have an adversary who can access a wrackle. So we have encryption and decryption queries to the wrackle. And at some point in the game, there is what I will denote as the challenge query. That's the orange part here. So there is a fresh nonce. The adversary chooses two messages. He receives one of the ciphertext corresponding to one of the messages chosen by the wrackle and he has to tell whether it is the message M0 or M1 that was encrypted. If we want to add leakage to that, yeah, we can add the leakages, right? So we will add the blue leakages for the nonchallenge queries. And they are blue because in this case, it typically allows the adversary to do these DPA attacks. But we can also add, or I think we should, add these orange leakage encryption challenges which additionally allow the adversary to perform this message comparison attack. So remember, this is the attack that I put in the middle of my taxonomy. CCL1 is the CC security with leakage in encryption. CCL2 is CC security with leakage in encryption and decryption. And there's one further additional subtlety. And it is that in this case as well, we add the decryption leakage. So it may sound strange that you care about the decryption leakage if the adversary can actually decrypt. But there are applications where this could be useful, typically IP protection, right? You can have a game, you can decrypt and play the game but not make copies of the game. I assume key transportation could be another application. So the core, what is very challenging here and the main problem is this orange thing. And I would like to discuss that a little bit. So in the literature, of course, the starting point is the seminal paper by Mikhaili and Rezin. That was followed by Benny and like, it's now Hans-Segueff, Bakersky, Goldwasser. So in their definition, the observation is that indistinguishability with this challenge and encryption leakage is going to be very difficult. Why? Because if you leak one single bit of the message, you're doomed, you can win the game with probability one. So it is, of course, quite tempting to ignore that. And I would say it can make sense, right? And that's typically the difference between leakage resilience and leakage resistance. Leakage resilience is you can leak about the message and when you leak about the message, maybe you even leak everything. I mean, you have no guarantees there. But when it stops leaking, the system security recovers. You can still encrypt later on. In the case of leakage resistance, we care about this challenge encryption leakage and we want to prevent that or to face it. Why aren't we happy with just leakage resilience? I would say essentially because if you ignore the challenge leakage, that means an implementation that leaks the plain text in full is something perfectly acceptable. And I don't think this is what we want in theory. I also don't think it's good in practice. We know from all these works on TLS, like Kanvel and Vaudnet, Kenny Patterson and Quotors, that this message leakage can have very big impact. These are very different attacks, by the way, so I'm not claiming what we do has any relevance to what they do, but it's really something that I use as an argument to say, we cannot completely ignore this plain text leakage. Maybe the third point is, and I think it's quite important, if we don't make this part of the definition, it will never be a goal for anybody. Neither cryptographers nor cryptographic engineers. And that's a pity because we have things that we can do. If you're a cryptographer, you can try to minimize the message manipulation. If you're an engineer, you can try to minimize the plain text leakage. So not much is done on that, and that's clearly a nice open problem, but it could be done. Ultimately, I would say we need to understand what can be achieved anyway, so maybe the conclusion will be in the future that we have no negligible advantage here, so no nice security parameter, but these leakage, they sometimes happen, and that's probably important for our use of cryptography in the field. Less important, I think, our technical view is also a little bit more grayscale than Michaelien Rezin. So there's always this example, given that if you leak one boot, beat your doomed, which is correct, but it may not always be the case that you exactly leak one bit. Imagine you have a remote timing attack, then you have scalar leakages. It's not so clear that you have so much information. Imagine you have proxy re-encryption, then the messages are not chosen by the adversary and it's a slightly different setup, but imagine you have hamming weights, leakages, then a vast majority of the message will have exactly the same hamming weight, so they may actually be difficult to distinguish. So I'm just saying that's an open problem. I think much more work needs to be done, but I don't think it's an impossibility result that we have with these message comparison attacks. One motivating example is tree-based leakages in PRFs, analyzed in the leakage setting by Faust, Pietrek and Skipper. So in this case, we have a tree-based construction and at every stage, we encrypt either an old zero or an old one message. And this can be proven quite nice against key recovery, but it's very bad against message comparison attacks. So this is typically an example where we have a construction that looks good if you ignore this confidentiality issue and that's not so good if you want to take care about it. Okay, so that's what we have for definitions. We have ciphertext integrity with leakage in encryption, decryption, CCA security with leakage in encryption, one more question could be what happens if you have misuse and there are also interesting things happening there. So first, what is misuse, so non-misuse, by the way? This has been introduced by Hogaway and Shreemton and the idea is that when you take an authenticated encryption scheme, it's typically randomized or there's an IV or a nonce and you want to minimize, for example, in the non-setting, you want to minimize the impact of nonce repetition. How this is achieved is typically with a two-pass design where you first manipulate all the messages and then you do the encryption. That's the single IV construction. And in this case, only when you have exactly identical nonce messages, you should be able to detect something. In this case, you will see it's exactly the same message, but if you change one single bit of nonce or message, everything should look random to the adversary. The problem with leakage is that this is essentially impossible to achieve because just imagine that you have two messages here and they are made of four blocks. The first three blocks are the same, the last block is different. So this is what we have here. In this case, the first four block cipher executions, including the one of the nonce, will lead to exactly the same state. And that means in this case, we have exactly this state comparison attack that I mentioned at the beginning and where I explained that it's impossible to avoid, to trivially win the game. So we conclude from that message, misuse resistance is impossible. The good news is that a very small relaxation is possible and this is misuse resilience. Sorry, maybe I screwed up with the model also. The misuse resistance is impossible and the relaxation is misuse resilience. So in this case, sorry, the only difference is that the nonce has to be fresh in the challenge. So the scheme here starts with a fresh nonce and as a result, the adverse, we cannot do this state comparison again because everything is fresh and secret. He can still do DPA, so everything is in blue. He can still try message comparison attack. The messages are in orange, but there's no red attack anymore. So if I summarize, what do we have? I think what all this mainly suggests is that for confidentiality, no meaningful encryption scheme can satisfy in the same time leakage resilience, sorry, leakage resistance and nonce misuse resistance. If you exclude trivial implementations where everything is leak free. And as a result, you have natural combinations. The first one is misuse resilience with leakage resistance and that's what we call CCA small M big L that we introduced or you can go for the opposite, which is misuse resistance and leakage resilience that CCA big M small N introduced by Barwell and quotas. What I find interesting is that it shows that as a designer you have a choice to make. Either you have an application where you can say that the challenge leakage is not an issue, it's not going to happen and I can control this and okay, that's an option or you cannot do that and then it means that you will have to ask implementers to deal with the control of the nonce and to avoid nonce issues. In our setup, so the leakage resistance setup, the best definition would be a combination of CAML2, CCAML2 and misuse resistance a la Hoga-Wishampton and of course, many weaker variants could make sense. There's a lot of things to study here. We looked a little bit at CAML2 plus CCAML2 without the black box misuse. There's a recent paper by Dobranik and Menink looking at CPS security leakage resilience in encryption only for the duplicate sponge construction so many things can be done, I assume. Good, so we have definitions. We kind of know what seems feasible and what seems impossible. The last thing I would like to do is try to convince you that we can do something at the design level and that we gain something from all this. So my starting point for this section will be this leakage resilience map. So it's a very simple construction. You take the message, you hash it, and the hash value is sent to a block cipher and then you do the direct verification by comparing with the value. If you have this map, forgeries in the leakage setting can happen in two different ways. Either you do a DPA against the long-term key, that's the classical way, or you do a DPA against the tag verification because you can typically monitor the comparison with many random tags and in the end you will recover the correct tag. What's interesting is that for the rest, all the leakage on the dotted parts can be completely unbounded, we don't care. So first question is can we minimize the attack surface? Can we reduce what the adversary can do? And the answer is yes. So luckily there's a very nice and simple trick that we can do is just do the tag verification based on the inverse block cipher. Because if you do that, then suddenly all these verifications they take place with the public hash value so you can also leak in full about the comparison. And this I find very beneficial because in general, maybe I will not have too much time to speak about that, but finding good leakage assumption is something difficult. So it's good to know that for some parts, some additional parts of the design, you can be completely unbounded. That's a Mac, by the way. So how do we generalize this to an authenticated encryption scheme? The first thing I'm going to do is in your confidentiality with leakage. And I just want to build something that is CIML2, so ciphertext integrity with misuse and leakage in encryption and decryption. And I do that by adding a first encryption scheme here on the left, which can be any. The only trick is that this scheme is using a key K prime and it's not the same key as here. If you do that, actually everything can leak in full and then you hash the ciphertext and you use exactly the same Mac and you are going to have exactly what you want. And I think this is exactly where we see that these composite definitions can be very interesting in the leakage setting because it shows the weakest possible assumption may be very different if you want to do confidentiality or integrity. And typically, of course, confidentiality with unbounded leakage, this is not something that can work. So that's nice, we have CIML2. The next step is how to add confidentiality guarantees. And there we have two approaches typically. The first one is what I would call the engineering approach to CCL security. So we take any encryption scheme here at CBC and we will protect the block cipher against DPA. That's why they are all in blue. And also we have to take care about the message comparison. That's conceptually perfectly feasible. That's something that we can do. I explained in the second section that with masking we are able to do that. The only problem is that it will lead to very expensive implementations because the cost of masking is very high. So what's the alternative? It's to build a CCAML2 encryption scheme. And in this case, we don't take any encryption scheme here. We take typically a leakage-resonant stream cipher. And for this, the first proposal was by Jumboski and Piet Shack in 2008. And the idea there is you will have, you still need one block cipher where you protect the key very well so that this one has to be blue. With this block cipher, you generate a fresh key. But all the rest is based on a kind of raking mechanism. So this fresh key here will be used to encrypt twice, wants to generate another fresh key, want to generate the key scream and do the encryption. And as a result, this thing can be in green. So it can be only secure against SPA, I'm sorry. And as I argued, SPA can be much, much cheaper. So what can we do in terms of proofs and reductions? What we are able to do is different for integrity and confidentiality. So for integrity, we are able to reduce the security of a full-fledged scheme to the security of the two block ciphers against these DP attacks. And we are able to do that in this very nice unbounded leakage model where everything else is given to the adversary, which seems quite convenient. Formally, this block cipher, for the moment, we model it as leak-free, which means that's something feasible, but very expensive. So that means typically we want to reach 128 bits of security with masking. I think for integrity, we can reach graceful degradations in the sense that if you decrease the security, the DPA security of the block cipher, not everything is going to collapse. We still have the same level of security for the rest. For confidentiality, things are a little bit more tricky again. So what we do here is we reduce the security of a full-fledged scheme to both the DPA security of the two block ciphers and the security of one single iteration of the stream cipher. And that's the minimum thing to which we can do the reduction. Of course, we cannot do that in the unbounded leakage model, so we need additional assumptions. Again, I don't have time to detail them. The bottom line, I think, is we have no perfect assumptions, but good enough assumptions in the sense that breaking the assumption here is, in general, more difficult than breaking the final block to which we reduce. And the good news is that we can also do that for sponges, and it's going to be exactly the same. We require the sponge to have SPA security for the permutation and to protect the message here. So I would like to conclude with or to finish with an example of full-fledged scheme. This is SP1, so it's a scheme that is only one pass, so it can be online in encryption and decryption. It's CIML2, it's only CCAML1, so it's only ensure CCA security with leakage in encryption. The reason is that if we want to have a one pass design, we strictly need that. If we want to have CCAML2, essentially, you will need to have one first pass in decryption. How does it work? Essentially, we have two trickable block ciphers, one at the beginning, one at the end. At the beginning, the trickable block cipher is used to generate a fresh key. At the end, it is used to do the tag verification. So these two block ciphers are in blue. They have to be protected strongly against DPA, so very high order masking, typically. And the others, like the permutation, is in green, so it only requires security against SPA. And so this encourages what we call leveled implementations, which I believe are very handy. Leveled implementations are implementations where different parts of the design are not protected with the same level of security with respect to side-channel attacks. Again, for the TBC, high order masking will be needed. And for the weekly protected thing, essentially, what we can leverage is, again, the observation that computing less means leaking less. And so for this part, we will try to have an implementation of the permutation that is as fast as possible. If you do hardware, typically, you try to do that in one or two clock cycles. One remark is that when we go for these leveled implementations, it can sound annoying that we have two different primitives, a permutation and a TBC. It's not a problem in this case because the implementations are going to be very different anyway. And as a side note, this type of construction also has all sorts of black box security guarantees, so it's beyond birthday with respect to the TBC key, it has multi-user security with a public parameter and so on. So finally, what do we gain? That's maybe the most important slide. We gain a lot in performance. So this is, remember, that's a slide that I showed for the performance of masking. So the blue curve is what we would have for a uniform implementation where everything is masked with the same level. For example, if you use CBC. The green curve is the cost in cycles per byte for a 100 byte message here for our leveled implementation. So you see you gain something and the gain is plotted by this red curve that is given in function of the number of shares. So here we already gain a factor of 3.5. If we go for larger messages like one kilobyte message here, the gain, of course, increases a lot, right? Here we have a gain of a factor 24, 25 for a larger number of shares. So we really see that concretely we can gain a lot with this type of implementations. So it's time to conclude. The first thing is what we hoped we can achieve a little bit is a theory to guide practice. And in this respect, a criticism that we can make here is it looks like we have a big zoo of definition, right? Because you have to choose between leakage resilience and resistance. And these walls are very nasty to manipulate. These use resilience and resistance, leakage and encryption and decryption and for integrity and confidentiality. My view is kind of that this reflects the complexity of the physical world. So I don't see an escape directly for that, but maybe there is. What I think most important to see is that these are anyway not black and white notions. And I will give the example of CIML2. I showed in the talk that we can achieve CIML2 with in this nice unbounded leakage model if you do the inverse verification trick. But you could also say, okay, I don't want to do an inverse. And then you are going to protect the tag verification against DPA. That's perfectly fine. And that's another way to reach exactly the same thing. It just means different requirements for the hardware implementers. What is best here in this case, by the way, I have no clue. It has not been evaluated. So this is something to study. What's important is a thing and what is the hope is when you do this kind of analysis, whenever you have a strong assumption, it tells the hardware designer where they have to put their implementation efforts. The other thing is, I hope, I wanted to show that there remains many open problems in this field. So it's not completely solved. I think we have a lot of good ingredients, not perfect ones. And we also don't really know how to mix them yet. Even in theory, so simple questions include, we have many authenticated encryption schemes in the literature. Even more with the ongoing list competition, can we classify them based on these security definitions to see under which requirement we can reach which leakage we are guaranteed? We have some links that are not really understood but between different security notions. There's a problem of graceful degradations that I mentioned. There's a problem of proofs under weaker physical assumptions but very frustrating. I had another set of 15 slides to discuss that. It's a very technical topic but very, very important one. Maybe also application to signatures and PKE. So there's much more papers, by the way, on asymmetric crypto than in the symmetric setting. So, but maybe still something to do there. That's for theory. I would say in the middle we have Cypher designs. I mentioned the AES because everybody knows it. I don't think the AES is the easiest Cypher to mask. We can improve that. At some point, I also think if we had efficient geomorphic primitives, that would be really great because that would make the independence condition much easier to satisfy. Masking is a topic of its own. Couldn't discuss it much but physical defaults, composition, horizontal attacks. I mean we have a lot of things to do there and of course implementation. So improved confidentiality for these one block messages. Not much is done. Prototype open source implementations, right? Take these implementations, look how far we can go in a completely open manner, of course. And I guess in general, anything that leads to simple hardware design guidelines. And I want to finish the talk closing the loop with evaluation challenges. So this problem of transparency, I mentioned it that it's important for design. I think it's also important for evaluation. So the situation nowadays is you build a chip, you will send it to a lab. The lab will make experiments for one web quick. Let's say they take two to 30 measurements and then they will tell you whether it's broken or not. That's it. And by the way, there's something very important here is that all these assumptions, they are computed per device. So it's extremely different from black box crypto. In black box crypto, Diffy Elman is there everywhere. With leakage, whatever assumption you use, it has to be proven again for every device. And in this sense, the fact that we use diverse assumptions in leakage, I don't think it's a problem because the lab will have to repeat that anyway. The main thing is if you keep this model, then what happens when you're happy, right? The lab didn't find anything after two to 30 measurements. Does it mean that you have two to the 40 security? Does it mean that you have two to 80 security? Nobody knows. And with this type of approach, I don't think we can go much further. So also for that, I believe if you have open implementation where you release all the implementation details, then you can move to a model where you do evidence-based evaluations on reduced versions. And then you use the proofs and everything that we know to have proof-based evaluations for full versions. And maybe we can hope for tight bonds up to two to the 80 or one to 18 bit security. And with this, I conclude. Thank you. You have time for a few questions. If you have a question, please raise your hand. So thank you. Could you go back to slide 4.3? It's nothing serious. Don't worry, it's not a terrible attack. So you had been claiming that when you look at, when you ignore confidentiality, you still see which requirements you need. As much as I can see here, your requirement is that the whole thing is collision-resistant, the encryption followed by the hash function. If you don't ignore confidentiality, a weaker assumption, weak collision-resistant resistance would be okay because K prime can be assumed to be secret. And so it's actually that if you include confidentiality, you suddenly can come up with a much weaker assumption. We go assumption for what? Like if you, as part of the assumption that you need to prove the whole thing secure to have a security guarantee. Because then a collision on the edge. Like if you include confidentiality with leakage, everything is different. That's, and then we need much stronger guarantees and assumptions. Well, but for authenticity, you suddenly need a weaker assumption. We need weaker assumptions, but from the leakage viewpoints, you can leak everything, all the intermediate. But of course you need black box assumptions, right? I mean, this may be like the encryption scheme is still a good encryption scheme. The hash function is still a cryptographic hash function. Okay. Maybe a related question. So you mentioned the definition based on an ideal world. So would that, if we would have a definition like that, would that be a stronger definition in some sense than looking at integrity and confidentiality? Because I don't know in terms of composition or stuff like that. Yeah. I guess so in terms of like for generic composition results, these things, like it's extremely convenient if you ignore the leakage. The reason is we don't see how to model that. And then maybe that's just us who don't have the right tool for doing it. But yeah, of course, if you would have a relevant definition for that, it would be interesting. So you were mentioning there is this distance between what is done in the industry they are using like two shares and then academia, you would say it would be eight. So the question is like, what, okay. So if you would do it, if you have eight shares, it would be more difficult to ensure some other properties like I don't know the independence between them or other things. So if you can ensure better properties with two shares, then maybe it's better to use two shares rather than eight shares. So I mean, the number of shares impacts performance in the first place. This is something that maybe that's the limit. And does it impact the independence condition? I'm not so sure. So maybe to Stefan's question, I have two questions for the first, as quick maybe. So what you're saying that in theory, I think what he was saying that in theory, just for the magic thing, H doesn't need to be collision resistance. If I understand correctly, you're saying that if I actually put a non-cryptographic H, kid, not cryptographic H, it makes it actually much harder probably for this because now if the key leaks, it becomes, so you're kind of saying counterintuitively to proofs and from the leakage perspective, actually collision resistant implementation is probably better than kind of universal hash function or something. Yeah. If, okay. Thanks, thanks. I mean, the other question is that, yeah. Well, my interpretation, but that's a quick question. So in theory, we kind of started with bounded length leakage. And there was some papers about noisy leakage, which I guess happens to real life. Sometimes it's kind of painful to extend. But of course, you know, we left our papers. There was a lot of like cryptography papers, but in practice kind of few times, I tried to talk to practitioners. I mean, everybody couldn't understand what this kind of bounded leakage kind of means because in reality, it kind of never the case. So I guess two questions kind of as practitioner, do you view value? I mean, if you start from something which kind of doesn't hold in practice, I mean, how do we get guidance from you how to extend the models and related question with respect to noisy leakage? Even if you have things with noisy leakage, let's say we start right away with noisy leakage and get some kind of entropy bound or something. How do we tell practitioner, I mean, how do you set the parameter? Because the scheme will be less efficient depending on more noisy leakage or not. Are you confident that you can actually kind of tell us how to set parameters? So how do we deal with imperfections in the assumptions, right? I think that's like in any case when we put a block cipher in the mode, we hope that it's a PRP and here it was because it can be very distant, but we deal with it by hoping for the best. I mean, I'm saying I have a scheme which is less and less efficient given kind of leakage rate. What do you do? I mean, if I come to your scheme to sell it, I mean, do you feel like we can like team up with people in hardware and crypto? How do we set the parameters? What do we do? So that's the main point. That's your second question. I think we need to go for assumptions that can be falsified by engineers. And in this sense, yeah, bounded length from scratch, it's invalidated because you think I have 25,000 bits. I leak much more than the key size. So this one cannot be relevant in practice. It's still a good indication that the scheme has good properties, but it cannot help us at all to choose security parameters. We get much closer with the Helpsodor entropy and we worked a lot on this simulatability assumption. So, these are the slides, okay. So you can choose, right? Helpsodor entropy means there's a computational limit to the adversary, and we hope that there's a big set of keys that generate leakages that are hard to distinguish. So this is something I believe it can be more or less achieved, but very hard to quantify. The problem is then there are two things that you need to bound the leakage function both for the important information and the computation. So I guess we need to take that offline anyway. But yeah, this is better. Simulatability is in a sense even better because that's something you can ask engineers to break and it happened, right? Like there's a team, Jake Longo and others, they broke some instances and then we can try to improve that. These kind of games, I think we can really estimate what's the value of the epsilon and quantify the security parameters if we have tight bonds, of course. The best, by the way, would be, yeah, that's by you. All these hard to invert leakages, right? We have no clue how to use them in symmetric crypto, but that would be great. This we can really not only ensure but quantify if there's a way to prove these encryption schemes with these assumptions, that would be perfect. Last question over there. Thanks for the very inspiring talk. You spoke a lot about hardware, but leakage is also happening in software. So what happens there? Is all broken and too easy for you or is it much harder? I will humbly say I don't know enough about this. It's a fascinating topic. I'm sure there are interactions. I haven't read, I mean, I've seen talks on that I haven't read the papers. I hope that it can be, that crypto can help there too. But of course the more the attack becomes devastating, like sometimes they leak, they really have this unbounded leakage model, by the way. Maybe what we do for integrity can be relevant there. But for confidentiality, I have the upside. I just don't know, but it's a great topic. I should have put this in my list. Okay, let's thank the speaker again.