Difference between revisions of "Lightweight Block Ciphers"
Leo.perrin (talk  contribs) (→Summary) 

(18 intermediate revisions by 2 users not shown)  
Line 318:  Line 318:  
      
 Specification<ref name=WZ11></ref>   Specification<ref name=WZ11></ref>  
+    
+  ! rowspan="3"  [[#LEALEA]]  
+   rowspan="3"  Hong et al.  
+   rowspan="3"  WISA 13<ref name=HLKRRL14></ref>  
+   rowspan="3"  128  
+   128  
+   rowspan="3"  GFN  
+   24  
+   rowspan="3"   
+  * None<ref name=ttbook group=note></ref>  
+   rowspan="3"    
+   rowspan="3"    
+   rowspan="3"    
+   rowspan="3"    
+   rowspan="3"    
+    
+   192  
+   28  
+    
+   256  
+   32  
    
! rowspan="2"  [[#LEDLED]]  ! rowspan="2"  [[#LEDLED]]  
Line 341:  Line 362:  
 Specification<ref name=GPPR11></ref>   Specification<ref name=GPPR11></ref>  
    
−  +  ! [[#MANTISMANTIS]]  
−  +   Beierle et al.  
−  +   CRYPTO 16<ref name=BJKLP16></ref>  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  ! [[#MANTISMANTIS]]  
−   Beierle et al.  
−   CRYPTO 16<ref name=BJKLP16></ref>  
 64   64  
 128+64 (tweak)   128+64 (tweak)  
Line 744:  Line 744:  
      
    
−  ! rowspan="5"  [[#SIMON and SPECKSPECK]]  +  ! rowspan="2"  [[#SPARXSPARX]] 
−   rowspan="5"  Beaulieu et al.  +   rowspan="2"  Dinu et al. 
−   rowspan="5"  eprint.iacr 13<ref name=BSST13></ref>  +   rowspan="2"  ASIACRYPT 16<ref name=DPUVGB16></ref> 
−   32  +   64 
+   rowspan="2"  SPN (ARX)  
+   128  
+   24  
+   rowspan="2"   
+  * Integral (15/22/24 rounds of SPARX64/128, 128/128, 128/256)<ref name=DPUVGB16></ref>  
+   rowspan="2"    
+     
+     
+     
+     
+    
+   128  
+   128/256  
+   32/40  
+     
+     
+     
+     
+    
+  ! rowspan="5"  [[#SIMON and SPECKSPECK]]  
+   rowspan="5"  Beaulieu et al.  
+   rowspan="5"  eprint.iacr 13<ref name=BSST13></ref>  
+   32  
 64   64  
 rowspan="5"  ARX   rowspan="5"  ARX  
Line 923:  Line 946:  
* Target: Software  * Target: Software  
−  Mysterion explores the LSdesign paradigm introduced by the designers of [[#Fantomas/RobinFantomas and Robin]] and combines it with an AESlike structure to increase the security level.  +  Mysterion explores the LSdesign paradigm introduced by the designers of [[#Fantomas/RobinFantomas and Robin]] and combines it with an AESlike structure to increase the security level. In particular, it uses a [[#BitSliced SBoxesbitsliced SBox]]. 
The internal state of the block cipher is organized into a 4×32 bit matrix for Mysterion128 and a 4×64 bit matrix for Mysterion256. These are subdivided into 4×8 blocks, so that the internal state of Mysterion128 (resp. 256) consists in 4 (resp. 8) such blocks. A round consists in the following operations:  The internal state of the block cipher is organized into a 4×32 bit matrix for Mysterion128 and a 4×64 bit matrix for Mysterion256. These are subdivided into 4×8 blocks, so that the internal state of Mysterion128 (resp. 256) consists in 4 (resp. 8) such blocks. A round consists in the following operations:  
Line 961:  Line 984:  
==== Zorro ====  ==== Zorro ====  
−  * Article: ''Block Ciphers that are Easier to Mask: How Far Can we Go?'', <ref name=GGNS13></ref>  +  * Article: ''Block Ciphers that are Easier to Mask: How Far Can we Go?'', CHES'13<ref name=GGNS13></ref> 
* Authors: Benoit Gerard, Vincent Grosso, Maria NayaPlasencia, FrancoisXavier Standaert  * Authors: Benoit Gerard, Vincent Grosso, Maria NayaPlasencia, FrancoisXavier Standaert  
* Target: Software  * Target: Software  
Line 975:  Line 998:  
Much thought has been put in the design of the Sbox: while retaining good cryptographic properties, it minimizes the number of multiplications necessary to compute it. It is based on a small 4round Feistel cipher with mixing layer where the Feistel function is the monomial X<sup>3</sup> in GF(2<sup>4</sup>).  Much thought has been put in the design of the Sbox: while retaining good cryptographic properties, it minimizes the number of multiplications necessary to compute it. It is based on a small 4round Feistel cipher with mixing layer where the Feistel function is the monomial X<sup>3</sup> in GF(2<sup>4</sup>).  
−  ===  +  === BitSliced SBoxes === 
−  +  All block ciphers with an SPN structure that use a bitsliced SBox are put in this category. We call "bitsliced SBox" a nonlinear layer consisting in the parallel application of several small nonlinear functions which is supposed to be implemented using basic bitwise operations such as XOR, AND and OR. While [[#MysterionMysterion]] is classified as AESlike in this list, it also fits in this category. Similarly, the Feistel networks [[#RoadRunneRRoadRunneR]] and [[#SEASEA]] use bitsliced SBoxes in their Feistel functions.  
−  ====  +  ==== Fantomas/Robin ==== 
−  +  [[File:LSdesign.pngthumbThe components of a LSdesign300px]]  
−  
−  
−  
−  
−  
−  
−  
−  [[File:LSdesign.pngthumbThe components of a LSdesign300px]]  
* Article: ''LSDesigns: Bitslice Encryption for Efficient Masked Software Implementations'', FSE'14<ref name=GLSV14></ref>  * Article: ''LSDesigns: Bitslice Encryption for Efficient Masked Software Implementations'', FSE'14<ref name=GLSV14></ref>  
Line 1,001:  Line 1,016:  
Robin uses involutions as both its LBox and its SBox but it is not the case for Fantomas. As a consequence, Robin has more rounds. Both have a 8×8 bits SBox and a 16×16 bits LBox.  Robin uses involutions as both its LBox and its SBox but it is not the case for Fantomas. As a consequence, Robin has more rounds. Both have a 8×8 bits SBox and a 16×16 bits LBox.  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
==== Noekeon ====  ==== Noekeon ====  
Line 1,036:  Line 1,033:  
A round constant is XORed in the internal state before applying Gamma during encryption. Since the components are involutionbased, decryption can be implemented using the same circuit as encryption. 16 rounds are used.  A round constant is XORed in the internal state before applying Gamma during encryption. Since the components are involutionbased, decryption can be implemented using the same circuit as encryption. 16 rounds are used.  
−  It is claimed to be suitable for implementation in hardware and on  +  It is claimed to be suitable for implementation in hardware and on 8bit processors. 
−  8bit processors.  
The best attack by the designers is a linear attack based on a 2rounds iterative linear trail covering 9 rounds, which is then extended to cover 12 rounds through key guessing.  The best attack by the designers is a linear attack based on a 2rounds iterative linear trail covering 9 rounds, which is then extended to cover 12 rounds through key guessing.  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
==== PRIDE ====  ==== PRIDE ====  
Line 1,068:  Line 1,051:  
The keyschedule is very similar to that of [[#PRINCEPRINCE]]: the master key is split in two halves, the first being used as whitening key and the second being used to derive subkeys XORed in the internal state at every round. However, unlike in PRINCE, the postwhitening key is the same as the prewhitening key and the subkeys are not derived by XORing round constants but by adding round constants on some bytes using a regular addition modulo 256.  The keyschedule is very similar to that of [[#PRINCEPRINCE]]: the master key is split in two halves, the first being used as whitening key and the second being used to derive subkeys XORed in the internal state at every round. However, unlike in PRINCE, the postwhitening key is the same as the prewhitening key and the subkeys are not derived by XORing round constants but by adding round constants on some bytes using a regular addition modulo 256.  
−  ====  +  ==== Rectangle ==== 
−  [[File:  +  [[File:Rectangle.pngthumbThe round function of Rectangle250px]] 
−  * Article: ''  +  * Article: ''RECTANGLE: A Bitslice UltraLightweight Block Cipher Suitable for Multiple Platforms'', Science China Information Sciences'15<ref name=ZBLR14></ref> 
−  * Authors:  +  * Authors: Wentao Zhang, Zhenzhen Bao, Dongdai Lin, Vincent Rijmen, Bohan Yang, Ingrid Verbauwhede 
−  * Target: Hardware  +  * Target: Hardware and software 
−  The  +  Rectangle is a substitution permutation network. Its state is represented as a 4×16 matrix. The nonlinear layer consists in the parallel application of a 4bit SBox on the columns of the state and the linear layer consists simply in applying a fixed rotation by a different amount on each row. There are two versions of this cipher. The first had a key schedule operating by storing the key in a matrix undergoing a round of encryption except that the SBox is only applied on the first column<ref name=ZBLR14old></ref>. It was vulnerable to a relatedkey differential attack against 19 rounds<ref name=SHSSM14></ref>. 
−  +  The latest version, as published in Science China'15<ref name=ZBLR14></ref>, is not vulnerable to this attack anymore. Its keyschedule is different: it still relies on partially applying an SBox layer to a key state but the overall operation has now a generalized Feistel structure. Compared to the older version, the key schedule of the latest version also performs better in software.  
−  +  === Other SPNbased Structures ===  
−  +  We put in this category the ciphers with a SPN structure which are not as close to the [[#AESAES]] as the others, be it by the structure of the linear layer (e.g. [[#PRESENTPRESENT]]) of by their overall structure (e.g. [[#PRINCEPRINCE]]).  
−  +  ==== mCrypton ====  
−  * Article: ''  +  * Article: ''mCrypton – A Lightweight Block Cipher for Security of LowCost RFID Tags and Sensors'', ISA 06<ref name=LK06></ref> 
−  * Authors:  +  * Authors: Chae Hoon Lim and Tymur Korkishko 
−  * Target: Hardware  +  * Target: Hardware 
−  +  This cipher is a derivative of [http://en.wikipedia.org/wiki/CRYPTON CRYPTON], a candidate of the AES competition. It has a structure close to that of [[#AESRijndael]]: it is a SPN with an internal space organised like a 4x4 matrix of nibbles of 4 bits. A round consists in the application of an Sbox layer, a bit permutation within each column, a transposition of the matrix representing the state and, finally, xoring of the subkey. There are four different Sboxes, two being the inverse of the other two and they are all based on the inverse function in GF(2<sup>4</sup>). Encryption and decryption are almost identical except for the key schedule.  
−  +  ==== MANTIS ====  
−  +  [[File:MANTISencryption.pngthumbThe structure of MANTIS500px]]  
−  =  +  * Article: ''The SKINNY Family of Block Ciphers and its LowLatency Variant MANTIS'', CRYPTO'16 <ref name=BJKLP16></ref> 
+  * Authors: Christof Beierle, Jérémy Jean, Stefan Kolbl, Gregor Leander, Amir Moradi, Thomas Peyrin, Yu Sasaki, Pascal Sasdrich, and Siang Meng Sim  
+  * Target: Hardware  
−  +  Mantis is a tweakable block cipher with a 64bit block size, 128bit key and a 64bit tweak. Much like [[#PRINCEPRINCE]], from which it borrows the overall structure and the αreflexivity, it is optimized for low latency. The keyschedule is also borrowed from PRINCE in the sense that the master key is cut in two halves, the first being used as an input and output whitening key and the second as a round key. However, additional operations are performed to take the tweak into account. The round function uses the following functions which operate on a 4x4 matrix of 4bit nibbles (note that the last half of the rounds are the functionnal inverse of the first ones except for the round constants).  
−  +  # <tt>MixColumns</tt>: Each column is multiplied by a 4x4 binary matrix M.  
−  +  # <tt>PermuteCells</tt>: This operations plays the same role as the <tt>ShiftRow</tt> of the AES. However, it is more sophisticated than a mere rotation of the rows.  
−  +  # <tt>AddTweakey</tt>: Adds k<sub>1</sub> (the second half of the masterkey) along with some tweak material to the internal state.  
−  +  # <tt>AddConstant</tt>: Round constants are added to the state. These were derived in a fashion very similar to those of [[#PRINCEPRINCE]].  
+  # <tt>SubCells</tt>: The internal state goes through a layer of identical 4bit SBoxes.  
+  Several of the components, namely the SBox, the permutation used in <tt>PermuteCells</tt> and the matrix M have been borrowed from the lowenergy cipher [[#MidoriMidori]].  
−  +  The security claim is the same as for [[#PRINCEPRINCE]]: an adversary with 2<sup>d</sup> plaintext/ciphertext pair cannot recover the key in time less than 2<sup>126n</sup> encryptions. Furthermore, while they do not claim relatedkey security because of the FX construction used, the designers do claim relatedtweak security.  
−  
−  
−  +  ==== PRESENT ====  
−  +  [[File:PRESENT_round_function.pngthumbTwo rounds of PRESENT encryption400px]]  
+  * Article: ''PRESENT: An UltraLightweight Block Cipher'', CHES 07<ref name=BKLP07></ref>  
+  * Authors: A. Bogdanov, L.R. Knudsen, G. Leander, C. Paar, A. Poschmann, M.J.B. Robshaw, Y. Seurin, and C. Vikkelsoe  
+  * Target: Hardware  
−  +  This cipher is a SPN but, interestingly, it was not inspired by the [[#AESAES]]. Indeed, while many SPNbased ciphers have permutation layers close in structure to that of the AES (see [[#LEDLED]] or [[#mCryptonmCrypton]]), that of PRESENT is completely different: it is bit oriented and is rather simple. It can be implemented in hardware using simple wiring. However, since bitoriented permutations are not softwarefriendly, the target of PRESENT is clearly a hardware implementation. Its Sbox was selected for its good cryptographic properties as well as for its small hardware footprint.  
−  +  PRESENT is a very important design as it has been an inspiration for many others. For instance, its Sbox has also been reused by [[#GOST%20revisitedGOST revisited]] and [[#LEDLED]] as well as the [[Lightweight_Hash_Functionslightweight hash function]] [[Lightweight_Hash_Functions#PHOTONPHOTON]]. This cipher also inspired the design of two lightweight hash functions: [[Lightweight_Hash_Functions#DMPRESENTDMPRESENT]] and [[Lightweight_Hash_Functions#SPONGENTSPONGENT]].  
−  ==  +  While only PRESENT80 is described in the body of the CHES 07 article<ref name=BKLP07></ref>, PRESENT128 and its modified keyschedule are described in the appendix. This cipher has been standardized and is part of the ISO29192<ref name=ISO29192></ref> with [[#CLEFIACLEFIA]]. 
−  +  ==== PRINCE ====  
−  +  [[File:PRINCE_core.pngthumbThe PRINCEcore algorithm600px]]  
−  * Article: ''  +  * Article: ''PRINCE – A Lowlatency Block Cipher for Pervasive Computing Applications'', ASIACRYPT 12<ref name=BCGK12></ref> 
−  * Authors: Gregor Leander, Christof Paar,  +  * Authors: Julia Borghoff, Anne Canteaut, Tim Guneysu, Elif Bilge Kavun, Miroslav Knezevic , Lars R. Knudsen, Gregor Leander, Ventzislav Nikov, Christof Paar, Christian Rechberger, Peter Rombouts, Søren S. Thomsen, and Tolga Yalcın 
−  * Target: Hardware  +  * Target: Hardware (low latency) 
−  +  The main aim of the design of PRINCE is low latency.  
−  
−  +  There is no real key schedule: three 64 bits keys are derived from the 128 master key. Two are used as whitening keys and the third is simply xored in the internal state during encryption. To make the rounds behave differently from one another, different constants are xored in the internal state at each round. These constants RC<sub>i</sub> (i=0,..,11) are such that RC<sub>i</sub>⊕RC<sub>11i</sub>=α where α is a constant derived from π. This property, combined with the fact that the first 5 rounds are the inverse of the last 5 mean that the decryption algorithm for key k is identical to an encryption with key k⊕α. This property is refered to as "αreflexivity".  
−  +  The authors [https://www.emsec.rub.de/research/research_startseite/princechallenge/ challenge the symmetric cryptography community] to attack (roundsreduced versions of) this cipher and offer different rewards for "practical" attacks.  
+  === ARXBased SPN ===  
−  +  ==== SPARX ====  
−  +  { class="floatright"  
−  +    
−  +   [[File:SparxA.pngthumbSPECKEY, denoted A<sub>k</sub>.]]  [[File:Sparx64roundfunction.pngthumbRound function of SPARX64/128]]  
+    
+  }  
−  +  * Article: ''Design Strategies for ARX with Provable Bounds: SPARX and LAX''<ref name=DPUVGB16></ref>  
+  * Authors: Daniel Dinu, Léo Perrin, Aleksei Udovenko, Vesselin Velichkov, Johann Großschädl and Alex Biryukov  
+  * Target: software  
−  +  ''Disclosure: the maintainers of this webpage are amongst the designers of SPARX. A page dedicated to this algorithm is available on this website ([[SPARXhere]]).''  
−  +  SPARX is a family of ARXbased 64 and 128bit block ciphers. Only addition modulo 2<sup>16</sup>, 16bit XOR and 16bit rotations are needed to implement any version.  
−  +  The SPARX ciphers have been designed according to the ''Long Trail Strategy'' put forward by its authors in the same paper. It can be seen as a counterpart of the WideTrail Strategy suitable for algorithms built using a large and weak SBox rather than a small strong one. This method allows the designers to bound the differential and linear trial probabilities, unlike for all other ARXbased designs. The nonlinearity is provided by SPECKEY, a 32bit block cipher identical to [[#SPECKSPECK32]] except for its key addition. The linear layer is very different from that of, say, the [[#AESAES]] as it consists simply in a linear Feistel round for all versions.  
−  +  == Feistel Networks ==  
−  +  === ARXBased ===  
−  
−  
−  +  ARXbased ciphers are designed using only modular Addition, Rotation and XOR. In particular, the only source of nonlinearity is the modular addition. Algorithms built in this fashion are usually faster and smaller than SBoxbased algorithms in software, as well as having some inherit security against sidechannel attacks as modular addition leaks less information than table lookups. However, modular addition is not as attractive for designing hardware optimized algorithms due to its latency and "large" input and output size.  
−  
−  
−  
−  
−  +  The [[#SPARXSPARX]] block cipher is ARXbased but, due to its having a SPN structure, is put in said category.  
−  ====  +  ==== Chaskey Cipher ==== 
+  [[File:Chaskey.pngthumbThe round function of the permutation of Chaskey.200px]]  
−  +  * Article: ''Chaskey: An Efficient MAC Algorithm for 32bit Microcontrollers'', SAC'14<ref name=MMVW14></ref>  
+  * Authors: Nicky Mouha, Bart Mennink, Anthony Van Herrewege, Dai Watanabe, Bart Preneel and Ingrid Verbauwhede  
+  * Target: Software  
−  +  Chaskey ([http://mouha.be/chaskey/ primitive's website]) is a lightweight MAC algorithm optimised for 32bit microcontrollers. It is based on a 128bit block cipher, the Chaskey cipher, which uses ARX operations and an EvenMansour structure. This means that there is no key schedule: the 128bit master key is XORed, then a public permutation is applied and then the master key is XORed again. This simplicity is possible at the cost of a weaker security claim as in e.g. [[#PRINCEPRINCE]] or [[#PRIDEPRIDE]] because a generic attack exists with a time complexity of about 2<sup>128</sup>/D if the attacker obtains D plaintextciphertext pairs.  
−  +  The code implementing it is very simple and is given below. It is similar to that of [[Lightweight_Hash_Functions#SipHashSipHash]].  
−  
−  
−  +  The original paper also suggests doubling the number of rounds of the Chaskey cipher to obtain an even more secure primitive, ChaskeyLTS (Long Term Security), with 16 rounds. It was later suggested<ref name=Mou15></ref>, in reaction to Leurent's differentiallinear attack<ref name=Leu15b></ref>, to use a variant with 12 rounds called Chaskey12.  
−  +  <pre>  
−  #  +  #include <stdint.h> 
−  #  +  #define ROTL(x,b) (uint32_t)( ((x) >> (32  (b)))  ( (x) << (b)) ) 
−  
−  +  void encrypt(uint32_t v[4], uint32_t key[4]) {  
−  +  int i;  
−  =====  +  for (i=0; i<4; i++) v[i] ^= key[i]; 
−  +  for (i=0; i<8; i++) {  
−  +  v[0] += v[1]; v[1]=ROTL(v[1], 5); v[1] ^= v[0]; v[0]=ROTL(v[0],16);  
+  v[2] += v[3]; v[3]=ROTL(v[3], 8); v[3] ^= v[2];  
+  v[0] += v[3]; v[3]=ROTL(v[3],13); v[3] ^= v[0];  
+  v[2] += v[1]; v[1]=ROTL(v[1], 7); v[1] ^= v[2]; v[2]=ROTL(v[2],16);  
+  }  
+  for (i=0; i<4; i++) v[i] ^= key[i];  
+  }  
+  </pre>  
−  
−  +  ==== HIGHT ====  
−  
−  
−  
−  
−  +  [[File:HIGHT_round_function.pngthumbThe round function of HIGHT.400px]]  
−  
−  
−  +  * Article: ''HIGHT: A New Block Cipher Suitable for LowResource Device'', CHES 06<ref name=HLHS06></ref>  
+  * Authors: Deukjo Hong, Jaechul Sung, Seokhie Hong, Jongin Lim, Sangjin Lee, BonSeok Koo, Changhoon Lee, Donghoon Chang, Jesang Lee, Kitae Jeong, Hyun Kim, Jongsung Kim, and Seongtaek Chee  
+  * Target: Hardware  
−  The key schedule  +  HIGHT is an ARX based generalised Feistel network with whitening. The only operations used are addition and substraction modulo 2<sup>8</sup>, xor and bitwise rotations. The subfunctions F<sub>0</sub> and F<sub>1</sub> consist in the xor of three different rotations of the input. The key schedule generates 8 bytes of whitening keys by selecting some bytes of the master key and 128 bytes of subkeys in a more complex way. Both during whitening and during encryption, addition and xor are used at the same time on different part of the internal state (see the round function on the right). 
+  
+  Unlike for instance [[#TWINETWINE]], the permutation of the words after addition (or xoring) of the subkeys is a simple rotation.  
+  
+  The first author of HIGHT is also the first author of [[#LEALEA]].  
+  
+  ==== LEA ====  
+  
+  [[File:LEAroundfunction.pngthumbThe round function of LEA.300px]]  
+  
+  * Article: ''LEA: A 128Bit Block Cipher for Fast Encryption on Common Processors'', WISA 13<ref name=HLKRRL14></ref>  
+  * Authors: Hong, D., Lee, J. K., Kim, D. C., Kwon, D., Ryu, K. H., and Lee, D. G.  
+  * Target: Software  
+  
+  LEA is a 128bit block cipher operating on 4 branches of 32 bits each. The only operations used are 32bit modular addition, XOR and rotation (ARX structure): the designers suppose that "the usage of 32bit and 64bit processors will grow rapidly compared to 8bit and 16bit ones" (see specification<ref name=HLKRRL14></ref>, Section 1.1). The round function is described in the picture on the right. Note that the key is added in both datapath going in each modular additions.  
+  
+  The key schedule also follows the ARX paradigm: constants are added modulo 2<sup>32</sup> to the key state and the different words are then rotated.  
+  
+  The first author of LEA is also the first author of [[#HIGHTHIGHT]].  
==== RC5 ====  ==== RC5 ====  
Line 1,226:  Line 1,232:  
It has been an inspiration for the AES competition finalist [http://en.wikipedia.org/wiki/RC6 RC6]. This algorithm is patented by RSA security.  It has been an inspiration for the AES competition finalist [http://en.wikipedia.org/wiki/RC6 RC6]. This algorithm is patented by RSA security.  
−  ====  +  ==== SIMECK ==== 
−  [[File:  +  [[File:SIMECK_round_function.pngthumbThe SIMECK round function.200px]] 
−  * Article: ''  +  * Article: ''The Simeck Family of Lightweight Block Ciphers'', CHES'15<ref name=YZSAG15></ref> 
−  * Authors:  +  * Authors: Gangqiang Yang, Bo Zhu, Valentin Suder, Mark D. Aagaard, and Guang Gong 
−  * Target:  +  * Target: Hardware 
−  +  SIMECK is a family of block ciphers heavily inspired by the [[#SIMONSIMON]] family of block ciphers. Indeed, the round function is the same up to a change in the rotation indices: rotations by 1, 8 and 2 bits are replaced by rotations by 0, 5 and 1 bit. The key schedule reuses the round function, much like in [[#SPECKSPECK]], hence the name of the primitive.  
−  
−  
−  #  
−  
−  The  +  The security claim of this cipher is based on that of SIMON: SIMECK is intended to be as secure as SIMON. Note that the designers of SIMECK are not affiliated to the National Security Agency (unlike the designers of SIMON and SPECK). 
−  The  +  The change in the rotations and the key schedule allow an improved hardware implementation: SIMECK requires a smaller area than SIMON when implemented in hardware. 
−  ====  +  ==== SIMON and SPECK ==== 
−  [[File:  +  { class="floatright" 
+    
+   [[File:SIMON_round_function.pngthumbRound function of SIMON]]  [[File:SPECK_round_function.pngthumbRound function of SPECK]]  
+    
+  }  
−  * Article: ''  +  * Article: ''The SIMON and SPECK Families of Lightweight Block Ciphers'', eprint.iacr.org, 2013<ref name=BSST13></ref> 
−  * Authors:  +  * Authors: Ray Beaulieu, Douglas Shors, Jason Smith, Stefan TreatmanClark, Bryan Weeks, and Louis Wingers (NSA) 
−  * Target:  +  * Target: Hardware (SIMON) and software (SPECK) 
−  +  These ciphers have been designed by the American [http://en.wikipedia.org/wiki/NSA National Security Agency (NSA)]. They are both Feistel networks with two branches but differ by the design of their Feistel function. They are both almost ARX construction, meaning that they rely on Addition, word Rotation and Xor, although SIMON uses And gates instead of additions. Both perform exceptionnally well in both hardware and software, although SIMON is supposed to be more hardwareoriented and SPECK more softwareoriented. Unlike all other ciphers' specification, no security analysis whatsoever is provided.  
−  
−  
−  
−  
−  
−  ====  +  ===== SIMON ===== 
−  +  Hardwareoriented, this blockcipher relies only on the following operations: and, rotation, xor. It is a classical Feistel network where the Feistel function consists in applying basic operations on the branch, xoring the in subkey and then xoring the result with the other branch.  
−  +  ===== SPECK =====  
−  
−  
−  +  Softwareoriented, this blockcipher relies only on the following operations: addition, rotation, xor (ARX construction). The structure of the round function is a typical ARX structure similar to the one of the block cipher Threefish used by the hash function Skein<ref name=FLSWB10></ref>.  
−  +  ==== XTEA ====  
−  +  * Article: ''Tea Extensions''<ref name=NW97></ref>  
+  * Authors: Needham R. and Wheeler D.  
+  * Target: Software  
−  +  XTEA is a cipher designed so as to be described by the smallest amount of code. It is an improvement of a previous design called TEA which had identical goals but several weaknesses. To illustrate the compactness of the Ccode describing encryption, we provide below a possible implementation (suggested on the [http://en.wikipedia.org/wiki/XTEA wikipedia page of XTEA]).  
−  +  <pre>  
−  +  #include <stdint.h>  
−  
−  
−  
−  *  +  /* take 64 bits of data in v[0] and v[1] and 128 bits of key[0]  key[3] */ 
−  
−  *  
−  +  void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {  
+  unsigned int i;  
+  uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9;  
+  for (i=0; i < num_rounds; i++) {  
+  v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);  
+  sum += delta;  
+  v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);  
+  }  
+  v[0]=v0; v[1]=v1;  
+  }  
+  </pre>  
−  ===  +  === Two Branched === 
−  +  In this category, we put all the Feistel networks operating on blocks of size 2n for which the Feistel function maps n bits to n bits that are not based on the ARX paradigm.  
−  ====  +  ==== DESLX ==== 
−  +  * Article: ''New Lightweight DES Variants'', FSE 07<ref name=LPPS07></ref>  
+  * Authors: Gregor Leander, Christof Paar, Axel Poschmann, and Kai Schramm  
+  * Target: Hardware  
−  ====  +  This cipher is a modified version of [http://en.wikipedia.org/wiki/Data_Encryption_Standard DES]. The 8 Sboxes have been replaced by unique one to make it easier to implement. Besides, the 
+  Sbox was chosen so as to achieve better resilience against linear and differential attacks. Another modification is the use of a FX structure to increase the security: parts of the keys are used as whitening keys in the input and in the output.  
+  
+  The idea of using an old design from an era when hardware optimization was critical was also used in [[#GOST%20revisitedGOST revisited]].  
+  
+  ==== GOST revisited ====  
−  +  [[File:GOST_round_function.pngthumbThe GOST round function.300px]]  
−  
−  
−  +  * Article: ''256 Bit Standardized Crypto for 650 GE – GOST Revisited'', CHES 10<ref name=PLW10></ref>  
+  * Authors: Axel Poschmann, San Ling, and Huaxiong Wang  
+  * Target: Hardware  
−  +  The [http://en.wikipedia.org/wiki/GOST GOST] used to be a sovietic counterpart for the American [http://en.wikipedia.org/wiki/NIST NIST]. It still exists as a standards organization for countries of the former USSR. In cryptography, GOST usually refers to the block cipher GOST standard, a 64 bit twobranch Feistel network with a Feistel function using eight unspecified Sboxes. GOST revisited consists simply in the block cipher described in the GOST standard such that it uses eight copies of the [[#PRESENTPRESENT]] Sbox. The idea of using such an old design is to benefit from the cryptanalytic scrutiny it has already been subject to. Besides, the GOST cipher had already been standardized for 20 years when the paper was published. The approach consisting in modifying an old standard is similar to that of the designers of [[#DESLXDESLX]].  
−  #  
−  /  +  There is no real key schedule, different blocks of the master key are used at each round. The Feistel function is simply a modular addition of the key (modulo 2<sup>32</sup>), an Sbox layer and rotation by 11bits. This very simple structure and the lack of a key schedule explain the very small hardware footprint of the cipher. 
−  +  The authors compare the footprint of GOST using their Sbox layer and the one used by the Central Bank of Russian Federation and, interestingly, the difference is not so big (identical throughput and 800 or 1000 GE depending on the speed/area tradeoff).  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  ===  +  ==== ITUbee ==== 
−  +  [[File:ITUbee_encryption.pngthumbA complete ITUbee encryption.200px]]  
−  +  * Article: ''ITUbee: A Software Oriented Lightweight Block Cipher'', Lightweight Cryptography for Security and Privacy 13<ref name=KDH13></ref>  
−  +  * Authors: Ferhat Karakoç, Hüseyin Demirci, and A. Emre Harmancı  
−  * Article: ''  
−  * Authors:  
* Target: Software  * Target: Software  
−  +  ITUbee is a block cipher using 20 rounds of a Feistel structure with key whitening at the beginning and end of the encryption. Its structure is summarized in the figure on the right where:  
+  * L is a multiplication by a simple 5x5 square matrix operating on bytes,  
+  * S is a substitution layer using the SBox of the [[#AESAES]],  
+  * F(x) = S(L(S(x))).  
+  Its use of a Feistel function based on a small SPN is reminiscent of the Generalized Feistel Network [[#PiccoloPiccolo]]. Chunks of the master key are used directly during encryption; the only key schedule consists in adding round constant in a fashion similar to [[#LEDLED]] or [[#PRINCEPRINCE]]. Another Feistel Network with a SASASAS structure as its Feistel function was published later: [[#RoadRunneRRoadRunneR]].  
−  The  +  Its main features are low power consumption and low memory requirement in software (8bits microcontroller) according to simulations on the AVR ATiny45 microcontroller. The authors claim resilience against related key attacks. Unlike many lightweight block ciphers which have a block length of 64 bits, ITUbee uses blocks of 80 bits. 
−  +  ==== KASUMI/MISTY ====  
−  
−  
−  
−  +  [[File:Misty_rounds.pngthumbA description of the recursive structure of MISTY1 (KASUMI is similar to MISTY1) and MISTY2.350px]]  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  
−  ====  +  ===== MISTY ===== 
−  +  * Article: ''New Block Encryption Algorithm MISTY'', Fast Software Encryption 97<ref name=Mat97></ref>  
+  * Authors: Minoru Matsui  
+  * Target: Software and Hardware  
−  +  MISTY is a set of two 64bit block ciphers using 4n rounds (usually, 4n=8) with a Feistel structure for MISTY1 and MISTYlike (i.e. the non linear permutation is applied on a branch directly) for MISTY2 along with specific key dependent transformation applied on the branches between the rounds. The structure of the nonlinear function is itself a 3round Feistel Network and the Feistel function used in this second layer has a MISTYlike structure. This recursive structure is shown in the picture on the right. At the final level, 7 and 9bit bijective SBoxes are used. While uncommon, this choice allows the SBoxes to be both APN and bent, a task significantly harder to achieve on 8bit<ref group=note>In fact, whether an 8bit APN permutation exist is still an open problem.</ref>.  
−  
−  
−  +  The design criteria for MISTY is clearly stated:  
+  # MISTY should have a numerical basis for its security,  
+  # MISTY should be reasonably fast in software on any processor,  
+  # MISTY should be sufficiently fast in hardware implementation.  
−  +  The key schedule of MISTY reuses a component used during encryption, namely the socalled FI function corresponding to a 3round unbalanced MISTYlike structure using the 7 and 9bit SBoxes.  
−  ====  +  ===== KASUMI ===== 
−  +  KASUMI is a variant of MISTY1 allowing a more efficient hardware implementation. Its specification can be obtained from the etsi.org website<ref name=Etsi3GPP></ref>. It is referred to as A5/3 in this specification. It is identical to MISTY1 with 8 rounds (the default) except for its key schedule which simply rotates the bits of the master key and XORs round constants. This simplification lead to a vulnerability against relatedkey attacks<ref name=DKS10></ref> which is not present in MISTY1.  
−  +  ==== LBlock ====  
−  
−  
−  +  { class="floatright"  
+    
+   [[File:Lblockencryption.pngthumbA high level view of the LBlock encryption.100px]]  [[File:Lblockfeistelfunction.pngthumbThe Feistel function of Lblock.250px]]  
+    
+  }  
−  +  * Article: ''LBlock: A Lightweight Block Cipher'', ACNS 11<ref name=WZ11></ref>  
+  * Authors: Wenling Wu and Lei Zhang  
+  * Target: Hardware and Software  
−  +  This Feistel Network has two branches of 32 bits and a "twist": the branch which is xored with the output of the F function is first rotated by 8 bits. The Feistel function is made of a xor with a subkey, a layer of 8 distinct 4x4 Sboxes and a word permutation shuffling 4bit words. The permutation used in the Feistel function and the bit rotation of one of the branch make this design very similar to [[#TWINETWINE]] as explained in the TWINE specification<ref name=SMMK11></ref>.  
−  ====  +  The key schedule involves two additional Sboxes which are different from the ones used in the Feistel function. 
+  
+  ==== RoadRunneR ====  
−  [[File:  +  [[File:roadrunner_encryption.pngthumbThe RoadRunneR encryption.300px]] 
−  * Article: ''  +  * Article: ''RoadRunneR: A Small And Fast Bitslice Block Cipher For Low Cost 8bit Processors'', LightSec 2015<ref name=BS15></ref> 
−  * Authors:  +  * Authors: Adnan Baysal and Sühap Şahin 
* Target: Software  * Target: Software  
−  +  RoadRunneR is a Feistel Network which uses a SPN as its Feistel function. The nonlinear layer of the Feistel funciton is based on the bitsliced implementation of its SBox as can be seen for instance in the LS strategy introduced for [[#Robin/FantomasRobin and Fantomas]]. The designers had the following goals:  
+  # Implementation efficiency in 8bit CPUs,  
+  # No table and SRAM usage,  
+  # Low decryption overhead,  
+  # Provable security like in wide trail design strategy.  
+  
+  The key schedule is very simple: 32bit chunks of the master key are used one after another. Once the end of the key is reached, the first bits are used again. Round constants are added to prevent slide attacks.  
+  
+  The Feistel function has a SPN structure consisting in 4 SBox layers, 3 linear layers (much like [[#ITUbeeITUbee]]) and 3 key additions. The 4bit SBox was chosen for the very simple circuit that can be used to compute it as well as its good cryptographic properties. It was found in a previous work by Ullrich et al.<ref name=UDCIKMP11></ref> and is also used by [[#MysterionMysterion]]. The linear layer is applied on 4 bytes separately and consists in the xor of three different rotations of its input (in a fashion similar to the F<sub>0</sub> and F<sub>1</sub> functions of [[#HIGHTHIGHT]]): <math>x \mapsto x \oplus (x <<< 1) \oplus (x <<< 2)</math>.  
+  
+  ==== SEA ====  
+  
+  [[File:SEA_round_function.pngthumbThe SEA round function.300px]]  
+  
+  * Article: ''SEA: A Scalable Encryption Algorithm for Small Embedded Applications'', Smart Card Research and Advanced Applications 06<ref name=SPGQ06></ref>  
+  * Authors: FrancoisXavier Standaert, Gilles Piret, Neil Gershenfeld, and JeanJacques Quisquater  
+  * Target: Software and Hardware  
+  
+  SEA is a block cipher which can have an arbitrary block size n (as long as n=6b for some b), word size w and number of rounds n<sub>r</sub>. A complete description of the algorithm (round function and update of the key) is given on the figure on the right which comes from the original paper<ref name=SPGQ06></ref>. It is based on the following operations:  
+  * Bitwise XOR  
+  * Application of an Sbox S. Interestingly, S is a 3x3 Sbox.  
+  * Rotation of the words in a vector of words  
+  * Bit rotation inside a word  
+  * Addition modulo 2<sup>b</sup>  
+  
+  === Generalized Feistel Networks (GFN) ===  
+  
+  ==== CLEFIA ====  
+  
+  [[File:CLEFIA_Appendix_C.pngthumbThe CLEFIA encryption and its subroutines.200px]]  
+  
+  * Article: ''The 128Bit Blockcipher CLEFIA'', FSE 07<ref name=SAMT07></ref>  
+  * Authors: Taizo Shirai, Kyoji Shibutani, Toru Akishita, Shiho Moriai, and Tetsu Iwata  
+  * Target: Hardware and Software  
−  The  +  This cipher is intended for use in DRM protocols. Its "lightweightness" can be debated as an area of 4950 GE is significant. The designers of CLEFIA worked for [http://en.wikipedia.org/wiki/Sony_Corporation Sony] and some of them were involved in the creation of [[#PiccoloPiccolo]]. 
−  +  CLEFIA has been standardized and is part of the ISO29192<ref name=ISO29192></ref> with [[#PRESENTPRESENT]].  
==== Piccolo ====  ==== Piccolo ====  
Line 1,596:  Line 1,628:  
<ref name=DPUVGB16>  <ref name=DPUVGB16>  
−  Dinu, D., Perrin, L., Udovenko, A., Velichkov, V., Großschädl, J. & Biryukov, A. (2016). ''Design Strategies for ARX with Provable Bounds: SPARX and LAX''. In Advances in Cryptology–ASIACRYPT 2016 (  +  Dinu, D., Perrin, L., Udovenko, A., Velichkov, V., Großschädl, J. & Biryukov, A. (2016). ''Design Strategies for ARX with Provable Bounds: SPARX and LAX''. In Advances in Cryptology–ASIACRYPT 2016 (pp 484513). Springer Berlin Heidelberg. [http://eprint.iacr.org/2016/984.pdf pdf at eprint.iacr.org] 
</ref>  </ref>  
<ref name=DPVAR00>  <ref name=DPVAR00>  
−  Joan Daemen, Michaël Peeters, Gilles Van Assche, Vincent Rijmen (2000). ''Nessie Proposal: Noekeon'', First Open Nessie Workshop. [http://  +  Joan Daemen, Michaël Peeters, Gilles Van Assche, Vincent Rijmen (2000). ''Nessie Proposal: Noekeon'', First Open Nessie Workshop. [http://gro.noekeon.org/Noekeonspec.pdf pdf at noekeon.org] 
</ref>  </ref>  
Line 1,749:  Line 1,781:  
<ref name=NW97>  <ref name=NW97>  
Needham, R. M., & Wheeler, D. J. (1997). ''Tea extensions''.  Needham, R. M., & Wheeler, D. J. (1997). ''Tea extensions''.  
+  </ref>  
+  
+  <ref name=OVTK09>  
+  Özen, 0., Varıcı, K., Tezcan, C., & Kocair, C. (2009). ''Lightweight Block Ciphers Revisited: Cryptanalysis of Reduced Round PRESENT and HIGHT''. In Proceedings of the 14th Australasian Conference, ACISP 2009 Brisbane, Australia, July 13, 2009 (pp 90107). SpringerVerlag Berlin Heidelberg. [http://link.springer.com/chapter/10.1007/9783642026201_7 pdf at springer.com]  
</ref>  </ref>  
Latest revision as of 14:34, 11 April 2017
Lightweight block ciphers are lightweight cryptographic primitives. On this page, we list 36 lightweight block ciphers and study their properties: properties of the algorithm (structure, block size, number of rounds, etc), hardware implementation properties and known attacks.
Contents
Block Cipher Design
Desirable Properties
The aim of a block cipher is to provide a keyed pseudorandom permutation which is then used as the building block of more complex protocols. For instance, coupled with a proper Mode of operation, they can be used to encrypt data. A "good" blockcipher must be fast and secure, i.e. it must be impossible for an adversary with realistic computing power to retrieve the key used even if she has access to a blackbox capable of encrypting and decrypting the plaintext of her choice (security against chosenciphertext attack).
Design Principles
There are two families of designs for block ciphers: SubstitutionPermutation Networks and Feistel Networks. There are also specific constraints when designing lightweight blockciphers. First of all, memory is very expensive so that implementing Sboxes as lookup table can lead to a large hardware footprint. That is why these ciphers usually have no Sbox at all (SIMON) or very small ones, only 4x4 (PRESENT).
Cost of Implementing Decryption
Implementing decryption alongside encryption should lead to an increase of the area necessary as it requires its own logic. However, depending on the mode of operation of the cipher, it may be possible to ignore the decryption algorithm: for instance, in the case of OFB, decryption is useless. Another way of reducing the additional cost is to build algorithms such that encryption and decryption are very similar. A first approach is to use involutions as components, for instance in KLEIN. The whole structure can be exploited to have involution related properties, for instance αreflexivity in the case of PRINCE or differentiate encryption from decryption simply by a variation in the keyschedule (Feistel networks, mCrypton).
Fixed key?
The designers of symmetric block ciphers have different approaches regarding relted key attacks. The usecase of lightweight cryptography can lead to opposite views concerning the necessity of countermeasure to prevent such attacks.
 Because the key is likely to be "burnt" in the device, i.e. that it will not be possible to change it, there is no point in worrying about related key attacks: the probability for an attacker to obtain several devices keyed with appropriately related keys is too small to be of any importance.
 However, such block ciphers are very likely to be used to build compression functions for hash function with a MerkleDamgård structure. In this context, resilience against related key attakcs is much more important.
Summary
In the following table we list for each block cipher:
 Where it comes from (designers, year, conference/journal where it was introduced...),
 Its basic properties (key size, block size, structure...),
 Its known weaknesses (to the best of our knowledge),
 The properties of its best (to the best of our knowledge) hardware implementation.
Comparisons of the efficiency in time and space of their software implementation can be found in Survey and Benchmark of Lightweight Block Ciphers for Wireless Sensor Networks^{[1]} and on the webpage of the BLOC project. Source code for most of these primitives can be found on the github account of the project.
Presentation  Cryptographic Properties  Implementation Properties  

name  designers  reference (design)  block size  key size  structure  rounds  attacks  Technology used  area (#GE)  throughput (Kb/s @ 100kHz)  power consumption (µW)  reference (implementation) 
AES  Rijmen et al.  AES conference 98^{[2]}  128  128  SPN  10 

0.13µm  3100  80    ECRYPT^{[6]} 
192  12            
256  14            
Chaskey Cipher  Mouha et. al.  SAC'14^{[7]}  128  128  ARX  8 

         
CLEFIA  Shirai et al.  FSE 2007^{[9]}  128  128  GFN  18 

0.09µm  4950  355.6    ECRYPT^{[6]} 
192  22            
256  26            
DESLX  Leander et al.  FSE 2007^{[12]}  64  184  Feistel  16 

0.18 µm  2168  44.4  1.6  ECRYPT^{[6]} 
Fantomas  Grosso et al.  FSE'14^{[13]}  128  128  SPN  12 

         
GOST revisited  Poschmann et al.  CHES 10^{[14]}  64  256  Feistel  32 

0.18 µm  651 / 1017  24.24 / 200    Specification^{[14]} 
HIGHT  Hong et al.  CHES 06^{[16]}  64  128  GFS  32 

0.25µm  3048  188.2    ECRYPT^{[6]} 
ITUbee  Karakoç et al.  LightSec'13^{[21]}  80  80  Feistel  20 

         
KASUMI  ETSI  3GPP std^{[22]}  64  128  Feistel  8 

         
KLEIN  Gong et al.  SaP 12^{[24]}  64  64  SPN  12 

0.18 µm  1360 / 2032      Specification^{[24]} 
80  16  1530 / 2202      
96  20  1700 / 2372      
KATAN  De Cannière et al.  CHES 09^{[27]}  32  80  streamcipherlike  254 

0.13 µm  802  12.5  0.381  ECRYPT^{[6]} 
48            
64  0.13 µm  1054  25.1  0.555  ECRYPT^{[6]}  
KTANTAN  De Cannière et al.  CHES 09^{[27]}  32  80  streamcipherlike  254  0.13 µm  462  12.5  0.146  ECRYPT^{[6]}  
48            
64  0.13 µm  688  25.1  0.292  ECRYPT^{[6]}  
LBlock  Wu et al.  ACNS 11^{[31]}  64  80  Feistel  32 

0.18 µm  1320  200    Specification^{[31]} 
LEA  Hong et al.  WISA 13^{[37]}  128  128  GFN  24 

         
192  28  
256  32  
LED  Guo et al.  CHES 11^{[38]}  64  64  SPN  32 

0.18 µm  966  5.1    Specification^{[38]} 
128  48  1265  3.4    Specification^{[38]}  
MANTIS  Beierle et al.  CRYPTO 16^{[40]}  64  128+64 (tweak)  SPN  14 

         
mCrypton  Lim et al.  ISA 06^{[42]}  64  64  SPN  12 

0.13µm  2420^{[note 3]}  482.3    Specification^{[42]} 
96  2681^{[note 3]}      
128  2949^{[note 3]}      
Midori  Banik et al.  Asiacrypt'15^{[44]}  64  128  SPN  16 

0.09µm^{[note 4]}  1542    60.6^{[note 5]}  Specification^{[44]} 
128  20  2522    89.2^{[note 5]}  
MISTY1  Matsui  FSE'97^{[45]}  64  128  Feistel  8 

         
Mysterion  Journault et al.  WCC 15^{[48]}  128  ?^{[note 6]}  SPN  12 

         
256  ?^{[note 6]}  16          
Noekeon  Daemen et al.  Nessie Workshop^{[49]}  128  128  SPN  16 

         
Piccolo  Shibutani et al.  CHES 11^{[51]}  64  80  GFN  25 

  683 / 1136  14.8 / 237.04   /   Specification^{[51]} 
128  31    758 / 1196  12.12 / 193.9   /   
PRESENT  Bogdanov et al.  CHES 07^{[54]}  64  80  SPN  31 

0.18 µm  1075 / 1570  11.7 / 200  1.4 / 2.78  Poschmann's PhD Thesis^{[58]} 
128  1391 / 1884  11.45 / 200   / 3.67  
PRIDE  Albrecht et al.  CRYPTO 14^{[59]}  64  128  SPN  20 

         
PRINCE  Borghoff et al.  ASIACRYPT 12^{[59]}  64  128  SPN  12 

0.09 µm / 0.13 µm  3286 / 3491  529.9 / 533.3  4.5 / 5.8  Specification^{[59]} 
RC512  Rivest  FSE 95^{[63]}  32  0..2040  ARX  12 

        
64  
128  
Rectangle  Zhang et al.  Sci China'15^{[66]}  64  80  SPN  25 

0.13 µm  1599.5    Specification^{[66]}  
128  2063.5    
RoadRunneR  Baysal et. al.  LightSec 15^{[67]}  64  80  Feistel  10 

         
128  12          
Robin  Grosso et al.  FSE'14^{[13]}  128  128  SPN  16 

         
SEA  Standaert et al.  SCRAA 06^{[69]}  96^{[note 7]}  96  Feistel  93 

0.13 µm  449^{[70]}    3.218  MSQ07^{[71]} 
SKINNY  Beierle et al.  CRYPTO 16^{[40]}  64  64/128/192^{[note 8]}  SPN  32/36/40 

0.18 µm  1223/1696/2183  200.0/177.8/160.0    Specification^{[40]} 
128  128/256/384^{[note 8]}  40/48/56  2391/3312/4268  320.0/266.7/228.6    Specification^{[40]}  
SIMECK  Yang et al.  CHES'15^{[72]}  32  64  Feistel  32 

0.13µm  549 / 765  5.6 / 88.9  0.417 / 0.606  Specification^{[72]} 
48  96  36  778 / 1117  5.0 / 120.0  0.576 / 0.875  
64  128  44  1005 / 1484  4.2 / 133.3  0.754 / 1.162  
SIMON  Beaulieu et al.  eprint.iacr 13^{[75]}  32  64  Feistel  32 

        Specification^{[75]} 
48  72 / 96  36   / 763   / 15.0    
64  96 / 128  42 / 44  838 / 1000  17.8 / 16.7    
96  96 / 144  52 / 54  984 /   14.8 /     
128  128 / 192 / 256  68 / 69 / 72  1317 /  /   22.9 /  /     
SPARX  Dinu et al.  ASIACRYPT 16^{[81]}  64  SPN (ARX)  128  24 

         
128  128/256  32/40          
SPECK  Beaulieu et al.  eprint.iacr 13^{[75]}  32  64  ARX  22 

        Specification^{[75]} 
48  72 / 96  22 / 23   / 884   / 12.0    
64  96 / 128  26 / 27  984 / 1127  14.5 / 13.8    
96  96 / 144  28 / 29  1134 /   13.8 /     
128  128 / 192 / 256  32 / 33 / 34  1396 /  /   12.1 /  /     
TWINE  Suzaki et al.  Workshop on LC 11^{[84]}  64  80  GFN  36 

0.09 µm  1799  178    Specification^{[84]} 
128 

2285  178    
XTEA  Needham et al.  Note^{[87]}  64  128  Feistel  64 

0.13 µm  3490  57.1  19.5  ECRYPT^{[6]} 
Zorro  Gérard et al.  CHES 13^{[90]}  128  128  SPN  24 

         
SubstitutionPermutation Network
The SubstitutionPermutation Network (SPN) structure is the result of the seminal work of Shannon as it aims to provide both confusion and diffusion using two distinct operations. "Confusion" aims at making the relationship between the plaintext, the key and the ciphertext complicated while "Diffusion" focuses on achieving the avalancheeffect,i.e. a small modification on the plaintext must spread to the whole ciphertext. In an SPN, confusion is performed by a layer of Sboxes. An Sbox is simply a permutation of a small subset of plaintext space and many are used in parallel to act upon the whole plaintext. Diffusion is achieved through the use of a permutation of the whole space, usually linear and sometimes called Pbox. The best example of such a structure is Rijndael, the cipher which has been standardized by the American NIST to become the Advanced Encryption Standard (AES). This cipher had a great influence over the design of other primitives which we gathered in a group we call AESlike. However, it is possible to build a SPNbased cipher which is not as similar to the AES; such designs are presented in this section.
AESlike
We put in this category the block ciphers having a structure derived from that of the AES. As it is the current encryption standard, the cryptographic community has been studying it closely since its publication in 1997 and, as of November 2013, it is still secure.
The lightweight authenticated cipher FIDES could also fit in this category. Furthermore, the stream cipher LEX^{[92]} is based on the AES and serves as a basis for the design of other lightweight authenticated encryption schemes, namely ASC1 and ALE.
AES
 Article: AES proposal: Rijndael, AES conference 98^{[2]}
 Authors: Joan Daemen, Vincent Rijmen
The AES consists in 3 versions of the Rijndael cipher which have been standardized by the NIST. They are called AES128, AES192 and AES256, the number corresponding to the key size. The internal state is always of 128 bits in the standard. An encryption consists in the following operations which are performed over the 128bits internal state organized as a 4x4 matrix of bytes.
 SubBytes: Each cell in the matrix is replaced by its image by a Sbox. The AES Sbox is S(x) = M(x^{1})⊕C where the multiplicative inverse is taken in GF(2^{8}) (0 being mapped to 0), M is a matrix and C a constant. The inverse function is used because of its optimal nonlinearity and differential spectrum (in even characteristic), properties which were known long before^{[93]}. This Sbox is also used for instance in PHOTON.
 ShiftRows: The cells in the first row are left untouched, those in the second are shifted by 1 to the left, those in the third by 2 and those in the fourth by 3. This is to ensure diffusion between columns.
 MixColumns: Each column is multiplied by an invertible MDS matrix to ensure diffusion between the rows.
 AddRoundKey: The current subkey is xored in the internal state.
To have a visual explanation of the inner working of this cipher, the reader may refer to this flash animation by Enrique Zabala, Universidad ORT, Montevideo, Uruguay.
KLEIN
 Article: KLEIN: A New Family of Lightweight Block Ciphers, SaP 12^{[24]}
 Authors: Zheng Gong, Svetla Nikova and Yee Wei Law
 Target: Hardware and Software
The 4x4 Sbox used in the SubNibbles step is an involution. Furthermore, since all the Sboxes in the Sbox layer are identical, it is possible to implement only one in hardware and put all protections against sidechannel attacks in this unique place. The diffusion layer is made of two steps. The 16 4bits nibbles are grouped into 8 bytes which are rotated two steps to the left so that the second byte becomes the last (RotateNibbles). Then, the bytes are split into two groups of 4 bytes which are considered like vectors of (GF(2^{8}))^{4} and multiplied by a matrix (MixNibbles). This last operation is very similar to the MixColumn operation of the AES.
The keyschedule is a Feistel Network involving at each round two calls to the Sbox and a xoring of a round counter.
When discussing the keyschedule, the designers claim (Section 3.2.4^{[24]}):
KLEIN will be used to construct blockcipherbased hash functions and message authentication codes[...]
They also tried to prevent relatedkey attacks and to provide easier masking to prevent sidechannel attacks.
LED
 Article: The LED Block Cipher, CHES 11^{[38]}
 Authors: Jian Guo, Thomas Peyrin, Axel Poschmann, and Matt Robshaw
 Target: Hardware and Software
Lightweight Encryption Device is a SPN heavily based on AES. Encryption is made of "steps" interleaved with xoring of the key, each "step" corresponding to 4 rounds. Each round is made of the xoring of a round constant and AESstyle SubCells, ShitRows and MixColumnsSerial operations. The method used to design the MDS matrix used in the MixColumnsSerial was first used for the hash function PHOTON designed by the same team. The Sbox used in the SubCells step is the PRESENT Sbox.
An interesting characteristic of this design is the key schedule (or lack thereof): a key of 64 bits is xored with internal state as is while a key of 128 bits is cut into two subkeys of 64 bits which are used alternatively. Because of this, it is a variation of the EvenMansour construction like in its best attack^{[39]}.
The authors provide a reference implementation as well as results on the efficiency of their algorithm at led.crypto.sg. Note that the algorithm presented in the proceedings of CHESS 2011 (link) has been modified slightly in the version available on eprint^{[38]}. In particular, the definition of the round constants has been modified and an 80bit version of the cipher was introduced.
Midori
 Article: Midori: A Block Cipher for Low Energy Asiacrypt'15^{[44]}
 Authors: Subhadeep Banik, Andrey Bogdanov, Takanori Isobe, Kyoji Shibutani, Harunaga Hiwatari, Toru Akishita, and Francesco Regazzoni
 Target: Hardware
Midori64 and Midori128 are two block ciphers designed to reduce energy consumption when implemented in hardware. They are both based on the same Midori structure. It uses an AESlike structure where the internal state is divided into a 4x4 matrix of nibbles (Midori64) or bytes (Midori128). Encryption then relies on 4 operations:
 SubCell: application of the 4 or 8bit SBoxes to each cell of the internal state. There are 4 different 8bit SBoxes built with an ASA^{1} structure where S consists in the parallel application of a 4bit SBox (distinct from the one used in Midori64) and A is one of 4 different 8bit permutations.
 ShuffleCell: A sophisticated replacement of the ShiftRow operation of the AES is used. A different permutation of the 4 cells is applied on each row. These were chosen so as to maximize diffusion.
 MixColumn: Each column is replaced by its image by a multiplication with an almostMDS involution matrix M.
 KeyAdd: A key addition. The key schedule is very simple: for the 128bit version, the master key is XORed in the internal state along with a sparse round constant at every round. For the 64bit version, the first half of the master key is XORed in the internal state in odd rounds and the second in even rounds. The XOR of the two halves is used as whitening keys and, again, sparse round constants (equal to 0 except on the LSB of each nibble) are used.
The specification^{[44]} contains a detailed analysis of the power consumption of this algorithm as well as comparison with other algorithms (namely AES, PRINCE, PRESENT, Noekeon and SIMON).
Mysterion
 Article: Improving the Security and Efficiency of Block Ciphers based on LSDesign WCC 15^{[48]}
 Authors: Anthony Journault, FrançoisXavier Standaert and Kerem Varici.
 Target: Software
Mysterion explores the LSdesign paradigm introduced by the designers of Fantomas and Robin and combines it with an AESlike structure to increase the security level. In particular, it uses a bitsliced SBox.
The internal state of the block cipher is organized into a 4×32 bit matrix for Mysterion128 and a 4×64 bit matrix for Mysterion256. These are subdivided into 4×8 blocks, so that the internal state of Mysterion128 (resp. 256) consists in 4 (resp. 8) such blocks. A round consists in the following operations:
 SBox layer: the 4x4 "Class 13" SBox identified by Ullrich et al.^{[94]} is applied in parallel to each column of the internal state (much like in the Feistel function of RoadRunneR).
 LBox layer: the 8×8 LBox is applied bytewise in parallel on every row of every block: 4 (resp. 8) parallel applications/row for Mysterion128 (resp. Mystertion256).
 ShiftColumns: this operation is similar in spirit to the ShiftRow operation of the AES. For Mysterion256, the first column of each block is left unchanged, the second are rotated by one, etc. For Mysterion128, the columns are grouped 2by2 so that the first 2 columns of each block are left unchanged, the next 2 are rotated by 2, etc. (see picture on the right).
SKINNY
 Article: The SKINNY Family of Block Ciphers and its LowLatency Variant MANTIS, CRYPTO'16 ^{[40]}
 Authors: Christof Beierle, Jérémy Jean, Stefan Kolbl, Gregor Leander, Amir Moradi, Thomas Peyrin, Yu Sasaki, Pascal Sasdrich, and Siang Meng Sim
 Target: Hardware
SKINNY is a family of lightweight tweakable block ciphers designed so as to have the smallest hardware footprint. All members of the family are SPN consisting of several iterations of the following operations transforming a 4x4 matrix of 4bit nibbles (64bit variant) or bytes (128bit variant). A picture summarizing this is given on the right.
 SubCells (SC): each cell goes through an SBox (the 4bit SBox S_{4} for the 64bit variant the 8bit SBox S_{8} for the 128bit variant).
 AddConstants (AC): round constants derived using a 6bit LFSR are added into the state.
 AddRoundTweakey (ART): SKINNY is built using the TWEAKEY framework^{[95]}, round keys therefore depend on both the master key and the tweak and are called RoundTweakey. This operations adds such key material to half of the internal state.
 ShiftRows (SR): The rows are rotated to the right according to their index, i.e. the first row is left unchanged, the second is rotated by 1, the third by 2 and the third by 3. This operation is identical to the one in the AES except for the direction of the rotation.
 MixColumns (MC): Each column is multiplied by a binary matrix M given below.
The main idea behind this design is to provide as low an area in hardware as possible without sacrificing neither speed nor security. In particular, unlike for the NSA cipher SIMON, bounds are provided for the number of active SBoxes in any differential trail in both the singlekey and the relatedkey setting. These are obtained using a technique based on first transforming the existence of a trail into a MILP problem and then using a MILP solver to retrieve the result.
The components were chosen because of the good compromise they provide between cryptographic properties and hardware cost. The SBoxes can be computed using a simple circuit (the one computing S_{4} is given on the right) and the matrix M is a simple binary matrix:
Zorro
 Article: Block Ciphers that are Easier to Mask: How Far Can we Go?, CHES'13^{[90]}
 Authors: Benoit Gerard, Vincent Grosso, Maria NayaPlasencia, FrancoisXavier Standaert
 Target: Software
Zorro is a modified version of the AES intended to be easy to mask (like Zorro, the masked hero). To achieve this, fewer calls to the Sbox are made during each round and the Sbox has been modified. To compensate, the number of rounds has been increased to 24. This design also borrows ideas from LED: there is no key schedule but, instead, the addition of round constants at each round. Besides, the execution is split into "steps" of 4 rounds and the key is added only at the end of a step. This the operation AK (add key) which consists simply in xoring the master key. No security claims are made regarding related key attacks.
Each round is made of 4 operations:
 SB* which is a variant of the SubBytes operation where the Sbox is applied to one row of the 4x4 bytes internal state,
 AC is a round constant addition similar to the one used in LED,
 SR is identical to ShiftRows,
 MC is identical to MixColumns.
Much thought has been put in the design of the Sbox: while retaining good cryptographic properties, it minimizes the number of multiplications necessary to compute it. It is based on a small 4round Feistel cipher with mixing layer where the Feistel function is the monomial X^{3} in GF(2^{4}).
BitSliced SBoxes
All block ciphers with an SPN structure that use a bitsliced SBox are put in this category. We call "bitsliced SBox" a nonlinear layer consisting in the parallel application of several small nonlinear functions which is supposed to be implemented using basic bitwise operations such as XOR, AND and OR. While Mysterion is classified as AESlike in this list, it also fits in this category. Similarly, the Feistel networks RoadRunneR and SEA use bitsliced SBoxes in their Feistel functions.
Fantomas/Robin
 Article: LSDesigns: Bitslice Encryption for Efficient Masked Software Implementations, FSE'14^{[13]}
 Authors: Grosso, V., Leurent, G., Standaert, F. X., & Varıcı, K.
 Target: Software
These block ciphers are two instances of socalled "LSdesigns" where the internal state of the cipher is a matrix of s×L bits and where:
 the nonlinear layer consists in the parallel applications of a s×s bits permutation (the SBox) on each column of the matrix, and
 the linear layer consists in the application of a linear L×L bits permutation (the LBox) on each line of the matrix.
This structure is intended to ease masking and thus to help thwart sidechannel attacks when this cipher is implemented on a microcontroller. The SBoxes of both ciphers (Fantomas and Robin) were chosen so as to be efficiently implemented in a bitslice fashion.
Robin uses involutions as both its LBox and its SBox but it is not the case for Fantomas. As a consequence, Robin has more rounds. Both have a 8×8 bits SBox and a 16×16 bits LBox.
Noekeon
 Article: The Noekeon Block Cipher, Nessie Proposal^{[49]}
 Authors: Joan Daemen, Michaël Peeters, Gilles Van Assche, Vincent Rijmen
 Target: Software/Hardware
Noekeon is a SubstitutionPermutation Network operating on blocks of 128 bits using a 128bits key. It operates on 4 words of 32 bits except for the SBox layer, "Gamma", which operates on 4bits nibbles. The same round key is used in every round; how it is derived depends on whether relatedkey attacks must be considered or not. However, there exists relatedkey differentials for both key schedules^{[96]} It uses the following operations.
 Gamma: Consists in applying a 4bit involution SBox on nibbles independently. Each of the 32 nibbles considered in Gamma is made of the bits of index i in each of the 4 words for all i in [0, 31]. This leads to a simple bitslice implementation of this layer. Most choices for Gamma generated using the same design criteria would have lead to weak ciphers but the one chosen in Noekeon does not^{[96]}.
 Theta: A linear layer which mixes words with each other and operates at the byte level. It has a LaiMassey structure where the LaiMassey function is linear: . The round key is XORed between the 2steps of the LaiLassey operation.
 shift operations: Three of the four words are rotated by different offsets, namely 1, 5 and 2. Each rotations and their inverses are used.
A round constant is XORed in the internal state before applying Gamma during encryption. Since the components are involutionbased, decryption can be implemented using the same circuit as encryption. 16 rounds are used.
It is claimed to be suitable for implementation in hardware and on 8bit processors.
The best attack by the designers is a linear attack based on a 2rounds iterative linear trail covering 9 rounds, which is then extended to cover 12 rounds through key guessing.
PRIDE
 Article: Block Ciphers  Focus On the Linear Layer (feat. PRIDE), CRYPTO'14^{[97]}
 Authors: Martin R. Albrecht, Benedikt Driessen, Elif Bilge Kavun, Gregor Leander, Christof Paar and Tolga Yalcın
 Target: Software
PRIDE is the output of research focusing on the design of the linear layer in SubstitutionPermutation Networks. Its main target is 8bit microcontrollers. Specifically, the computer assisted search for components of the linear layer was optimized to look for permutations which can be efficiently implemented using the AVR instruction set.
To limit the overhead implied by the implementation of both encryption and decryption, its SBox is an involution. Furthermore, it is implemented in a bitsliced fashion and was chosen so as to minimize the number of instructions necessary to evaluate it.
The keyschedule is very similar to that of PRINCE: the master key is split in two halves, the first being used as whitening key and the second being used to derive subkeys XORed in the internal state at every round. However, unlike in PRINCE, the postwhitening key is the same as the prewhitening key and the subkeys are not derived by XORing round constants but by adding round constants on some bytes using a regular addition modulo 256.
Rectangle
 Article: RECTANGLE: A Bitslice UltraLightweight Block Cipher Suitable for Multiple Platforms, Science China Information Sciences'15^{[66]}
 Authors: Wentao Zhang, Zhenzhen Bao, Dongdai Lin, Vincent Rijmen, Bohan Yang, Ingrid Verbauwhede
 Target: Hardware and software
Rectangle is a substitution permutation network. Its state is represented as a 4×16 matrix. The nonlinear layer consists in the parallel application of a 4bit SBox on the columns of the state and the linear layer consists simply in applying a fixed rotation by a different amount on each row. There are two versions of this cipher. The first had a key schedule operating by storing the key in a matrix undergoing a round of encryption except that the SBox is only applied on the first column^{[98]}. It was vulnerable to a relatedkey differential attack against 19 rounds^{[99]}.
The latest version, as published in Science China'15^{[66]}, is not vulnerable to this attack anymore. Its keyschedule is different: it still relies on partially applying an SBox layer to a key state but the overall operation has now a generalized Feistel structure. Compared to the older version, the key schedule of the latest version also performs better in software.
Other SPNbased Structures
We put in this category the ciphers with a SPN structure which are not as close to the AES as the others, be it by the structure of the linear layer (e.g. PRESENT) of by their overall structure (e.g. PRINCE).
mCrypton
 Article: mCrypton – A Lightweight Block Cipher for Security of LowCost RFID Tags and Sensors, ISA 06^{[42]}
 Authors: Chae Hoon Lim and Tymur Korkishko
 Target: Hardware
This cipher is a derivative of CRYPTON, a candidate of the AES competition. It has a structure close to that of Rijndael: it is a SPN with an internal space organised like a 4x4 matrix of nibbles of 4 bits. A round consists in the application of an Sbox layer, a bit permutation within each column, a transposition of the matrix representing the state and, finally, xoring of the subkey. There are four different Sboxes, two being the inverse of the other two and they are all based on the inverse function in GF(2^{4}). Encryption and decryption are almost identical except for the key schedule.
MANTIS
 Article: The SKINNY Family of Block Ciphers and its LowLatency Variant MANTIS, CRYPTO'16 ^{[40]}
 Authors: Christof Beierle, Jérémy Jean, Stefan Kolbl, Gregor Leander, Amir Moradi, Thomas Peyrin, Yu Sasaki, Pascal Sasdrich, and Siang Meng Sim
 Target: Hardware
Mantis is a tweakable block cipher with a 64bit block size, 128bit key and a 64bit tweak. Much like PRINCE, from which it borrows the overall structure and the αreflexivity, it is optimized for low latency. The keyschedule is also borrowed from PRINCE in the sense that the master key is cut in two halves, the first being used as an input and output whitening key and the second as a round key. However, additional operations are performed to take the tweak into account. The round function uses the following functions which operate on a 4x4 matrix of 4bit nibbles (note that the last half of the rounds are the functionnal inverse of the first ones except for the round constants).
 MixColumns: Each column is multiplied by a 4x4 binary matrix M.
 PermuteCells: This operations plays the same role as the ShiftRow of the AES. However, it is more sophisticated than a mere rotation of the rows.
 AddTweakey: Adds k_{1} (the second half of the masterkey) along with some tweak material to the internal state.
 AddConstant: Round constants are added to the state. These were derived in a fashion very similar to those of PRINCE.
 SubCells: The internal state goes through a layer of identical 4bit SBoxes.
Several of the components, namely the SBox, the permutation used in PermuteCells and the matrix M have been borrowed from the lowenergy cipher Midori.
The security claim is the same as for PRINCE: an adversary with 2^{d} plaintext/ciphertext pair cannot recover the key in time less than 2^{126n} encryptions. Furthermore, while they do not claim relatedkey security because of the FX construction used, the designers do claim relatedtweak security.
PRESENT
 Article: PRESENT: An UltraLightweight Block Cipher, CHES 07^{[54]}
 Authors: A. Bogdanov, L.R. Knudsen, G. Leander, C. Paar, A. Poschmann, M.J.B. Robshaw, Y. Seurin, and C. Vikkelsoe
 Target: Hardware
This cipher is a SPN but, interestingly, it was not inspired by the AES. Indeed, while many SPNbased ciphers have permutation layers close in structure to that of the AES (see LED or mCrypton), that of PRESENT is completely different: it is bit oriented and is rather simple. It can be implemented in hardware using simple wiring. However, since bitoriented permutations are not softwarefriendly, the target of PRESENT is clearly a hardware implementation. Its Sbox was selected for its good cryptographic properties as well as for its small hardware footprint.
PRESENT is a very important design as it has been an inspiration for many others. For instance, its Sbox has also been reused by GOST revisited and LED as well as the lightweight hash function PHOTON. This cipher also inspired the design of two lightweight hash functions: DMPRESENT and SPONGENT.
While only PRESENT80 is described in the body of the CHES 07 article^{[54]}, PRESENT128 and its modified keyschedule are described in the appendix. This cipher has been standardized and is part of the ISO29192^{[100]} with CLEFIA.
PRINCE
 Article: PRINCE – A Lowlatency Block Cipher for Pervasive Computing Applications, ASIACRYPT 12^{[59]}
 Authors: Julia Borghoff, Anne Canteaut, Tim Guneysu, Elif Bilge Kavun, Miroslav Knezevic , Lars R. Knudsen, Gregor Leander, Ventzislav Nikov, Christof Paar, Christian Rechberger, Peter Rombouts, Søren S. Thomsen, and Tolga Yalcın
 Target: Hardware (low latency)
The main aim of the design of PRINCE is low latency.
There is no real key schedule: three 64 bits keys are derived from the 128 master key. Two are used as whitening keys and the third is simply xored in the internal state during encryption. To make the rounds behave differently from one another, different constants are xored in the internal state at each round. These constants RC_{i} (i=0,..,11) are such that RC_{i}⊕RC_{11i}=α where α is a constant derived from π. This property, combined with the fact that the first 5 rounds are the inverse of the last 5 mean that the decryption algorithm for key k is identical to an encryption with key k⊕α. This property is refered to as "αreflexivity".
The authors challenge the symmetric cryptography community to attack (roundsreduced versions of) this cipher and offer different rewards for "practical" attacks.
ARXBased SPN
SPARX
 Article: Design Strategies for ARX with Provable Bounds: SPARX and LAX^{[81]}
 Authors: Daniel Dinu, Léo Perrin, Aleksei Udovenko, Vesselin Velichkov, Johann Großschädl and Alex Biryukov
 Target: software
Disclosure: the maintainers of this webpage are amongst the designers of SPARX. A page dedicated to this algorithm is available on this website (here).
SPARX is a family of ARXbased 64 and 128bit block ciphers. Only addition modulo 2^{16}, 16bit XOR and 16bit rotations are needed to implement any version.
The SPARX ciphers have been designed according to the Long Trail Strategy put forward by its authors in the same paper. It can be seen as a counterpart of the WideTrail Strategy suitable for algorithms built using a large and weak SBox rather than a small strong one. This method allows the designers to bound the differential and linear trial probabilities, unlike for all other ARXbased designs. The nonlinearity is provided by SPECKEY, a 32bit block cipher identical to SPECK32 except for its key addition. The linear layer is very different from that of, say, the AES as it consists simply in a linear Feistel round for all versions.
Feistel Networks
ARXBased
ARXbased ciphers are designed using only modular Addition, Rotation and XOR. In particular, the only source of nonlinearity is the modular addition. Algorithms built in this fashion are usually faster and smaller than SBoxbased algorithms in software, as well as having some inherit security against sidechannel attacks as modular addition leaks less information than table lookups. However, modular addition is not as attractive for designing hardware optimized algorithms due to its latency and "large" input and output size.
The SPARX block cipher is ARXbased but, due to its having a SPN structure, is put in said category.
Chaskey Cipher
 Article: Chaskey: An Efficient MAC Algorithm for 32bit Microcontrollers, SAC'14^{[7]}
 Authors: Nicky Mouha, Bart Mennink, Anthony Van Herrewege, Dai Watanabe, Bart Preneel and Ingrid Verbauwhede
 Target: Software
Chaskey (primitive's website) is a lightweight MAC algorithm optimised for 32bit microcontrollers. It is based on a 128bit block cipher, the Chaskey cipher, which uses ARX operations and an EvenMansour structure. This means that there is no key schedule: the 128bit master key is XORed, then a public permutation is applied and then the master key is XORed again. This simplicity is possible at the cost of a weaker security claim as in e.g. PRINCE or PRIDE because a generic attack exists with a time complexity of about 2^{128}/D if the attacker obtains D plaintextciphertext pairs.
The code implementing it is very simple and is given below. It is similar to that of SipHash.
The original paper also suggests doubling the number of rounds of the Chaskey cipher to obtain an even more secure primitive, ChaskeyLTS (Long Term Security), with 16 rounds. It was later suggested^{[101]}, in reaction to Leurent's differentiallinear attack^{[102]}, to use a variant with 12 rounds called Chaskey12.
#include <stdint.h> #define ROTL(x,b) (uint32_t)( ((x) >> (32  (b)))  ( (x) << (b)) ) void encrypt(uint32_t v[4], uint32_t key[4]) { int i; for (i=0; i<4; i++) v[i] ^= key[i]; for (i=0; i<8; i++) { v[0] += v[1]; v[1]=ROTL(v[1], 5); v[1] ^= v[0]; v[0]=ROTL(v[0],16); v[2] += v[3]; v[3]=ROTL(v[3], 8); v[3] ^= v[2]; v[0] += v[3]; v[3]=ROTL(v[3],13); v[3] ^= v[0]; v[2] += v[1]; v[1]=ROTL(v[1], 7); v[1] ^= v[2]; v[2]=ROTL(v[2],16); } for (i=0; i<4; i++) v[i] ^= key[i]; }
HIGHT
 Article: HIGHT: A New Block Cipher Suitable for LowResource Device, CHES 06^{[16]}
 Authors: Deukjo Hong, Jaechul Sung, Seokhie Hong, Jongin Lim, Sangjin Lee, BonSeok Koo, Changhoon Lee, Donghoon Chang, Jesang Lee, Kitae Jeong, Hyun Kim, Jongsung Kim, and Seongtaek Chee
 Target: Hardware
HIGHT is an ARX based generalised Feistel network with whitening. The only operations used are addition and substraction modulo 2^{8}, xor and bitwise rotations. The subfunctions F_{0} and F_{1} consist in the xor of three different rotations of the input. The key schedule generates 8 bytes of whitening keys by selecting some bytes of the master key and 128 bytes of subkeys in a more complex way. Both during whitening and during encryption, addition and xor are used at the same time on different part of the internal state (see the round function on the right).
Unlike for instance TWINE, the permutation of the words after addition (or xoring) of the subkeys is a simple rotation.
The first author of HIGHT is also the first author of LEA.
LEA
 Article: LEA: A 128Bit Block Cipher for Fast Encryption on Common Processors, WISA 13^{[37]}
 Authors: Hong, D., Lee, J. K., Kim, D. C., Kwon, D., Ryu, K. H., and Lee, D. G.
 Target: Software
LEA is a 128bit block cipher operating on 4 branches of 32 bits each. The only operations used are 32bit modular addition, XOR and rotation (ARX structure): the designers suppose that "the usage of 32bit and 64bit processors will grow rapidly compared to 8bit and 16bit ones" (see specification^{[37]}, Section 1.1). The round function is described in the picture on the right. Note that the key is added in both datapath going in each modular additions.
The key schedule also follows the ARX paradigm: constants are added modulo 2^{32} to the key state and the different words are then rotated.
The first author of LEA is also the first author of HIGHT.
RC5
 Article: The RC5 Encryption Algorithm, FSE 95^{[63]}
 Authors: Ron Rivest
 Target: Software
RC5 is a an ARX (modular Addition, Rotation, Xor) twobranched Feistel network. It is "word oriented", meaning that all operations are performed over subblocks of size w; w being the bit length of one branch. Thus, RC5 can have a block size of 32, 64 or 128 corresponding respectively to w=16, w=32 and w=64. The key can be made of any number b of bytes between 0 and 255 and the number r of rounds is also a parameter so that an instance of RC5 should be denoted RC5w/r/b. Here, we fix w=32 and b=16 so that RC5r is a shortcut for RC532/r/16. Its most remarkable feature is the use of datadependent rotations.
The key schedule derives an array of subkeys from the master key and "magic constants" derived from the mathematical constants e and the golden ratio.
Like for XTEA, we provide a pseudocode for the encryption routine. It comes from Section 4.1 of the original paper^{[63]}. A is the left branch, B is the right one and S is the array of the subkeys.
A = A + S[0] B = B + S[1] for i = 1 to r do A = ((A ⊕ B) <<< B) + S[2×i] B = ((B ⊕ A) <<< A) + S[2×i+1]
It has been an inspiration for the AES competition finalist RC6. This algorithm is patented by RSA security.
SIMECK
 Article: The Simeck Family of Lightweight Block Ciphers, CHES'15^{[72]}
 Authors: Gangqiang Yang, Bo Zhu, Valentin Suder, Mark D. Aagaard, and Guang Gong
 Target: Hardware
SIMECK is a family of block ciphers heavily inspired by the SIMON family of block ciphers. Indeed, the round function is the same up to a change in the rotation indices: rotations by 1, 8 and 2 bits are replaced by rotations by 0, 5 and 1 bit. The key schedule reuses the round function, much like in SPECK, hence the name of the primitive.
The security claim of this cipher is based on that of SIMON: SIMECK is intended to be as secure as SIMON. Note that the designers of SIMECK are not affiliated to the National Security Agency (unlike the designers of SIMON and SPECK).
The change in the rotations and the key schedule allow an improved hardware implementation: SIMECK requires a smaller area than SIMON when implemented in hardware.
SIMON and SPECK
 Article: The SIMON and SPECK Families of Lightweight Block Ciphers, eprint.iacr.org, 2013^{[75]}
 Authors: Ray Beaulieu, Douglas Shors, Jason Smith, Stefan TreatmanClark, Bryan Weeks, and Louis Wingers (NSA)
 Target: Hardware (SIMON) and software (SPECK)
These ciphers have been designed by the American National Security Agency (NSA). They are both Feistel networks with two branches but differ by the design of their Feistel function. They are both almost ARX construction, meaning that they rely on Addition, word Rotation and Xor, although SIMON uses And gates instead of additions. Both perform exceptionnally well in both hardware and software, although SIMON is supposed to be more hardwareoriented and SPECK more softwareoriented. Unlike all other ciphers' specification, no security analysis whatsoever is provided.
SIMON
Hardwareoriented, this blockcipher relies only on the following operations: and, rotation, xor. It is a classical Feistel network where the Feistel function consists in applying basic operations on the branch, xoring the in subkey and then xoring the result with the other branch.
SPECK
Softwareoriented, this blockcipher relies only on the following operations: addition, rotation, xor (ARX construction). The structure of the round function is a typical ARX structure similar to the one of the block cipher Threefish used by the hash function Skein^{[103]}.
XTEA
 Article: Tea Extensions^{[87]}
 Authors: Needham R. and Wheeler D.
 Target: Software
XTEA is a cipher designed so as to be described by the smallest amount of code. It is an improvement of a previous design called TEA which had identical goals but several weaknesses. To illustrate the compactness of the Ccode describing encryption, we provide below a possible implementation (suggested on the wikipedia page of XTEA).
#include <stdint.h> /* take 64 bits of data in v[0] and v[1] and 128 bits of key[0]  key[3] */ void encipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) { unsigned int i; uint32_t v0=v[0], v1=v[1], sum=0, delta=0x9E3779B9; for (i=0; i < num_rounds; i++) { v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]); sum += delta; v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]); } v[0]=v0; v[1]=v1; }
Two Branched
In this category, we put all the Feistel networks operating on blocks of size 2n for which the Feistel function maps n bits to n bits that are not based on the ARX paradigm.
DESLX
 Article: New Lightweight DES Variants, FSE 07^{[12]}
 Authors: Gregor Leander, Christof Paar, Axel Poschmann, and Kai Schramm
 Target: Hardware
This cipher is a modified version of DES. The 8 Sboxes have been replaced by unique one to make it easier to implement. Besides, the Sbox was chosen so as to achieve better resilience against linear and differential attacks. Another modification is the use of a FX structure to increase the security: parts of the keys are used as whitening keys in the input and in the output.
The idea of using an old design from an era when hardware optimization was critical was also used in GOST revisited.
GOST revisited
 Article: 256 Bit Standardized Crypto for 650 GE – GOST Revisited, CHES 10^{[14]}
 Authors: Axel Poschmann, San Ling, and Huaxiong Wang
 Target: Hardware
The GOST used to be a sovietic counterpart for the American NIST. It still exists as a standards organization for countries of the former USSR. In cryptography, GOST usually refers to the block cipher GOST standard, a 64 bit twobranch Feistel network with a Feistel function using eight unspecified Sboxes. GOST revisited consists simply in the block cipher described in the GOST standard such that it uses eight copies of the PRESENT Sbox. The idea of using such an old design is to benefit from the cryptanalytic scrutiny it has already been subject to. Besides, the GOST cipher had already been standardized for 20 years when the paper was published. The approach consisting in modifying an old standard is similar to that of the designers of DESLX.
There is no real key schedule, different blocks of the master key are used at each round. The Feistel function is simply a modular addition of the key (modulo 2^{32}), an Sbox layer and rotation by 11bits. This very simple structure and the lack of a key schedule explain the very small hardware footprint of the cipher.
The authors compare the footprint of GOST using their Sbox layer and the one used by the Central Bank of Russian Federation and, interestingly, the difference is not so big (identical throughput and 800 or 1000 GE depending on the speed/area tradeoff).
ITUbee
 Article: ITUbee: A Software Oriented Lightweight Block Cipher, Lightweight Cryptography for Security and Privacy 13^{[21]}
 Authors: Ferhat Karakoç, Hüseyin Demirci, and A. Emre Harmancı
 Target: Software
ITUbee is a block cipher using 20 rounds of a Feistel structure with key whitening at the beginning and end of the encryption. Its structure is summarized in the figure on the right where:
 L is a multiplication by a simple 5x5 square matrix operating on bytes,
 S is a substitution layer using the SBox of the AES,
 F(x) = S(L(S(x))).
Its use of a Feistel function based on a small SPN is reminiscent of the Generalized Feistel Network Piccolo. Chunks of the master key are used directly during encryption; the only key schedule consists in adding round constant in a fashion similar to LED or PRINCE. Another Feistel Network with a SASASAS structure as its Feistel function was published later: RoadRunneR.
Its main features are low power consumption and low memory requirement in software (8bits microcontroller) according to simulations on the AVR ATiny45 microcontroller. The authors claim resilience against related key attacks. Unlike many lightweight block ciphers which have a block length of 64 bits, ITUbee uses blocks of 80 bits.
KASUMI/MISTY
MISTY
 Article: New Block Encryption Algorithm MISTY, Fast Software Encryption 97^{[45]}
 Authors: Minoru Matsui
 Target: Software and Hardware
MISTY is a set of two 64bit block ciphers using 4n rounds (usually, 4n=8) with a Feistel structure for MISTY1 and MISTYlike (i.e. the non linear permutation is applied on a branch directly) for MISTY2 along with specific key dependent transformation applied on the branches between the rounds. The structure of the nonlinear function is itself a 3round Feistel Network and the Feistel function used in this second layer has a MISTYlike structure. This recursive structure is shown in the picture on the right. At the final level, 7 and 9bit bijective SBoxes are used. While uncommon, this choice allows the SBoxes to be both APN and bent, a task significantly harder to achieve on 8bit^{[note 9]}.
The design criteria for MISTY is clearly stated:
 MISTY should have a numerical basis for its security,
 MISTY should be reasonably fast in software on any processor,
 MISTY should be sufficiently fast in hardware implementation.
The key schedule of MISTY reuses a component used during encryption, namely the socalled FI function corresponding to a 3round unbalanced MISTYlike structure using the 7 and 9bit SBoxes.
KASUMI
KASUMI is a variant of MISTY1 allowing a more efficient hardware implementation. Its specification can be obtained from the etsi.org website^{[22]}. It is referred to as A5/3 in this specification. It is identical to MISTY1 with 8 rounds (the default) except for its key schedule which simply rotates the bits of the master key and XORs round constants. This simplification lead to a vulnerability against relatedkey attacks^{[23]} which is not present in MISTY1.
LBlock
 Article: LBlock: A Lightweight Block Cipher, ACNS 11^{[31]}
 Authors: Wenling Wu and Lei Zhang
 Target: Hardware and Software
This Feistel Network has two branches of 32 bits and a "twist": the branch which is xored with the output of the F function is first rotated by 8 bits. The Feistel function is made of a xor with a subkey, a layer of 8 distinct 4x4 Sboxes and a word permutation shuffling 4bit words. The permutation used in the Feistel function and the bit rotation of one of the branch make this design very similar to TWINE as explained in the TWINE specification^{[84]}.
The key schedule involves two additional Sboxes which are different from the ones used in the Feistel function.
RoadRunneR
 Article: RoadRunneR: A Small And Fast Bitslice Block Cipher For Low Cost 8bit Processors, LightSec 2015^{[67]}
 Authors: Adnan Baysal and Sühap Şahin
 Target: Software
RoadRunneR is a Feistel Network which uses a SPN as its Feistel function. The nonlinear layer of the Feistel funciton is based on the bitsliced implementation of its SBox as can be seen for instance in the LS strategy introduced for Robin and Fantomas. The designers had the following goals:
 Implementation efficiency in 8bit CPUs,
 No table and SRAM usage,
 Low decryption overhead,
 Provable security like in wide trail design strategy.
The key schedule is very simple: 32bit chunks of the master key are used one after another. Once the end of the key is reached, the first bits are used again. Round constants are added to prevent slide attacks.
The Feistel function has a SPN structure consisting in 4 SBox layers, 3 linear layers (much like ITUbee) and 3 key additions. The 4bit SBox was chosen for the very simple circuit that can be used to compute it as well as its good cryptographic properties. It was found in a previous work by Ullrich et al.^{[94]} and is also used by Mysterion. The linear layer is applied on 4 bytes separately and consists in the xor of three different rotations of its input (in a fashion similar to the F_{0} and F_{1} functions of HIGHT): .
SEA
 Article: SEA: A Scalable Encryption Algorithm for Small Embedded Applications, Smart Card Research and Advanced Applications 06^{[69]}
 Authors: FrancoisXavier Standaert, Gilles Piret, Neil Gershenfeld, and JeanJacques Quisquater
 Target: Software and Hardware
SEA is a block cipher which can have an arbitrary block size n (as long as n=6b for some b), word size w and number of rounds n_{r}. A complete description of the algorithm (round function and update of the key) is given on the figure on the right which comes from the original paper^{[69]}. It is based on the following operations:
 Bitwise XOR
 Application of an Sbox S. Interestingly, S is a 3x3 Sbox.
 Rotation of the words in a vector of words
 Bit rotation inside a word
 Addition modulo 2^{b}
Generalized Feistel Networks (GFN)
CLEFIA
 Article: The 128Bit Blockcipher CLEFIA, FSE 07^{[9]}
 Authors: Taizo Shirai, Kyoji Shibutani, Toru Akishita, Shiho Moriai, and Tetsu Iwata
 Target: Hardware and Software
This cipher is intended for use in DRM protocols. Its "lightweightness" can be debated as an area of 4950 GE is significant. The designers of CLEFIA worked for Sony and some of them were involved in the creation of Piccolo.
CLEFIA has been standardized and is part of the ISO29192^{[100]} with PRESENT.
Piccolo
 Article: Piccolo: an ultralightweight blockcipher, CHES 11^{[51]}
 Authors: Shibutani, K., Isobe, T., Hiwatari, H., Mitsuda, A., Akishita, T., & Shirai, T.
 Target: Hardware
Piccolo is a GFS with 4 16bits branches which employs a sophisticated permutation for the diffusion layer instead of a simple shift (like TWINE and as opposed to CLEFIA) as well as whitening. Note that although the branches of the Fesitel structure are made of 16 bits, the permutation operates on words of 8 bits.
The Feistel function is a small SPN where the permutation layer is a multiplication by the same matrix as the one used in the MixNibbles operation in the AES and KLEIN  although in a different field. The 4x4 Sbox was designed especially for Piccolo and, while still having decent nonlinearity and differential uniformity, has a tiny hardware footprint: it can be implemented using only 4 NOR gates, 3 XOR gates and 1 XNOR gate. A small SPN is also used as the Feistel function in ITUbee.
The designers work for Sony and several of them worked on CLEFIA.
TWINE
 Article: TWINE: A Lightweight, Versatile Block Cipher, Workshop on Lightweight Crypto 11^{[84]}
 Authors: Tomoyasu Suzaki, Kazuhiko Minematsu, Sumio Morioka, and Eita Kobayashi
 Target: Hardware and software
TWINE is a generalised Feistel structure (GFS) with 16 4bits branches. The Feistel function, called 8 times per round, consists simply in xoring a subkey and applying a 4x4 Sbox. The key schedule itself is also a GFS.
The diffusion layer is not a simple circular shift, like for instance in CLEFIA and HIGHT, it is a more sophisticated permutation to speedup diffusion. It is based on Suzaki et al.'s Improving the Generalized Feistel (FSE 10)^{[104]}: the permutation used in TWINE requires only half as much rounds as a circular shift for a one subblock difference to diffuse to all the subblocks. The Sbox is based on the inverse function in GF(2^{4}), just like the one of the AES which is based on the inverse function in GF(2^{8}).
The designers of TWINE worked at NEC Corporation, a Japanese company. While a priori different due to its 2branched nature, LBlock actually has a structure very similar to TWINE.
Other Designs
KTANTAN and KATAN
 Article: KATAN and KTANTAN — A Family of Small and Efficient HardwareOriented Block Ciphers, CHES 09^{[27]}
 Authors: Christophe De Cannière, Orr Dunkelman, and Miroslav Knezevic
 Target: Hardware
The optimization of the physical footprint is at the core of these two designs, at the cost of some speed. The only difference between the two families is the key schedule: in KTANTAN, the key is included in the hardware and cannot be changed. The design is based on a variant of the stream cipher trivium called bivium.
The structure of the encryption is best described by the designers themselves:
The structure of the KATAN and the KTANTAN ciphers is very simple — the plaintext is loaded into two registers (whose lengths depend on the block size). Each round, several bits are taken from the registers and enter two nonlinear Boolean functions. The output of the Boolean functions is loaded to the least significant bits of the registers (after they were shifted). Of course, this is done in an invertible manner. To ensure sufficient mixing, 254 rounds of the cipher are executed.
Several attacks based on MeetintheMiddle related concepts have been successfully applied on these ciphers^{[29]}^{[30]}. They exploit the slow diffusion of the key material to the internal state throughout the rounds.
The hash function QUARK borrows ideas from these ciphers.
Notes
 ↑ Since the Sbox used has better properties than the ones of the DES, attacks on DES may not be applicable to DESLX. Furthermore, no attack exists (to the best of our knowledge) on DESLX with its full FX structure.
 ↑ ^{2.0} ^{2.1} ^{2.2} ^{2.3} ^{2.4} ^{2.5} ^{2.6} ^{2.7} ^{2.8} To the best of our knowledge.
 ↑ ^{3.0} ^{3.1} ^{3.2} Encryption only.
 ↑ The figures for Midori correspond to an encryptiononly implementation.
 ↑ ^{5.0} ^{5.1} Note that the implementation proposed uses a 10 MHz frequency (unlike the other ciphers in this table).
 ↑ ^{6.0} ^{6.1} The paper in which Mysterion was introduced does not describe a key schedule, only a round function (and a number of round).
 ↑ The blocksize of SEA can actually be chosen arbitrarily among multiples of 6. 96 bits is the smallest size considered in the paper about the hardware implementation of SEA (MSQ07).
 ↑ ^{8.0} ^{8.1} Note that SKINNY is built using the TWEAKEY framework which makes little distinction between the key and the tweak. Thus, the key sizes actually correspond to the sum of the key and the tweak length.
 ↑ In fact, whether an 8bit APN permutation exist is still an open problem.
References
 ↑ Cazorla, M., Marquet, K., & Minier, M. (2013). Survey and Benchmark of Lightweight Block Ciphers for Wireless Sensor Networks. IDEA, 64(128), 34. pdf at eprint.iacr.org
 ↑ ^{2.0} ^{2.1} Daemen, J., & Rijmen, V. (1998, June). AES proposal: Rijndael. In First Advanced Encryption Standard (AES) Conference.pdf at csci.csusb.edu
 ↑ Mala, H., Dakhilalian, M., Rijmen, V., & ModarresHashemi, M. (2010). Improved impossible differential cryptanalysis of 7round AES128. In Progress in CryptologyINDOCRYPT 2010 (pp. 282291). Springer Berlin Heidelberg. pdf at springer.com
 ↑ Biryukov, A., & Khovratovich, D. (2009). Relatedkey Cryptanalysis of the Full AES192 and AES256. In Advances in Cryptology–ASIACRYPT 2009 (pp. 118). Springer Berlin Heidelberg. pdf at springer.com
 ↑ Bogdanov, A., Khovratovich, D., & Rechberger, C. (2011). Biclique cryptanalysis of the full AES. In Advances in Cryptology–ASIACRYPT 2011 (pp. 344371). Springer Berlin Heidelberg. pdf at kuleuven.be
 ↑ ^{6.0} ^{6.1} ^{6.2} ^{6.3} ^{6.4} ^{6.5} ^{6.6} ^{6.7} ^{6.8} ECRYPT European Network of Excellence in Cryptology II Lightweight Cipher Lounge, http://www.ecrypt.eu.org/lightweight/index.php/Block_ciphers
 ↑ ^{7.0} ^{7.1} Mouha, N., Mennink, B., Van Herrewege, A., Watanabe, D., Preneel, B., & Verbauwhede, I. (2014). Chaskey: An Efficient MAC Algorithm for 32bit Microcontrollers. In Selected Areas in Cryptography  SAC 2014 (pp. 306323). Springer International Publishing. pdf at kuleuven.be
 ↑ Leurent, G. (2015). Differential and Linear Cryptanalysis of ARX with Partitioning for Reduced Data Complexity. In Proceedings of Early Symmetric Crypto 2015 (p. 75). ISBN 9789995981419. pdf at cryptolux.org
 ↑ ^{9.0} ^{9.1} Shirai, T., Shibutani, K., Akishita, T., Moriai, S., & Iwata, T. (2007, January). The 128bit blockcipher CLEFIA. In Fast software encryption (pp. 181195). Springer Berlin Heidelberg. pdf at psu.edu
 ↑ Li, Y., Wu, W., & Zhang, L. (2012). Improved integral attacks on reducedround CLEFIA block cipher. In Information Security Applications (pp. 2839). Springer Berlin Heidelberg. pdf at springer
 ↑ Tezcan, C. (2010). The improbable differential attack: Cryptanalysis of reduced round CLEFIA. In Progress in CryptologyINDOCRYPT 2010 (pp. 197209). Springer Berlin Heidelberg.
 ↑ ^{12.0} ^{12.1} Leander, G., Paar, C., Poschmann, A., & Schramm, K. (2007, January). New lightweight DES variants. In Fast Software Encryption (pp. 196210). Springer Berlin Heidelberg. pdf at springer
 ↑ ^{13.0} ^{13.1} ^{13.2} Grosso, V., Leurent, G., Standaert, F. X., & Varıcı, K. (2014, March). LSdesigns: Bitslice encryption for efficient masked software implementations. In Fast Software Encryption (pp. 1837). Springer Berlin Heidelberg. pdf at hal.inria.fr
 ↑ ^{14.0} ^{14.1} ^{14.2} Poschmann, A., Ling, S., & Wang, H. (2010). 256 bit standardized crypto for 650 GE – GOST revisited. In Cryptographic Hardware and Embedded Systems, CHES 2010 (pp. 219233). Springer Berlin Heidelberg. pdf at springer
 ↑ Dinur, I., Dunkelman, O., & Shamir, A. (2012, January). Improved attacks on full GOST. In Fast Software Encryption (pp. 928). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{16.0} ^{16.1} . Cite error: Invalid
<ref>
tag; name "HLHS06" defined multiple times with different content  ↑ Zhang, P., Sun, B., & Li, C. (2009). Saturation attack on the block cipher HIGHT. In Cryptology and network security (pp. 7686). Springer Berlin Heidelberg. pdf at springer
 ↑ Özen, 0., Varıcı, K., Tezcan, C., & Kocair, C. (2009). Lightweight Block Ciphers Revisited: Cryptanalysis of Reduced Round PRESENT and HIGHT. In Proceedings of the 14th Australasian Conference, ACISP 2009 Brisbane, Australia, July 13, 2009 (pp 90107). SpringerVerlag Berlin Heidelberg. pdf at springer.com
 ↑ Koo, B., Hong, D., & Kwon, D. (2011). Relatedkey attack on the full HIGHT. In Information Security and CryptologyICISC 2010 (pp. 4967). Springer Berlin Heidelberg. pdf at springer
 ↑ Hong, D., Koo, B., & Kwon, D. (2012). Biclique attack on the full HIGHT. In Information Security and CryptologyICISC 2011 (pp. 365374). Springer Berlin Heidelberg. pdf at springer
 ↑ ^{21.0} ^{21.1} Karakoç, F., Demirci, H., & Harmancı, A. E. (2013). ITUbee: a software oriented lightweight block cipher. In Lightweight Cryptography for Security and Privacy (pp. 1627). Springer Berlin Heidelberg. pdf at springer.com
 ↑ ^{22.0} ^{22.1} ETSI (201410). Universal Mobile Telecommunications System (UMTS); LTE; 3G Security; Specification of the 3GPP confidentiality and integrity algorithms; Document 2: Kasumi specification (3GPP TS 35.202 version 12.0.0 Release 12). pdf at etsi.org
 ↑ ^{23.0} ^{23.1} Dunkelman, O., Keller, N., & Shamir, A. (2010). A practicaltime relatedkey attack on the KASUMI cryptosystem used in GSM and 3G telephony. In Advances in Cryptology–CRYPTO 2010 (pp. 393410). Springer Berlin Heidelberg. pdf at math.huji.ac.il
 ↑ ^{24.0} ^{24.1} ^{24.2} ^{24.3} Gong, Z., Nikova, S., & Law, Y. W. (2012). KLEIN: a new family of lightweight block ciphers. In RFID. Security and Privacy (pp. 118). Springer Berlin Heidelberg. pdf at eemcs.utwente.nl
 ↑ Aumasson, J. P., NayaPlasencia, M., & Saarinen, M. J. O. (2011). Practical attack on 8 rounds of the lightweight block cipher KLEIN. In Progress in Cryptology–INDOCRYPT 2011 (pp. 134145). Springer Berlin Heidelberg. pdf at springer
 ↑ Lallemand, V., & NayaPlasencia, M. (2014). Cryptanalysis of KLEIN (Full version). IACR Cryptology ePrint Archive, 2014, 90. pdf at eprint.iacr.org
 ↑ ^{27.0} ^{27.1} ^{27.2} De Canniere, C., Dunkelman, O., & Knežević, M. (2009). KATAN and KTANTAN—a family of small and efficient hardwareoriented block ciphers. In Cryptographic Hardware and Embedded SystemsCHES 2009 (pp. 272288). Springer Berlin Heidelberg. pdf at kuleuven.be
 ↑ Albrecht, M. R., & Leander, G. (2013, January). An allinone approach to differential cryptanalysis for small block ciphers. In Selected Areas in Cryptography (pp. 115). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{29.0} ^{29.1} Zhu, B., & Gong, G (2011). Multidimensional MeetintheMiddle Attack and Its Applications to KATAN32/48/64. pdf at eprint.iacr.org
 ↑ ^{30.0} ^{30.1} Bogdanov, A., & Rechberger, C. (2011, January). A 3subset meetinthemiddle attack: cryptanalysis of the lightweight block cipher KTANTAN. In Selected Areas in Cryptography (pp. 229240). Springer Berlin Heidelberg. pdf at dtu.dk
 ↑ ^{31.0} ^{31.1} ^{31.2} Wu, W., & Zhang, L. (2011, January). LBlock: a lightweight block cipher. In Applied Cryptography and Network Security (pp. 327344). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ Minier, M., & NayaPlasencia, M. (2012). A related key impossible differential attack against 22 rounds of the lightweight block cipher LBlock. Information Processing Letters, 112(16), 624629. pdf at ac.elscdn.com
 ↑ Soleimany, H., & Nyberg, K. (2012). ZeroCorrelation Linear Cryptanalysis of ReducedRound LBlock. IACR Cryptology ePrint Archive, 2012, 570. pdf at eprint.iacr.org
 ↑ Sasaki, Y., & Wang, L. (2013). Comprehensive study of integral analysis on 22round LBlock. In Information Security and Cryptology–ICISC 2012 (pp. 156169). Springer Berlin Heidelberg. pdf at springer
 ↑ Liu, Y., Gu, D., Liu, Z., & Li, W. (2012). Impossible differential attacks on reducedround LBlock. In Information Security Practice and Experience (pp. 97108). Springer Berlin Heidelberg. pdf at springer
 ↑ Boura, C., Minier, M., NayaPlasencia, M., & Suder, V. (2014). Improved impossible differential attacks against roundreduced LBlock. pdf at hal.archivesouvertes.fr
 ↑ ^{37.0} ^{37.1} ^{37.2} Hong, D., Lee, J. K., Kim, D. C., Kwon, D., Ryu, K. H., & Lee, D. G. (2014). LEA: A 128bit block cipher for fast encryption on common processors. In Information Security Applications (pp. 327). Springer International Publishing. pdf at springer.com
 ↑ ^{38.0} ^{38.1} ^{38.2} ^{38.3} ^{38.4} Guo, J., Peyrin, T., Poschmann, A., & Robshaw, M. (2011). The LED block cipher. In Cryptographic Hardware and Embedded Systems–CHES 2011 (pp. 326341). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{39.0} ^{39.1} Dinur, I., Dunkelman, O., Keller, N., & Shamir (2013), A. Key Recovery Attacks on 3round EvenMansour, 8step LED128, and Full AES 2. pdf at eprint.iacr.org
 ↑ ^{40.0} ^{40.1} ^{40.2} ^{40.3} ^{40.4} ^{40.5} Beierle, C., Jean, J., Kölbl, S., Leander, G., Moradi, A., Peyrin, T., Sasaki, Y., Sasdrich, P. & Sim, S. M. (2016, August). The SKINNY family of block ciphers and its lowlatency variant MANTIS. In Annual Cryptology Conference (pp. 123153). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ Dobraunig, C., Eichlseder, M., Kales, D., & Mendel, F. (2016). Practical Key Recovery Attack on MANTIS_{5}, IACR Cryptology ePrint Archive, 2016, 754. pdf at eprint.iacr.org
 ↑ ^{42.0} ^{42.1} ^{42.2} Lim, C. H., & Korkishko, T. (2006). mCrypton–A lightweight block cipher for security of lowcost RFID tags and Sensors. In Information Security Applications (pp. 243258). Springer Berlin Heidelberg. pdf at springer
 ↑ ^{43.0} ^{43.1} Yonglin, H. & Dongxia, B. (2013). A Meetinthemiddle Attack on RoundReduced mCrypton. Cryptology ePrint Archive, Report 2013/756. pdf at eprint.iacr.org
 ↑ ^{44.0} ^{44.1} ^{44.2} ^{44.3} Banik S., Bogdanov, A., Isobe, T., Shibutani, K., Hiwatari, H., Akishita, T., & Regazzoni, F. (2015). Midori: A Block Cipher for Low Energy. In Advances in Cryptology–ASIACRYPT 2015 (To appear). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{45.0} ^{45.1} Matsui, M. (1997, January). New block encryption algorithm MISTY. In Fast Software Encryption (pp. 5468). Springer Berlin Heidelberg. pdf at googlecode.com
 ↑ Todo, Y. (2015). Integral Cryptanalysis on Full MISTY1. In Advances in CryptologyCRYPTO 2015 (pp. 413432). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ BarOn, A. (2015). A 2^{70} Attack on the Full MISTY1. IACR Cryptology ePrint Archive, 2015, 746. pdf at eprint.iacr.org
 ↑ ^{48.0} ^{48.1} Journault, A., Standaert, F.X., & Varici, K. (2015) Proceedings of the 9th International Workshop on Coding and Cryptography, WCC 2015, Paris, France. extended abstract at uclouvain.be.
 ↑ ^{49.0} ^{49.1} ^{49.2} Joan Daemen, Michaël Peeters, Gilles Van Assche, Vincent Rijmen (2000). Nessie Proposal: Noekeon, First Open Nessie Workshop. pdf at noekeon.org
 ↑ Z’aba, M. R., Raddum, H., Henricksen, M., & Dawson, E. (2008, January). Bitpattern based integral attack. In Fast Software Encryption (pp. 363381). Springer Berlin Heidelberg. pdf at springer.com
 ↑ ^{51.0} ^{51.1} ^{51.2} Shibutani, K., Isobe, T., Hiwatari, H., Mitsuda, A., Akishita, T., & Shirai, T. (2011). Piccolo: an ultralightweight blockcipher. In Cryptographic Hardware and Embedded Systems–CHES 2011 (pp. 342357). Springer Berlin Heidelberg. pdf at springer
 ↑ Wang, Y., Wu, W., & Yu, X. (2012). Biclique cryptanalysis of reducedround piccolo block cipher. In Information Security Practice and Experience (pp. 337352). Springer Berlin Heidelberg. pdf at springer
 ↑ Minier, M. (2013). On the Security of Piccolo Lightweight Block Cipher against RelatedKey Impossible Differentials. In Progress in Cryptology–INDOCRYPT 2013 (pp. 308318). Springer International Publishing. pdf at springer.com
 ↑ ^{54.0} ^{54.1} ^{54.2} Bogdanov, A., Knudsen, L. R., Leander, G., Paar, C., Poschmann, A., Robshaw, M. J., ... & Vikkelsoe, C. (2007). PRESENT: An ultralightweight block cipher. In Cryptographic Hardware and Embedded SystemsCHES 2007 (pp. 450466). Springer Berlin Heidelberg. pdf at springer
 ↑ Collard, B., & Standaert, F. X. (2009). A statistical saturation attack against the block cipher PRESENT. In Topics in Cryptology–CTRSA 2009 (pp. 195210). Springer Berlin Heidelberg. pdf at uclouvain.be
 ↑ Cho, J. Y. (2010). Linear cryptanalysis of reducedround PRESENT. In Topics in CryptologyCTRSA 2010 (pp. 302317). Springer Berlin Heidelberg. pdf at springer.com
 ↑ Blondeau, C. & Nyberg, K. (2014). Links Between Truncated Differential and Multidimensional Linear Properties of Block Ciphers and Underlying Attack Complexities. In Advances in Cryptology—EUROCRYPT'14 (To Appear). Springer Berlin Heidelberg. pdf at aalto.fi
 ↑ Poschmann, A. Lightweight Cryptography: Cryptographic Engineering for a Pervasive World. PhD Thesis from Faculty of Electrical Engineering and Information Technology RuhrUniversity Bochum, Germany. pdf at eprint.iacr.org
 ↑ ^{59.0} ^{59.1} ^{59.2} ^{59.3} Borghoff, J., Canteaut, A., Güneysu, T., Kavun, E. B., Knezevic, M., Knudsen, L. R., ... & Yalçın, T. (2012). PRINCE–A LowLatency Block Cipher for Pervasive Computing Applications. In Advances in Cryptology–ASIACRYPT 2012 (pp. 208225). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ Soleimany, H., Blondeau, C., Yu, X., Wu, W., Nyberg, K., Zhang, H., ... & Wang, Y. (2013). Reflection Cryptanalysis of PRINCElike Ciphers. FSE. 13 pdf at aalto.fi
 ↑ Canteaut, A., NayaPlasencia, M., & Vayssiere, B. (2013). Sieveinthemiddle: Improved MITM attacks. In Advances in Cryptology–CRYPTO 2013 (pp. 222240). Springer Berlin Heidelberg. pdf at hal.inria.fr
 ↑ Anne Canteaut, Thomas Fuhr, Henri Gilbert, María NayaPlasencia and JeanRené Reinhard (2014). Multiple Differential Cryptanalysis of RoundReduced PRINCE (Full version), IACR Cryptology ePrint Archive, 2014, 089. pdf at eprint.iacr.org
 ↑ ^{63.0} ^{63.1} ^{63.2} Rivest, R. L. (1995, January). The RC5 encryption algorithm. In Fast Software Encryption (pp. 8696). Springer Berlin Heidelberg. pdf at csail.mit.edu
 ↑ Biryukov, A., & Kushilevitz, E. (1998). Improved cryptanalysis of RC5. In Advances in Cryptology—EUROCRYPT'98 (pp. 8599). Springer Berlin Heidelberg. pdf at springer
 ↑ Borst, J., Preneel, B., & Vandewalle, J. (1999, January). Linear Cryptanalysis of RC5 and RC6. In Fast Software Encryption (pp. 1630). Springer Berlin Heidelberg. pdf at esat.kuleuven.be
 ↑ ^{66.0} ^{66.1} ^{66.2} ^{66.3} ^{66.4} Wentao Zhang, Zhenzhen Bao, Dongdai Lin, Vincent Rijmen, BoHan Yang, Ingrid VerBauwhede. RECTANGLE: a bitslice lightweight block cipher suitable for multiple platforms. Sci China Inf Sci, 2015, 58: 122103(15). pdf at eprint.iacr.org
 ↑ ^{67.0} ^{67.1} Baysal, A., & Ş., Sühap. (2015). RoadRunneR: A Small And Fast Bitslice Block Cipher For Low Cost 8bit Processors. LightSec 2015. pdf at eprint.iacr.org
 ↑ Leander, G., Minaud, B., & Rønjom, S. (2015). A generic approach to invariant subspace attacks: Cryptanalysis of Robin, iSCREAM and Zorro. In Advances in CryptologyEUROCRYPT 2015 (pp. 254283). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{69.0} ^{69.1} ^{69.2} Standaert, F. X., Piret, G., Gershenfeld, N., & Quisquater, J. J. (2006). SEA: A scalable encryption algorithm for small embedded applications. In Smart Card Research and Advanced Applications (pp. 222236). Springer Berlin Heidelberg. pdf at springer
 ↑ This figure corresponds to the datapath only, the plaintext and the key have to be stored elsewhere.
 ↑ Mace, F., Standaert, F. X., & Quisquater, J. J. (2007, July). ASIC implementations of the block cipher sea for constrained applications. In Proceedings of the Third International Conference on RFID SecurityRFIDSec (pp. 103114). pdf at psu.edu
 ↑ ^{72.0} ^{72.1} ^{72.2} Yang, G., Zhu, B., Suder, V., Aagaard, M.D., & Gong, G. (2015). The Simeck Family of Lightweight Block Ciphers. In Cryptographic Hardware and Embedded Systems–CHES 2011 (pp. 342357). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ Kölbl, Stefan, & Roy, Arnab (2015). A Brief Comparison of Simon and Simeck, IACR Cryptology ePrint Archive, 2015, 706. pdf at eprint.iacr.org
 ↑ Qiao, K., Hu, L., & Sun, S. (2015). Differential Security Evaluation of Simeck with Dynamic Keyguessing Techniques. IACR Cryptology ePrint Archive, 2015, 902. pdf at eprint.iacr.org
 ↑ ^{75.0} ^{75.1} ^{75.2} ^{75.3} ^{75.4} Beaulieu, R., Shors, D., Smith, J., TreatmanClark, S., Weeks, B., & Wingers, L. The SIMON and SPECK Families of Lightweight Block Ciphers. pdf at eprint.iacr.org
 ↑ ^{76.0} ^{76.1} Alex Biryukov, Arnab Roy, and Vesselin Velichkov (2014). Differential Analysis of Block Ciphers SIMON and SPECK, FSE'14 (To appear). pdf at cryptolux.org
 ↑ Ning Wang, Xiaoyun Wang, Keting Jia and Jingyuan Zhao (2014). Improved Differential Attacks on Reduced SIMON Versions, IACR Cryptology ePrint Archive, 2014, 448. pdf at eprint.iacr.org
 ↑ Farzaneh Abed, Eik List, Stefan Lucks and Jakob Wenzel (2013). Differential and Linear Cryptanalysis of ReducedRound Simon, IACR Cryptology ePrint Archive, 2013, 526 pdf at eprint.iacr.org
 ↑ ^{79.0} ^{79.1} Javad Alizadeh, Hoda A. Alkhzaimi, Mohammad Reza Aref, Nasour Bagheri, Praveen Gauravaram and Martin M. Lauridsen (2014). Improved Linear Cryptanalysis of Round Reduced SIMON, IACR Cryptology ePrint Archive, 2014, 681. pdf at eprint.iacr.org
 ↑ Chen, H., & Wang, X. (2015). Improved Linear Hull Attack on RoundReduced Simon with Dynamic Keyguessing Techniques, IACR Cryptology ePrint Archive, 2015, 666. pdf at eprint.iacr.org
 ↑ ^{81.0} ^{81.1} ^{81.2} Dinu, D., Perrin, L., Udovenko, A., Velichkov, V., Großschädl, J. & Biryukov, A. (2016). Design Strategies for ARX with Provable Bounds: SPARX and LAX. In Advances in Cryptology–ASIACRYPT 2016 (pp 484513). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ Dinur, I. (2014). Improved Differential Cryptanalysis of RoundReduced Speck, IACR Cryptology ePrint Archive, 2014, 320. pdf at eprint.iacr.org
 ↑ Farzaneh Abed, Eik List, Stefan Lucks and Jakob Wenzel (2013). Cryptanalysis of the Speck Family of Block Ciphers, IACR Cryptology ePrint Archive, 2013, 568. pdf at eprint.iacr.org
 ↑ ^{84.0} ^{84.1} ^{84.2} ^{84.3} Suzaki, T., Minematsu, K., Morioka, S., & Kobayashi, E. (2011). Twine: A lightweight, versatile block cipher. In ECRYPT Workshop on Lightweight Cryptography (pp. 146169). pdf from nec.co.jp
 ↑ ^{85.0} ^{85.1} Çoban, M., Karakoç, F., & Boztaş, Ö. (2012). Biclique cryptanalysis of TWINE. In Cryptology and Network Security (pp. 4355). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{86.0} ^{86.1} Wang, Y., & Wu, W. (2014, January). Improved Multidimensional ZeroCorrelation Linear Cryptanalysis and Applications to LBlock and TWINE. In Information Security and Privacy (pp. 116). Springer International Publishing. pdf at springer.com
 ↑ ^{87.0} ^{87.1} Needham, R. M., & Wheeler, D. J. (1997). Tea extensions.
 ↑ Lu, J. (2009). Relatedkey rectangle attack on 36 rounds of the XTEA block cipher. International Journal of Information Security, 8(1), 111. pdf at springer.com
 ↑ Sekar, G., Mouha, N., Velichkov, V., & Preneel, B. (2011). Meetinthemiddle attacks on reducedround XTEA. In Topics in Cryptology–CTRSA 2011 (pp. 250267). Springer Berlin Heidelberg. pdf at springer.com
 ↑ ^{90.0} ^{90.1} Gérard, B., Grosso, V., NayaPlasencia, M., & Standaert, F. X. (2013). Block Ciphers that are Easier to Mask: How Far Can we Go?. CHES 2013. pdf at eprint.iacr.org
 ↑ Guo, J., Nikolic, I., Peyrin, T., & Wang, L. Cryptanalysis of Zorro. Cryptology ePrint Archive, Report 2013/713 pdf at eprint.iacr.org
 ↑ Biryukov, A. (2005). A new 128bit key stream cipher LEX. eSTREAM, ECRYPT Stream Cipher Project, Report, 13, 2005. pdf at ecrypt.eu.org
 ↑ Nyberg, K. (1994, January). Differentially uniform mappings for cryptography. In Advances in cryptology—Eurocrypt’93 (pp. 5564). Springer Berlin Heidelberg. pdf at science.unitn.it
 ↑ ^{94.0} ^{94.1} Markus Ullrich, Christophe De Canniere, Sebastiaan Indesteege, Özgül Küçük, Nicky Mouha, and Bart Preneel. Finding optimal bitsliced implementations of 4×4bit sboxes. In SKEW 2011 Symmetric Key Encryption Workshop, Copenhagen, Denmark, pages 16–17, 2011.
 ↑ Jean, J., Nikolić, I., & Peyrin, T. (2014, December). Tweaks and keys for block ciphers: the TWEAKEY framework. In International Conference on the Theory and Application of Cryptology and Information Security (pp. 274288). Springer Berlin Heidelberg. pdf at eprint.iacr.org
 ↑ ^{96.0} ^{96.1} Knudsen, L. R., & Raddum, H. (2001). On noekeon. Report for the NESSIE project. pdf at kuleuven.be
 ↑ Martin R. Albrecht, Benedikt Driessen, Elif Bilge Kavun, Gregor Leander, Christof Paar and Tolga Yalcın (2014). Block Ciphers  Focus On the Linear Layer (feat. PRIDE), Full Version, IACR Cryptology ePrint Archive, 2014, 453. pdf at eprint.iacr.org
 ↑ Zhang, W., Bao, Z., Lin, D., Rijmen, V., Yang, B. & Verbauwhede, I. (2014). RECTANGLE: A Bitslice UltraLightweight Block Cipher Suitable for Multiple Platforms. Cryptology ePrint Archive, Report 2014/084, version 20140207:151850. pdf at eprint.iacr.org
 ↑ Shan, J., Hu, L., Song, L., Sun, S., Ma, X. (2014). RelatedKey Differential Attack on Round Reduced RECTANGLE80. IACR Cryptology ePrint Archive, 2014, 986. pdf at eprint.iacr.org
 ↑ ^{100.0} ^{100.1} Website of the International Standard Organization, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=56552
 ↑ Mouha, N. (2015). Chaskey: a MAC Algorithm for Microcontrollers  Status Update and Proposal of Chaskey12 , IACR Cryptology ePrint Archive, 2015, 1182. pdf at eprint.iacr.org
 ↑ Leuren, G. (2015). Differential and Linear Cryptanalysis of ARX with Partitioning  Application to FEAL and Chaskey, IACR Cryptology ePrint Archive, 2015, 968. pdf at eprint.iacr.org
 ↑ Ferguson, N., Lucks, S., Schneier, B., Whiting, D., Bellare, M., Kohno, T., ... & Walker, J. (2010). The Skein hash function family. Submission to NIST (round 3), 7(7.5), 3. pdf at schneier.com
 ↑ Suzaki, T., & Minematsu, K. (2010, January). Improving the generalized Feistel. In Fast Software Encryption (pp. 1939). Springer Berlin Heidelberg. pdf at eprint.iacr.org