 Hello everyone, my name is Christoph Beierlder and I am going to present Skinny AAD and Skinny Hash, which was a submission to the NIST lightweight cryptography standardization process and also published in the TOSC special issue. And this is joint work with the Skinny team. First of all, let me give an overview of the AAD scheme. So, AAD stands for Authenticated Encryption with Associated Data. And this picture here shows what is the idea. So the scheme gets a fixed key k and a nonce n, which should be varied for each encryption. And the input will be a message and associated data. And then the scheme outputs a ciphertext and some authentication tag. And for the message, we want to guarantee confidentiality and integrity for the associated data. We only want to guarantee integrity. Usually this is public data, for example, some header. And if the tag will be invalid for a given ciphertext, a decryption oracle would output an error. So you're not able to decrypt unless the tag is valid. Our scheme called Skinny AAD is a tweakable block cipher-based authenticated encryption which associated data, which employs the well-known Skinny tweakable block cipher from crypto 2016 in a Tata CB3 framework, which is the tweakable version of the OCB framework. And this was introduced in 2011. And our particular instance is very similar to deoxys one, which is a third round candidate of the Caesar competition. Our primary member is based on Skinny 128-384 and it gets a 128-bit key, 128-bit nonce, outputs a 128-bit tag and allows to process a message of up to 2 to the 68 bytes. Our hashing scheme called Skinny Hash is a function-based sponge construction and the primary member uses a 384-bit to 384-bit function built from this tweakable cipher Skinny 128-384. So compared to usual sponge constructions, the underlying, we don't use an underlying permutation, but a function. Our features are as follows. Skinny is a well-understood design that since its publication already received lots of external cryptanalysis. For instance, we found more than 30 published papers since 2016. And we use this cipher in a modular approach, which means we're using a well-known mode of operation. We use the Tata CB3 framework for AAD and the sponge framework for hashing together with the cipher. And these modes are provable secure, assuming that the underlying cipher is ideal. And in particular, by assuming AAD to be an ideal tweakable block cipher, we would obtain beyond-birthday bound security for the AAD scheme. Another advantage of this AAD scheme is that it is highly paradisable because it operates with independent calls to the tweakable cipher. Moreover, the Skinny cipher allows for efficient threshold implementations, and this is in particular helpful for protecting against side-channel attacks of our schemes. And Skinny was also designed to allow for very flexible separation into what is key and what is tweak, and this allows for very flexible parameter handling in an AAD mode. So, for instance, you can think about more members of an AAD family rather than those which we submitted to NIST. First of all, I will recall how the tweakable block cipher looks like before I present the AAD and the hashing modes. And then I will quickly give an overview of ASIC performances of our scheme before I conclude the talk with showing you the best script analysis so far and our ideas for third-round tweak proposals. The Skinny family of tweakable block ciphers was presented at Krypto 2016 and has the following main features. It is a very flexible tweakable cipher that allows several block ciphers and tweak or key ciphers, so we have different members of this family, and it is also an academic design that competes with the lightweight NSA cipher Simon in terms of performances and area in hardware implementations. While at the same time, it provides strong arguments against the most common attack vectors, most importantly differential and linear cryptanalysis. So, to go into detail of the specifications, Skinny supports block sizes of either 64-bit or 128-bit and also depending on the member, the tweak and key size t can be either equal to the block size or twice the block size or even three times the block size. And we will denote Skinny with an n-bit blocks and t-bit tweak and key by Skinny nt. And it is important to note that our schemes Skinny AAD and Skinny Hash only make use of the Skinny versions with a 128-bit block size and then only of those with a tweaky size of two times the block size and three times the block size. I will only focus on the Skinny variants with a 128-bit block size. So the internal state will be represented by a four times four matrix of 8-bit elements and the initial 128-bit plaintext will be mapped to the cipher state row by row. And then a round function depicted below will be iterated for several times depending on the version. So it is very similar to AES, so we have a substitution layer, a constant addition and a round key, a round tweaky addition before we have a linear layer very similar to the AES consisting of shift rows and mixed columns. And for Skinny 128-256, this round will be iterated 48 times. And for the Skinny version with a tweak size three times as long as the block size, we iterate this 56 times. So the substitution layer, as I said before, is an S-box layer which substitutes each byte of the state according to an 8-bit S-box which is depicted on the right side. This design was inspired by the Piccolo S-box and can be implemented in hardware with 24 gate equivalents only. It has good differential and linear properties, so for instance, for differences, non-zero differences, the maximum differential probability is 2 to the minus 2. The constant addition is also very lightweight, so in each round we only x or 3 8-bit constants to the first column of the state. And those constants are derived from a 6-bit affine LFSR. So far we have seen those two layers and in the next step I will explain how this add round tweaky operation looks like. So what is the difference between a block cipher and a tweakable block cipher? So on the left there is the usual block cipher depicted which gets a key as input and a plaintext and outputs a ciphertext. And for each fixed key the mapping from the plaintext to the ciphertext should be a permutation. On the right hand side a tweakable block cipher is depicted where we get some tweak value t as an additional input. And the idea is that each fixed tweak defines another block cipher, so another family of permutation parameterized by the key. In 2014 the tweaky framework was introduced which presented the idea that the tweak and the key material should be handled in the same way by a tweaky schedule. So they should not be separated as shown in the picture above. So instead of a tweak state schedule we have a tweaky schedule which gets this tweaky as an input. And then in each round a subtweaky will be generated here depicted by this function g which is then x-ord to the state. And in this tweaky schedule the tweaky state will be updated by some linear function h which is a very simple linear function. For example in skinny this consists of a permutation of a cell permutation of the internal state and some very simple LFSR operation. So this is depicted on this picture here. So the tweaky, so here this depicts the skinny version with a tweak key size of two times the block lengths. So we can separate this tweaky state into two 128 bit blocks. And the update function in each round is a cell permutation layer PT on each of these two states. And then one of these states is updated by an LFSR operation. And the subtweaky is generated by just taking the two states and x-or them together. And then what is important to note that the x-or to the state is only in the first two rows of the state. So we don't x-or the whole 128 bit tweaky but only 64 bit of tweaky in every round. So now I already said that the linear layer is very similar to the AES. So shift rows is a cell wise permutation of the state where row i of the state is rotated by i positions to the right. And in AES this rotation is to the left. This is the only difference. And a mixed column operates on every column of the state independently. So we have a linear transformation which branch number two in this case. Which ensures full state diffusion in both forward and backward direction within at most six rounds. And moreover one subtweaky addition is going to affect the whole state after one round. Guaranteed by this mixed column operation. This is important because the tweaky is only added to half of the round. So we have to think about what is the diffusion in the key. So now I will talk about the AEAD scheme. So we introduce six members in the NIST submission called M1 up to M6. Which vary in the underlying block cipher used and also in the length of the nonce and the length of the tag. The key is always 128 bits. M1 is the primary member. So it is based on skinny 128 384 and encrypts under 128 bit nonce and 128 bit key and generates a 128 bit tag. And the members M5 and M6, I have to remark that those do not follow the NIST requirements to support input messages of up to twosers of 50 bytes. Because the mode guarantees security only if the maximum message length is 2 to the 28 bytes for those two cases. So here I will explain how the TETA CB3 framework looks like. First I will concentrate on the handling of associated data. So the associated data denoted by the string A is separated into 128 bit blocks. So A0, A1 up to some ALA-1. And those go as the message into the tweakable block cipher. And then for each call the key of the cipher is equal to the nonce and the key of the AEAD. But the tweak varies. So the tweak varies for each block by some block counter here 01 up to LA-1 and some fixed byte for domain separation. And this domain separation byte, so here D2 indicates what is going to be processed right now. So for example, this byte will be different depending on whether you process associated data or the message. And it is also different depending on if you use padding or not. So for example, the first picture shows the handling without padding, the second picture with padding. And you can see that this last block is handled differently. So in case that the associated data length is not a multiple of the block lengths, you have to pad it with some string one and followed by zeros. And if you do this, then the associated data, then the domain separation byte is different. And then so you XOR the output of these. So the cipher outputs, you all XOR them together and generate some temporary authentication tag. So here this picture shows you how the encryption works. Again, the message is separated into 128 bit blocks, called M0 up to LM minus one. And they get as a message into the tweakable block ciphers. Again, the key is fixed to N and K and the tweak varies by a block counter and a final byte for domain separation. So here this byte is denoted D0 and this is different from the byte used in the associated data handling. And again, depending on whether you pad or not, the last block is handled differently. I'm using also another byte for domain separation. And then the output of these independent cipher calls will be given as a message, as a ciphertext C. And the final authentication tag is generated by XORing together the message and putting this into another tweakable block cipher call using another tweak value again. The output of this is XORed with the temporary authentication tag for associated data. I showed you on the slide before and this XOR will compute the tag which is given as the final output. And as you can see, this mode is highly parallelizable because it operates on independent tweakable block cipher calls. On the slides before, I presented a slightly simplified version of this scheme because we just used a simple block counter where we just incremented one by one. But in fact, this tweak value will be generated by an LFSR. So we clock an LFSR to generate the next counter value. And this does not matter for security because we just need that the counters are unique for each block. So this LFSR should have a high period. The mode offers full 128-bit security for confidentiality and an integrity security of the minimum of 128 or the tag length in the non-respecting model. So it's important to note the user is not allowed to use non-sys twice, for example. And it's important to remark that the confidentiality security is going to drop to the tag length if an adversary has a decryption oracle. So if in the adaptive chosen ciphertext model the security of confidentiality drops to the tag length. So the mode guarantees security only if the total size of the associated data and the message is limited. And so, for example, for the primary member, this size must not exceed 2 to the 68 bytes. And this comes from the LFSR used from generating the counters. You have 2 to the 64 independent blocks at most and you should not use a counter twice. And also the maximum number of messages for the same key should be upper bounded. So it should be 2 to the 128 for the primary member, for instance. So now let me describe how SkinnyHash looks like. So SkinnyHash uses the well-known sponge construction depicted here. And it is important to see here that the primary member uses a state size of 384 bits. So this FL should be a function of 384 bits. And then the rate will be 128 bits and the capacity 256 bits. So now how do these functions look like? So in the usual sponge construction a permutation is used. And we are going to build a function which is constructed from the Skinny Tweaker block cipher. So I will explain the right part of this picture because it corresponds to the primary member. So the input X, which is 384 bits, goes as a tweaky input into 3 Skinny 128, 384 block ciphers. And then the input of these block ciphers will be a constant. So for instance, constant 0, constant 1, constant 2. So we have the encryption of 3 constants under a fixed tweaky. And then the outputs will be concatenated together and will be given as the final output of 384 bits. And we are going to claim 2 to the half of the capacity bit security with regard to preimage, secondary image, and collision resistance. And what is quite interesting is that very recently a formal security proof given by Hoso Yamada and Ivata was published on the e-print archive which states that in the ideal cipher model the construction is indifferentiable from a random oracle if the total number of queries to the cipher and the inverse are in 0 to the 2 to the n. So we have to assume that the Skinny is an ideal tweakable block cipher and then this sponge mode instantiated with the function I've shown before will be indifferentiable from a random oracle up to 2 to the n number of queries. We also made hardware implementations of our schemes in ASICs and I will quickly show you the performances we got. Those are the results for the primary member of the AEAD scheme and the two variants for the hashing scheme. The first table shows unprotected round-based ASIC implementations. The second table shows side-channel-protected round-based ASIC implementations. For more details I will refer you to the paper. Let me talk a bit about the best crypt analysis so far. So besides our own crypt analysis in the crypto paper 2016 the Skinny cipher has received an extensive amount of external analysis and as of February 2020 which was the date of acceptance of the paper to the TOSC special issue we have found 30 formally published papers related to crypt analysis excluding all physical attacks. 14 of those papers only considered the Skinny versions we did not use in the AEAD and the hashing schemes and 16 of those papers studied the two Skinny instances we used in the NIST schemes. The best skin recovery attacks on those two variants are 23 rounds for the Skinny 128 and 256 and 28 rounds for the Skinny 128 384. There are all related tweaky attacks. And it is important to remark that those attacks are not necessarily valid on the AEAD and hashing scheme because of this modular approach. So we use this tweakable block cipher in a mode and it is not clear that the attacks on the cipher itself carries over to the mode. So these are only worst case attacks. So NIST has promised to allow tweaks if the schemes are chosen for the third round of the standardization process. And we plan to do two tweaks to our scheme. So first we are planning to drop all the members based on Skinny 128 and 256 in order to set the focus on the schemes that formally meet the NIST requirements. As I said, the members M5 and M6 for AEAD do not allow for long enough message. And so we are going to drop them. For hashing, this removal affects Skinny TK2 hash. So we only have one tweakable block cipher left that is applied in the schemes, namely Skinny 128 384. As a second proposal for a tweak, we plan to reduce the number of rounds of the Skinny tweakable block cipher. So if you remember, the best attack so far covers 28 rounds on Skinny 128 384. And our plan is to reduce from 56 rounds to 40 rounds. This reduction would still leave us 30% security margin on the primitive, not on the mode. And by this we are going to take advantage of the large amount of external cryptanalysis, which was conducted so far. The performance gain of this reduction will be about 1.4. And so we are going to do an improved, so we're going to get an improved tradeoff between security margin and efficiency. The new variants will be denoted by a plus sign in the end. So for instance, our primary member will be denoted Skinny AEAD M1 plus. This concludes my talk. Thank you very much.