 So, in the next talk, it's called Craft Lightweight Tweakwell Block Cipher with Efficient Protection against Folder Text. It's a paper by Christof Bayerle, Gregor Leander, Amir Mohadi and Sharam Rasouzadeh, and Sharam will give the talk. Thank you. In this talk, I'm going to present Craft, which is a new Black Lightweight Tweakwell Block Cipher, and it is designed to be efficient in protection against differential fault analysis attacks. In the last two decades, it is known that secrets stored or processed by implementation of an algorithm can be recovered using physical attacks. One of the important and most known such attacks is differential fault analysis, or briefly saying DFA attacks, that attacker tries to disturb the device during its operation. He computes output for the same input twice, one with and one without fault injection, and by comparing the output, he finds some information about the secrets value. The most simplest countermeasure to protect implementation is the application where in the implementation, the function is implemented twice, and by comparing the outputs, if they are equal, implementation gives the output, otherwise, it gives some random or null value. More complicated, countermeasures are concurrent error detections, which by adding some redundancy to the original implementation, it checks if the fault is injected or not. In a recent paper named Impeccable Circuits, we introduced a technique that guarantees detection of fault injections up to a certain number in any place of the implementation, and there we consider two adversary models that the attacker is able to make at most some number of injections in any place of the implementation, either in one clock cycle or every clock cycle, depending on the adversary model. To make it clear, in these models, SFA safe error or SACAT models are not covered, so SFA kind of attacks or SFA kind of attacks are not covered by this countermeasure, and they need some extra countermeasure to be protected. One important result from that paper was independence property that says to prevent fault propagation, the coordinate function of each operation has to be implemented independently. For example, considering the Skinny's mixed column, the implementation is shown in the picture that it needs three XOR gates, but if attacker injects fault in the second XOR gate that is shown by red, it will affect two output bits. In other meaning, by injecting one bit fault, attacker gains one more bit in the output. Using independence property to prevent fault propagation, we should implement in the bottom picture that it will need four XOR gates in a seat of three. On that paper, considering different size for redundancy, we examined our constructions for these six well-known lightweight black ciphers and found out that they are not efficiently designed for protection against differential fault analysis attacks. This was our motivation for designing craft that our first goal was to design a tweakable black cipher that in algorithmic level, it is efficient in protection against DFA attacks. We also wanted craft to be tweakable and also provides the decryption in the same structure for encryption with a small area overhead. Also, to have an easy security analysis, we decided to use already known design methods. To this reason, we chose a skinny-like structure with 128-bit key and 64-bit black and tweak size. What we designed is iteration of 31 rounds and it offends one linear round to the end. The round function can be shown as the picture in the bottom. It starts with linear operations and ends with nonlinear one. Also, the last round, which is linear one, doesn't add any security to the design, but as you see, it will help us in the decryption structure. In more detail, there are five operations in each round that all of them are involutions. It starts with mixed column that a binary matrix M is multiplied to each column and then round constants are absorbed to only fifth and fourth nibble of the state. Then round tweak is absorbed to all of the state and the last linear operation is nibble permutation. That permutation P changes the position of nibble in the state and ends with nonlinear operation, which is an expect layer that's applied to each nibble. The difference of the last round is that it doesn't include two last operations. It rates the round function 32 times, but in the last round it gives the output before permutation of nibble. About tweak schedule, we separate the key to its two halves and simply explore it with tweak key and this will give us the first two tweak keys. But for security reasons, we need to use tweak in another way, explore it with another way to keys and to provide other two tweak keys, we use a key permutation to change the nibbles of tweak and again, explore it with round keys and we will have these four tweak keys. And then depending on the reminder of round index to the fourth, one of these two keys are absorbed to the state. About design rationale, briefly saying from all the options that we had, we chose the ones that are efficient in the construction for concurrent error detections. Also, we wanted them to be involutions to provide decryption structure in the same structure for encryption with small modifications. So far, decryption with modifying tweak key and reversing order of round constants, decryption of craft is the same as its encryption. And that is because of these two equations that the first one says changing place of S-box operation and permutation of nibbles doesn't change the structure and also we can change the order of mix column at round constants and at tweak key with only modifying the tweak value. Then decryption equation can be which is the reverse of encryption and as all the operations are involutions, we can just reverse the, to reverse the encryption equation, we need to reverse the order of operations, which is shown in the second equation. And using two previously shown equations, we can change the position of S-box with permutation of nibbles, which is shown in that color, and also change the position of at tweak key with mix column by modifying the tweak value, tweak key value. Then we will reach to the third equation and considering with a question for encryption, it is same up to reversing order of round constants and modifying tweak key value. For the other round functions, we search exhaustively through all options that we had and we chose the ones that provides us the most security. Here I only talk about the way that we chose S-box and for the rest you can see the paper. Yeah. Each S-box in CED construction need to be implemented with a redundant S-box. For example, in case of forbidden redundancy, S-box S need to be implemented together with S4, which is defined with this equation and F4 is multiplication with the shown matrix. And this matrix is part of generator matrix for extended Hamming code which is able to detect up to three bit fault injections. But there is a problem if we search through all S-boxes. That is, there are about 46 million involuntary S-boxes. Implementing and synthesizing them are not possible. What we did is taking benefit of independence property which says each coordinate function of S-box must be implemented separately. That means implementation cost for S-box and redundant S-box is sum of area size for each coordinate function. And in all of the cases that we considered for redundancy size, only 13 Boolean functions were important for each S-box. So if we have implementation for all of the balanced Boolean functions, we can say evaluate the cost for implementation of S-box in our constructions. And there are around 13,000 for the balanced Boolean functions and this number up to bit fermentation equivalence is only 730 balanced Boolean functions. And what we did is to implement and synthesize these 730 balanced Boolean functions which took around half a day and extended to all of the 13,000 balanced Boolean functions. Then for each S-box we just need to do certain lookup tables and say what is the cost implementation for this S-box. Searching through all of the S-boxes, we decided to use the chosen one which is also the S-box for Midori. And it is not only the smallest one, also it provides the minimum possible uniformity and linearity. About tweaky schedule, for key schedule there were two options for us. The first one was round key updating and the next was round key alternating. That the first one needs at least 128 registers in round base implementation. But the other one needs only 64 multiplexers. To be lightweight in implementation we decided to use the second one. And about the tweaky schedule, we decided to simply explore it with the key. But if we use only two first tweakys that would cause time data memory tradeup attacks in the related key model. And to prevent it we need to use queue permutation to change the tweak in the rounds that has the same round keys. To provide maximum possible security against time data memory tradeup attacks, this queue must be a circular one. And there are around two to the 40 such permutations. But checking for all of these two to the 40, the security provided by these two to the 40 permutations are not possible. And what we did is to choose around 1000s of them and evaluate the security provided by them. And the current one that we already chose is the one has most active spaxes in related tweak model. Related tweak differential attack. When designing finished we checked the security provided by our design. We evaluate security of craft against the attacks that was the most vulnerable ones to the similar design block ciphers. We listed the attacks that we already analysed against craft. And I ask you to see the paper if you are interested. And the security that we are claiming is that craft provides 124 bit security in related tweak model. And to emphasize it we don't claim anything about chosen key, known key or related key models. The most promising attack is an accelerated excessive search that is because of related key property of tweaky schedule. And it says that if difference delta is such that all the values enables are the same, then queue permutation of delta will not change its value. Then using either k0, k1 tweak or k0 plus delta, k1 plus delta, both will give same tweakies. And attacker using this property by asking to encryption of the same plain text under 16 different tweaks, he can find the master key with two to the 124 computations. After analysing it, we compared our design with six block ciphers that already examined in Peckville circuit's paper. And also we had some extra block ciphers that the viewers asked. We again implemented and I didn't bring them all here. I just bring iskini, which we found it more reasonable. And by iskini I mean iskini with 64 block size but 128 key and also 122 which supports tweak. In all case, for each set of five bars, the smallest one is the unprotected version and then the red one is with one bit and increasingly up to four bit redundancy. As you see, in all cases, craft is smaller than iskini and also when it supports tweak, it is again smaller than iskini 192. To conclude this talk, we designed craft which is a lightweight block cipher that is efficiently designed for protection against differential fault analysis attacks. And as far as we know, it is the smallest block cipher with 128 bit key in the round based implementation. And just with some overhead, it supports 64 bit tweak and also supports decryption in the same structure for encryption. And it has 124 bit security and related key model. That was the end of my talk and I would be happy to answer your questions. Any questions? There is a question. I have a general question. Which application, what is the motivation of designing tweakable lightweight block cipher? So for tweakable block cipher, for example, it can be used in encrypting memories because we can consider the address of the memory as tweak. But in lightweight setting in construct devices, do you have any application for using tweakable block cipher? For this, I'm not that much expert to say what is the reason to have tweakable block cipher but let's say we don't need to change the key most often. And not only in the, also lightweight block ciphers need to be tweakable because like in RFID implementations, you don't need to have, you don't need to change the key most often that it was not, if it was not tweakable. I'm not sure if I could answer. Any other question? Okay. You said your cipher is easy to break against fault attacks. So the obvious question would be do you did some practical evaluation in the end as well? Or how do you verify that indeed you get this security against forfeit faults or whatever? Having the chip and implement some, inject some faults into it. No, we didn't try it but it is in plan because implementing the chip is time consuming. We have this in plan but what we did is we write some simulations and we checked it and it was able to detect the claimed, the guaranteed number of bits in the implementation. Okay. And the fault model was that you can skip some instructions like the X or as you showed in the example or can you do more than that? Sorry again. So in the fault model you assume that you can skip some instructions or fault a particular gate or can they, they can do more than that? Like cutting wires or stuff like that. Attacker is able to implement fault in every place of implementation by, by use of differential fault analysis. Not like cipher kind of attacks. Okay. Thank you. Maybe I can answer later. So you still have a question? So can you comment how you generate around the constants? Yeah. It was 40 pages. The paper was 40 pages. We used two LFSRs, one 4-bit and one 3-bit. Yeah. Yeah. And we add them to only 4th and 5th nibbles. We checked security against nonlinear invariant. Other questions? Okay. If there are no questions let's thank the Shaham and the other speakers again. And I think that concludes today. Okay. Then I hope to see all of you tomorrow morning.