 So yeah, in this work with joint work with many people here, we are presenting a new family of lightweight 2KB block cipher that we call skinny. So the main goal of this work is to actually provide an alternative to the Simon block cipher which has been proposed by the NSA in 2013. And while personally I feel that this block cipher is very well conceived, there are some people in the community that are not so confident with this block cipher, mainly because the designers did not provide any security analysis at all when they published it. And so our goal here is to construct a lightweight primitive that is as good as Simon and at the same time provide all the security analysis and all the design choices that we've made along the way. So concretely what we want is to construct lightweight 2KB block cipher that is very lightweight, as lightweight as possible, which is very scalable in terms of to adapt the whole level of security that we want to reach and that can provide very efficient implementation both in software and in hardware. So to address all of this, we introduce what we call skinny, skinny family of lightweight 2KB block cipher. Internally, it generalizes the STK construction from the tricky paper that we have presented with Yvitsa Nikolits and Thomas Perrin at AGQ 2014. And the block size of skinny can either be 64 bits or 128 bits and the key and tweak sizes can either be one, twice, or three times the size of the block. So when we design skinny, we want it to be secure against differential and linear analysis in both single key and related key models. And at the same time, we want it to be very competitive in implementation for software and hardware. For example, if we look at the round base ASIC implementation of skinny 64, 128, so 64 bit block and 128 bit keys, we can get in implementation with typical conditions in slightly less than 1700 gates while the Simon block cipher is slightly above this. And for software, we also get competitive benchmarks on the latest Intel platforms. So a 2KB block cipher is a very interesting primitive for cryptographic application. I've listed a few here, but I'm sure there are many, many more. And in the past, in the literature, there are some construction to construct a 2KB block cipher, but most of them are actually generic. It's the sense that they start from a block cipher and construct the 2KB block cipher from it by injecting the tweak in some ways. And actually, there are very few add-on and direct construction of 2KB block cipher. Just a few here, for example, the Astipudding cipher, 3Fish, Mercy, and some part of Black2, there are some add-on construction. And in this paper in Asia 2014, we started with an observation that as a designer, it seems that the key and the tweak should be handled in the same way by the internal primitive. And what we call a tweaky schedule. Like a key schedule, but inside, we put actually the tweak as well. So just briefly, what is a tweaky framework? It's a way to bring together the design from the key and the tweak by extending what is very well known now as the key alternating strategy to design a primitive. So inside this tweaky framework, we have something that we call STK, which is a superposition tweaky that we actually use in the design of skinny. So what is that? It's a way to construct a key alternating cipher which is just the alternation between sub-key addition and roll function a few number of times. And then this STK is a way to describe the way to update the key schedule and the tweak schedule that can be represented like this. For example, this line could be the key, this line could be the tweak, and then both are updated independently at the same time, and we extract the contents of the register as sub-keys that are injected in the primitive. So with this construction, I will not go into all the details, but we can view this linear operation as a linear code and actually use that to bound the number of cancellations that can occur in the addition here to actually give bounds in terms of security in terms of number of activist boxes that we have in the cipher. So we can use these bounds to actually measure the security of the cipher. And we can inject that actually in some automatic tools to run some analysis and derive directly the bounds for these kinds of ciphers. So we use this in Skinny. And as a general design strategy for this line of construction in Skinny, we wanted to start with very weak crypto components that are very cheap in hardware and software to actually provide very efficient implementation. So if we think about it, it's very at the complete opposite direction from the design of the AES, where we start from a very strong SBOC, a very strong linear diffusion. But this allows us to have very few rounds, for example only 10 in the case of AES 128. And what we do, starting with very weak components, it's much closer to what the designer of Simon have done by picking only very small and cheap operation like end, go and rotation at the expense of putting much more rounds than the design to reach security. So we use this direction to construct Skinny. And at the same time, we want to reuse the strategy of the AES to build the round function because it's very well understood and we can actually use that to derive the number of activist boxes to get an estimation of the security. And in the end what we get is a cypher that's a very, very low number of operation. And I think if we remove any small N or XOR, then the cypher can be completely broken. So this is very challenging to do. And just to compare the briefies, the similarities and differences between Skinny and the AES, in terms of design, we also use a key alternating cypher. The internal state in Skinny is also a 4x4 matrix like in the AES. The round function is also SPN-like and AES-like, where for example the diffusion is also achieved by a combination of a shift-force and a mixed column. Then to assess, estimate the security, we count the number of activist boxes that we can get for, for example, for differential cryptanalysis, to derive bounds on how good is the security for Skinny, like in the AES. And we made the design resistance, again, linear and differential cryptanalysis. So now what is different between Skinny and the AES? We put more rounds because we start with weak operations, so we need more rounds. The key schedule is replaced by a linear 2-key schedule with keys and tweaks that are injected into the internal state. And a huge difference is that the matrix that we use is not MDS like in the case of the AES, but it has a binary matrix and it has only a branch number of two. So it's again a really weak diffusion matrix but we can still get some security. About security, we claim related key and related tweak security. And to measure the security of Skinny, it's actually much more difficult than in the case in the AES because the matrix is not MDS, so we cannot do the proof by hand to count the number of activist boxes in the case of single key security. So we have to rely on some tools by, for example, in our case, we model the system to assess the security in terms of MILP modeling. But with this MILP modeling, we can actually capture the security not only for single key, but actually for related key and related tweak, which is not that easy to do for the AES because the key schedule is not linear. So yeah. So just a brief overview of the specification of Skinny. So as I said before, we have internal state of either 64 bits or 128 bits, and the internal state is viewed as a 4x4 matrix, so then each cell is either 4 bits or 8 bits to get these values. The tweak key can be either N2N or 3N if N is the block size. And for example, to get the number of rounds, if we look at the 64-bit block size and 128-bit tweak key size, we put 36 rounds. If we compare this to Simon, they put 44 rounds. So roughly four times the number of rounds that we have to put in the AES. And this is because we start with very weak components in comparison to the AES. So now the round function, it's again really similar to the AES-like SPN function. So we have an S-box that we apply to every 16 cells. Then we put some constants, and then we inject the key, sub-keys into the internal state, but not into the full state, but just into half the state. So this allows us to gain, again, some gates in hardware. Then just shift rows. We rotate exactly in the AES, but in the other direction. And then the matrix is the same kind. We multiply the state by a matrix, but in our case, the matrix is binary. So just to come back to every possible component, for example, this 4-bit S-box, this is the one that we use in skinny. It's almost a piccolo S-box. In the piccolo, we have a notch here. Here it's really similar, and this one is actually very, very good in hardware. We can implement it in just 12 gates. Then the cryptographic properties is kind of typical. For example, maximal differential probability to the minus 2. It's really what we can see in the 4-bit S-box. What's different is the 8-bit S-box that we use in skinny, in the big version of skinny. We actually reuse the structure of the 4-bit S-box to construct this one. So we just double the input size and we apply exactly the same kind of operation. So it's very cheap. It's twice the size of the previous one, so only 24 gates. But we need to pay something here. So the thing is the cryptographic properties are much weaker for this S-box than it is for the previous one. For example, the maximum differential probability is exactly the same as the 4-bit S-box. We have to pay something more here to reach some security, but it's cheap. So the round constants, it's, again, very cheaply produced. So we use an LFSR, which is clocked every time we want to produce some constants. It costs in hardware only one gate to put this one here every time. So then we extract the bit from the LFSR and we just inject the round constants and form them like that. Okay, then the Twiki schedule now, so we reuse the SDK construction that I presented before. Here just one main difference is that when we want to update a Twiki state, for example, one line here, it's an internal state like the internal state of the main block here. But we extract only two lines of the states, which are injected in the internal state. And then every word of this Twiki state is updated by an internal permutation, which is linear, and we independently update every word of the Twiki state. And then half of the cells in each word are updated by an LFSR, which is very cheap in hardware because every LFSR can be implemented with just one XOR. Okay, so finally the mixed column. The mixed column is, again, it's a matrix multiplication like in the AS, but in our case, the matrix is binary, we are using this matrix. It has a bunch number only two. And we pick this one because it can be implemented with only three XORs. So again, it's very cheap to implement that. We do not do any field multiplication or which would need some shifts, for example. Okay, so just to describe a bit the design choices that we've made. So informally what we want to have is a low number of operations as low as possible, while at the same time retaining some security and maximizing the security of the cipher. So we have introduced some new components which have been selected sequentially. So first we started to select the S-boxes, then we pick the linear layer, the shift was a mixed column, and then we pick the tweaky permutation that is in the tweaky schedule. So to estimate all the possible choices that we could make, for example, for the S-box, we have two criteria. First criteria is the security. How many S-boxes can we activate with that choice? So we have to run some estimation using MILP to rank all the possible choices that we could make. And at the same time, we want to optimize for hardware and software efficiency for implementation. So we have to rely on some estimation for every possible operation. So we use classical costs for every gate, for example, a NAND gate with cost one and an XOR with cost 2.6. So this way we can measure how cheap is it to make this choice or that choice during the design, the choices, for example, for the S-box. So in particular for the S-box, what we did to pick this one is to run a search tool which tried to incrementally add some instruction to construct some permutation, and we stopped adding some instruction once we reached some cryptographic properties that we want. For example, the maximum differential probability, we wanted to be that value, so we stopped until we reached that criteria. So the first S-box permutation that we found on 4-bit was this one which is actually very close to the piccolo S-box and can be implemented in 12 gates. So for the 8-bit S-box, we could not do this because the search space is too big. What we did is simply reuse this structure, double the size, so that the strategy is very similar. We could not perform the search for that, so we just reuse this structure. Then for the metrics, we did something kind of similar. We want to optimize for two criteria. The first criteria is implementation, so we want the metrics, we impose it to be binary for implementation reasons because we want it to be very cheap. And we restrict the search space to invertible metrics, of course, but at most it has to use at most reexor and not more. And then for security, we want the full diffusion to be reached after a reasonable number of rounds, so we fixed a maximum number of six rounds. And then because we are injecting the sub-keys in only half the states, we want that each sub-key byte that we inject affects every possible byte after just one round backwards and forwards. So this restricts a lot of number of possible metrics. And in the end, with those two criteria, we have only 24 matrices to check. So we pick the one that maximizes the number of activist boxes, and this is this matrix that we chose. And then for the tricky schedule, again, we have these two criteria. For the security, we wanted to follow the STK construction, so this comes at some constraints. For example, in the LFSR, they have to maximize some cycles. And we want every byte that are injecting into the states to be used every two rounds. So every two rounds, all the bytes should be used, otherwise it would have been a weakness in the cipher somewhere. And then for implementation, we want to save a lot of gates in the implementation to only explore half the states, so only two lines. And the LFSR to be very cheap. So in the end, there are much more candidates than the matrix. And we checked all these 30,000 possibilities by ranking again using MILP and we pick that permutation to be used in the tricky schedule. So with all these choices now, we have the design fixed. We can measure and compare how good the design will perform in both software and hardware by counting all the possible, all the operation used inside the cipher to transform the plaintext to the ciphertext per bit of the primitive. So for example, in this variant of skinny64.128, we need roughly 140 operations per bit to transform the plaintext to the ciphertext. So we can compare that to other cipher and we see that actually a very low number of operations are used. And we can also use this estimation by affecting costs to every possible operation. So for example, an exo would cost 2.6 to get an estimation on the area for run-based implementation of the cipher. And this gives some metrics to compare to other ciphers. So I will not describe every number here. I do not have the time for that, but I think this table is very interesting and says a lot about the ciphers. So security analysis, unfortunately, I will not have time to describe everything that we have done in the paper. So you can see the full paper. We have considered many, many non-classes of attacks from different shell to integrate it and again we claim related key and related quick security. I'm sorry, I did not have time to describe everything. It's in the paper. So just a few words about the implementations. We have conducted many different implementations from a run-based, free-enrolled, serial and threshold implementation. Also we have some software. And I will just say a few words for run-based implementation which has been the main objective for minimization for us and it's a very good trade-off between area and throughput for the implementation. So just a few words about this. So here is a result for the implementation that we have made. So here you can see the... So this should be 64, 64, 64. For example, the skinny 64, 128 variant, we can implement it, as I said before, in slightly less than 1700 gates. And if we compare to Simon, okay, no, it's not, it should be 128 there. So if we compare to Simon, it's slightly less, but it's kind of the same range. We are roughly using the minimal number of operations and we can compare the throughput for these two implementations and we are roughly, yeah, in the same range. So just to conclude, we have presented a new lightweight family of 2K block cipher. It's almost as light as possible. I'm not aware we tried a lot to decrease more the number of operations, but we have not succeeded in doing that without degrading the security too much. So this cipher provides an alternative to the NSA-designed Simon family of block cipher. It provides very efficient implementation because it's using so many, so much, so few number of operations. And we claim some single key related security. So what is in the full version of the paper? Much more. We have just give some highlights by the design choices that we've made for this, but we give every choices, every possible variance that could have been made. The full security analysis is given. We give all the possible implementation from bit serial, label serial, low latency, which is also interesting threshold. I will also consider FPGA microcontroller and software. And finally, what I did not have time to present today is a variant of this 2K block cipher in a low latency fashion that we call Mantis, which is very similar to prints, but additionally it has a tweak input that can be used for memory encryption, for example, which is an interesting problem as well. So finally, we have set up a website where we put the full version specification and eventually we might put some updates of the cipher and I invite you to go look it online. And that's it. Thank you. Thank you.