1 Introduction

Lightweight cryptography aims to deploy cryptographic algorithms in resource-constrained devices such as embedded systems, RFID devices and sensor networks. The cryptographic community has done a significant amount of work in this area, including design, implementation and cryptanalysis of new lightweight cryptographic algorithms, together with efficient implementation of conventional cryptography algorithms in constrained environments (see the Lightweight Cryptography Lounge,Footnote 1 [89, 260, 391]). Most recent cryptographic competitions such as NIST’s SHA-3 Cryptographic Hash Algorithm CompetitionFootnote 2 and eSTREAM projectFootnote 3 (with the Profile 2) had requirements that support implementations for highly constrained devices. Additionally, NIST currently is working on a special callFootnote 4 to create a portfolio of lightweight algorithms through an open standardization process.

The lightweightness of a given cryptographic algorithm can be obtained in two ways, by optimized implementations with respect to different constraints or by dedicated designs which use smaller key sizes, smaller internal states, smaller building blocks, simpler rounds, simpler key schedules, etc. There are several relevant metrics for assessing lightweight algorithms, such as power and energy consumption, latency, throughput and resource requirements [404]. Power and energy consumption are important for devices that are battery-oriented or energy harvesting. Latency is the time taken to perform a given task, and is important for applications where fast response time is necessary (e.g., Advanced Driver Assistance Systems), while throughput can be defined as the rate at which the plaintext is processed per time unit, and is measured in Bps.

Resource requirements are expressed differently in hardware and software implementations. In the hardware case, they are described as gate area, expressed by logic blocks for FPGAs or by Gate Equivalents (GEs) for ASIC implementations. However, these measures highly depend on the particular technology, so it is not possible to do a fair and relevant comparison of the lightweight algorithm implementations exactly across different technologies. In the software case, resource requirements are described as number of registers, RAM and ROM consumption in bytes. ROM consumption corresponds in fact with the code size.

Hardware implementations are suitable for highly constrained devices. For example, on the low end, low-cost passive RFID tags may have a total of 1000–10,000 gates, with only 200–2000 budgeted for security purposes [309]. Software implementations are suitable for less constrained devices, and they are optimized for throughput and energy consumption.

Some design choices related to dedicated lightweight cryptographic algorithms have influences on the security margins. For example, smaller key sizes such as 80 bits or 96 bits are in conflict with the current NIST minimum key size requirement of 112 bits. Smaller block and output sizes in some algorithms may lead to plaintext recovery or codebook attacks. Simpler key schedules may enable different attacks using related keys, weak keys, etc. Smaller internal state (IS) and digest sizes in hash functions may lead to collision attacks. Simpler rounds sometimes means that more iterations are required to achieve security.

The main objective of this chapter is to offer to practitioners, researchers and all interested parties a short categorized catalog of existing symmetric lightweight primitives with their main features, some details about known software and hardware performance, and existing security analysis, to enable selection according to specific needs. These cryptographic primitives can be categorized into five areas: block and stream ciphers, hash functions, message authentication codes, and authenticated encryption schemes. As a consequence of the simplicity which provides lightweightness, the security evaluation of lightweight stream ciphers appears as an issue of top importance, and so a number of illustrative elements relevant for cryptanalysis of lightweight encryption techniques have been pointed out as well.

It can easily be observed that (see Sect. 2.2) almost all of the recently designed lightweight ciphers are block ciphers. The requirement for unnecessarily large internal states results in extra hardware area cost which definitely hinders designing ultralightweight stream ciphers. We analyze the arguments behind this criterion and propose to loosen it by justifying the security analysis in Sect. 2.3. We believe this adoption will promote the design and even the analysis of lightweight stream ciphers.

2 Catalog of Lightweight Cryptographic Primitives

The catalog of lightweight cryptographic primitives is divided in five categories: block and stream ciphers, hash functions, message authentication codes, and authenticated encryption schemes.

2.1 Block Ciphers

Block ciphers encrypt one block of plaintext bits at a time, to a block of ciphertext bits, through multiple rounds, and using a secret key. Each round is a sequence of several simple transformations, which provide confusion and diffusion [522]. In each round, a round key is used, which is derived from the secret key using a key schedule algorithm. According to the algorithm structure, block ciphers can be divided into several types:

  • Substitution Permutation Network (SPN)—each round consists of substitution (S-) and permutation (P-) boxes. Usually, S-boxes are non-linear transformations and provide confusion, while P-boxes are linear and provide diffusion.

  • Feistel Network (Feistel)—divides the input block into two halves, L i and R i, and in each round, the output block is (L i+1, R i+1) = (R i, L i ⊕ F(R i, K i+1)), where F is the round-function (introduced by H. Feistel [209]).

  • Add-Rotate-XOR (ARX)—only three operations are used: modular addition, rotation and XOR.

  • Generalized Feistel Network (GFN)—divides the input block into n parts, and each round consists of a round-function layer and a block-permutation layer, which usually is a cyclic shift. If the round-function is applied only to one part, we speak about Type-1, and if it is applied on the n∕2 parts, we speak about Type-2 GFN. If there is an additional linear layer between the two layers, we speak about Extended GFN [78].

  • LFSR-based—in the round function they use one or more Linear Feedback Shift Registers (LFSRs) in combination with non-linear functions.

  • LS-design—each round combines linear diffusion L-boxes with non-linear bitslice S-boxes, and they are aimed at efficient masked implementations against side-channel analysis [247].

  • XLS-design—a variation of the LS-design, that uses the additional ShiftColumns operation, and Super S-boxes [306].

There are also tweakable block ciphers, which in addition to the key and the message have a third input named tweak, and they must be secure even if the attacker is able to control the tweak input. Each tweakable block cipher can be seen as a family of permutations in which each (key, tweak) pair selects one permutation.

The standard block cipher approach can be made lightweight by using smaller key sizes (e.g., 80 or 96 bits), smaller block sizes (e.g., 64 bits), smaller or special building blocks (e.g., 4-bit S-boxes, no S-boxes at all, or recursive diffusion layers), simpler key schedules (e.g., selecting a key schedule where bits from the master key are selected as round keys), smaller hardware implementation, involutive encryption, etc. AES-128 belongs in this group also, because there are ASIC implementations of it with an area of just 2400 GE[426] on 0.18 μm technology, but it cannot be applied in every scenario. In Table 2.1, we give a summary of the known lightweight block ciphers, sorted in alphabetical order, with their type, key and block size in bits, number of rounds, used technology and number of GEs if known, and we give the best known attacks in Table 2.2. KASUMI used in UMTS, GSM, and GPRS mobile communications systems, 3-Way and MANTIS are considered insecure. Additionally, CLEFIA and PRESENT are part of the ISO-29192-2 standard, while HIGHT, MISTY1 and AES are part of the ISO/IEC 18033-3:2010 standard.

Table 2.1 Lightweight block ciphers (characteristics)
Full size table
Table 2.2 Lightweight block ciphers (best known attacks)
Full size table

For fair and consistent evaluation and comparison of software implementations of lightweight block and stream ciphers, one can use a free and open-source benchmarking framework FELICS (Fair Evaluation of Lightweight Cryptographic Systems) [182]. Currently, the assessment can be done on three widely used microcontrollers: 8-bit AVR, 16-bit MSP and 32-bit ARM, and extracted metrics are the execution time, RAM consumption and binary code size, from which one single value “Figure Of Merit” (FOM) is calculated. Table 2.3 presents some details about software performance of some lightweight block ciphers with the current best FELICS results for encryption of 128 bytes of data in CBC mode (scenario 1 in [182]), sorted according to the FoM measure, where the lowest result is the best.

Table 2.3 The current best FELICS results for scenario 1: Encrypt 128 bytes of data in CBC mode
Full size table

2.2 Stream Ciphers

Stream ciphers encrypt small portions of data (one or several bits) at a time. By using a secret key, they generate a pseudorandom keystream, which is then combined with the plaintext bits to produce the ciphertext bits. Very often the combining function is bitwise XORing, and in that case we speak about binary additive stream ciphers. The basic security rule for stream ciphers is not to encrypt two different messages with the same pair of key/IV. So, stream ciphers usually have a large keystream period, and a different key and/or IV should be used after the period elapses. Each stream cipher usually has an initialization phase with some number of rounds (or clock-cycles), followed by an encryption phase. A fast initialization phase makes a given cipher suitable for encrypting many short messages, while when several large messages need to be encrypted, stream ciphers with a fast encryption phase are more appropriate.

The standard stream cipher approach can be made lightweight by using: smaller key sizes (e.g., 80 bits), smaller IV/nonce sizes (e.g., 64 bits), a smaller internal state (e.g., 80 or 100 bits), simpler key schedules, a smaller hardware implementation, etc. Table 2.4 lists the known lightweight stream ciphers in alphabetical order, with their main parameters and details about hardware implementation, and Table 2.5 provides the best known attacks. One can notice that all eSTREAM Profile 2 candidates that were not selected as finalists are not in the table. Also, according to the hardware implementations, ZUC, ChaCha and Salsa20 cannot really be considered as lightweight. While Lizard uses 120 bit keys, its designers claim only 80-bit security against key-recovery attacks. A5/1 used in GSM protocol, E0 used in Bluetooth, A2U2, and Sprout are considered insecure.

Table 2.4 Lightweight stream ciphers (characteristics)
Full size table

Rabbit

[98]

128

64

513

128

271

4+4

0.18

3800

RAKAPOSHI

[148]

128

192

320

1

264

448

−

−

Salsa20

[80]

256

64

512

512

273

20

0.18

9970 [270]

SNOW 3G

[204]

128

128

576

32

 

32

−

−

Sprout

[27]

80

70

89

1

240

320

0.18

813

Trivium

[127]

80

80

288

1

264

1152

0.35

749 [409]

Quavium

[555]

80

80

288

1

264

1152

−

3496 estimated

WG-8

[207]

80

80

160

1

2160

40

0.065

1786 [587]

ZUC (v 1.6)

[205]

128

128

560

32

 

32

0.065

12,500 [378]

Table 2.5 Lightweight stream ciphers (best known attacks)
Full size table

Additionally, Enocoro and Trivium are part of the ISO/IEC 29192-3:2012 standard, and Rabbit is part of ISO/IEC 18033-4:2011. SNOW 3G was chosen for the 3GPP encryption algorithms UEA2 and UIA2, while ZUC was chosen for the 3GPP algorithms 128-EEA3 and 128-EIA3. The profile 2 eSTREAM portfolio includes Grain v1, MICKEY 2.0 and Trivium. There is an IETF implementation of the ChaCha20, published in RFC 7539, with 96-bit nonce and maximum message length up to 232 − 1B that can be safely encrypted with the same key/nonce, as a modification.

2.3 Hash Functions

A hash function is any function that maps a variable length input message into a fixed length output. The output is usually called a hashcode, message digest, hash value or hash result. Cryptographic hash functions must be preimage (one-way), second preimage and collision resistant.

Usually the message is first padded and then divided into blocks of fixed length. The most common method is to iterate over a so-called compression function, that takes two fixed size inputs, a message block and a chaining value, and produces the next chaining value. This is known as a Merkle-Damgård (MD) construction. The sponge construction is based on fixed-length unkeyed permutation (P-Sponge) or random function (T-Sponge), that operates on b bits, where b = r + c. b is called the width, r is called the rate (the size of the message block) and the value c the capacity. The capacity determines the security level of the given hash function. There is also a JH-like sponge in which the message block is injected twice.

The main problem of using conventional hash functions in constrained environments is their large internal state. SHA-3 uses a 1600 bit IS, and its most compact hardware implementation needs 5522 GE [471] on 0.13 μm technology. On the other hand, SHA-256 has a smaller IS (256 bit), but one of its smaller hardware implementations uses 10,868 GE [211] on 0.35 μm technology.

Lightweight hash functions can have smaller internal state and digest sizes (for applications where collision resistance is not required), better performance on short messages, small hardware implementations, etc. In some cases, for example tag-based applications, there is a need only for the one-way property. Also, most tag protocols require hashing of small messages, usually much less than 256 bits.

Tables 2.6 and 2.7 list the cryptographic and implementation properties of the known lightweight hash functions. ARMADILLO is considered insecure. Lesamnta-LW, PHOTON, and SPONGENT are part of the ISO/IEC 29192-5:2016 standard.

Table 2.6 Lightweight hash functions (cryptographic properties)
Full size table
Table 2.7 Lightweight hash functions (implementation properties)
Full size table

2.4 Message Authentication Codes

A message authentication code (MAC) protects the integrity and authenticity of a given message, by generating a tag from the message and a secret key. MAC schemes can be constructed from block ciphers (e.g., CBC-MAC (part of the ISO/IEC 9797-1:1999 standard) or OCB-MAC [504]), from cryptographic hash functions (e.g., HMAC (RFC 2104)), etc. Three lightweight security architectures have been proposed for wireless sensor networks: TinySec [316], MiniSec [382] and SenSec[370]. TinySec and MiniSec recommend CBC-MAC and the patented OCB-MAC, while SenSec recommends XCBC-MAC, for which there is an existential forgery attack [238], and all suggest the use of 32-bit tags. 32-bit security is not enough—the recommended size is at least 64 bits.

Design choices for lightweight MACs include shorter tag sizes, simpler key schedules, small hardware and/or software implementations, better performance on very short messages, no use of nonces, and generation from lightweight block ciphers and hash functions. Some lightweight MACs are listed in Table 2.8, and the best known attacks against these MACs are provided in Table 2.9.

Table 2.8 Lightweight MACs (characteristics)
Full size table
Table 2.9 Lightweight MACs (best known attacks)
Full size table

2.5 Authenticated Encryption Schemes

Authenticated encryption (AE) schemes combine the functions of ciphers and MACs in one primitive, so they provide confidentiality, integrity, and authentication of a given message. Besides the plaintext and the secret key, they usually accept variable length Associated Data (AEAD schemes), a public nonce, and an optional secret nonce. AD is a part of a message that should be authenticated, but not encrypted.

Lightweight authenticated encryption schemes are presented in Table 2.10, and the best known attacks against these schemes are provided in Table 2.11. Sablier and SCREAM/iSCREAM are considered insecure. The hardware implementation is given with encryption/authentication and decryption/verification functionalities.

Table 2.10 Lightweight authenticated encryption schemes (characteristics)
Full size table
Table 2.11 Lightweight authenticated encryption schemes (best known attacks)
Full size table

3 Illustrative Issues in Security Evaluation of Certain Encryption Schemes

As a consequence of the simplicity which makes them lightweight, the security evaluation of lightweight encryption schemes arises as an issue of top importance. However, constraints on chapter space limit our discussion of the security evaluation. Consequently, this section shows only a number of illustrative issues relevant for the cryptanalysis of lightweight encryption techniques. In the first part, a generic approach for security evaluation is discussed, and in the second an advanced dedicated approach is pointed out.

3.1 Reconsidering TMD Tradeoff Attacks for Lightweight Stream Cipher Designs

We can simply divide the tradeoff attacks against ciphers into two groups, key recovery attacks and internal state recovery attacks. The first tradeoff attack against symmetric ciphers was introduced by Hellman [268] to illustrate that the key length of DES was indeed too short. Hellman prepared several tables containing DES keys. In general, the tradeoff curve is TM 2 = N 2 where T is the time complexity and M is the memory complexity. N is the cardinality of the key space. Here, the data complexity D = 1 since only one chosen plaintext is used to define a one way function which produces the (reduction of the) ciphertext of the chosen plaintext for a given key. Then, the tables are prepared during the precomputation phase. In practice, one generally considers the point T = M = N 2∕3 on the curve since the overall complexity also becomes N 2∕3. The precomputation phase costs roughly O(N) encryptions. This is a generic attack which is applicable to any block cipher. Therefore, we can say that the security level diminishes to 2k∕3-bit security during the online phase of the Hellman tradeoff attack where k is the key length of a block cipher. However, one must pay a cost equivalent to exhaustive search to prepare the tables during the precomputation phase.

Stream ciphers also suffer from the same affliction by tradeoff attacks in that their keys can be recovered with an effort of 22k∕3 for each of them during the online phase. Stream ciphers consist of two parts. The initialization part uses an IV  and a key to produce a seed value S 0. Then, S 0 is used to produce the keystream sequence through a keystream generator. While a state update function updates the internal states S i, an output function produces the keystream bits (or words) z i. It is possible to define a one way function from the key to the first k bits of the keystream sequence by choosing an IV  value and fixing it. This is similar to the case of tradeoff attacks on block ciphers with a chosen plaintext. However, the attack may only be mounted on a decryption mechanism since it may not be possible to choose the IV  during the encryption. Then, by preparing the Hellman tables, one can recover a key in 22k∕3 encryptions using 22k∕3 memory. The precomputation is 2k. This is similar to the Hellman attack. Therefore, stream ciphers are prone to tradeoff attacks as with block ciphers in the key recovery case.

The other category of tradeoff attacks is aimed at recovering internal states of stream ciphers, rather than keys. Babbage [47] and Golić [236], independently, introduced another type of tradeoff curve DM = N to recover an internal state. One can pick out the point D = M = N 1∕2 to get an overall complexity of N 1∕2. Then, storing \(\sqrt {N}\) internal states with their outputs (keystream parts with an appropriate length), one can recover a keystream used during encryption/decryption if it is loaded in the table. We need roughly \(\sqrt {N}\) data to ensure a remarkable success rate. So, it is conventionally adopted that \(\sqrt {N}\) should be larger than 2k as a security criterion just to ensure that the internal state recovery attack through tradeoff is slower than the exhaustive search. This simply means that the internal state size should be at least twice as large as the key size. This extremely strict criterion has played a very crucial role in raising extra difficulties in designing lightweight stream ciphers.

Another highly effective tradeoff attack for internal state recovery is the Biryukov-Shamir attack [91]. This simply makes use of Hellman tables. But, instead of recovering just one specific internal state, it is enough to recover only one of D internal states. Then, preparing just one Hellman table is an optimum solution and the table can contain N∕D states. So, the precomputation phase is around O(N∕D) and the tradeoff curve is TM 2 D 2 = N 2 where D is bounded above by \(\sqrt {T}\) since the number of internal states contained in just one table is limited to avoid merging of collisions. We can pick out the point on the curve where time and memory are equal and maximize the data, namely T = M = N 1∕2 and D = N 1∕4. We need N 1∕2 to be larger than 2k if we want the online phase of the attack to be slower than an exhaustive search. This again simply implies that the internal state size should be at least twice as large as the key size.

The condition on the size of the internal states of stream ciphers makes designing ultralightweight stream ciphers too difficult. Indeed, there are several ultralightweight (say less than 1000 GE) block ciphers recently designed, such as PRESENT [101], LED [252], KTANTAN [126], Piccolo [526], and SIMON/SPECK [65], whereas there are almost no modern stream ciphers with hardware area cost less than 1000 GE.

The security margin for state recovery attacks through tradeoff techniques is k bits, whereas it is much less, 2k∕3 bits, for the key recovery attacks, although any information about the key is assumed to be more sensitive than any information about the internal states. One can produce any internal state once the key is recovered. However, recovery of an internal state may reveal only one session of the encryption/decryption with the corresponding IV . Hence, it seems that the more sensitive data are, contradictorily, protected less against tradeoff attacks!

The security level of tradeoff attacks to recover internal states should be the same as the security level of tradeoff attacks to recover keys, just to be fair. So, the online phase of a tradeoff attack should be at least 22k∕3 instead of 2k. Similarly, the precomputation should be not faster than exhaustive search. In this case, D = M = N 1∕2 ≥ 22k∕3 for the Babbage-Golić attack. Then, N should be at least 24k∕3. The same bound is valid for Biryukov-Shamir attack since the smallest overall complexity is attained when T = M = N 1∕2.

The precomputation phase of the Biryukov-Shamir attack is roughly N∕D; which is simply N 3∕4 when D = N 1∕4. So, the precomputation phase is more than 2k. This means that it is slower than an exhaustive search. On the other hand, the precomputation phase of the Babbage-Golić attack is M, and hence if the data is restricted to at most 2k∕3 for each key we have M ≥ 2k and hence the precomputation phase will be slower than an exhaustive search.

It seems it is enough to take the internal state size as at least 4k∕3, not at least 2k, for security against tradeoff attacks. This simply implies that it is possible to design lightweight stream ciphers with much smaller internal states. However, it is an open question how to design stream ciphers with very small internal states. The security is generally based on the largeness of the states.

3.2 Guess-and-Determine Based Cryptanalysis Employing Dedicated TMD-TO

This section presents an illustrative framework for cryptanalysis employing guess-and-determine and time-memory-data trade-off (TMD-TO) methods using the results of security evaluations of the lightweight stream ciphers Grain-v1, Grain-128 and LILI-128, reported in [415, 416], and [417], respectively.

3.2.1 Generic Approach

Certain stream ciphers can be attacked by employing the following approach: (1) Assuming the availability of a sufficiently long sample for recovering an internal state, we develop a dedicated TMD-TO attack which allows recovery of the internal state for a certain segment of the available sample. (2) The dedicated TMD-TO attack is developed over a subset of the internal states in which certain parts of the internal state are preset or algebraically recovered based on the considered keystream segment. Assume that the state size is ν and that certain bits (say β) of the internal state are fixed according to a specific pattern. Then, with this information, for the corresponding keystream segment, we try to obtain some more bits (say γ) of the internal state. The final goal is to recover the unknown bits of the internal state δ = ν − β − γ by employing a suitable TMD-TO attack. Accordingly, the cryptanalysis is based on the following framework:

  • preset certain bits of the internal state to a suitable pattern (the all-zeros pattern, for example);

  • for a given m-bit prefix (usually an m-zeros prefix) of the keystream segment, algebraically recover up to m bits of the internal state assuming that the remaining internal state bits are known;

  • recover the assumed bits of the internal state by employing the dedicated TMD-TO attack.

3.2.2 Summary of Cryptanalysis of Grain-v1 Employing Guess-and-Determine and Dedicated TMD-TO Approaches

The internal state of Grain-v1 consists of 160 bits corresponding to the employed nonlinear and linear feedback shift registers NFSR and LFSR, respectively. For a given parameter m, let Ω (m) be a subset of all internal states where three m-length segments of all zeros exist which implies that the state generates m consecutive zero outputs. Let the vectors b (i) and s (i) be the states of the NFSR and LFSR, respectively, at the instant i, s (i) = [s i, s i+1, …, s i+79] and b (i) = [b i, b i+1, …, b i+79]. Let u (i) be the internal state of Grain-v1, and accordingly, u (i) = [s (i)||b (i)] = [s i, s i+1, …, s i+79, b i, b i+1, …, b i+79]. For a given parameter m, the set Ω (m) is the set of internal state vectors defined as follows Ω (m) = {u (i)|s i+25−j = 0, s i+64−j = 0, b i+63−j = 0 , j = 0, 1, …, m − 1}. Consequently, the number of internal states belonging to Ω (m) is upper-bounded by 2160−3m.

The internal state recovery is based on the following: Whenever we observe an m-zeros prefix of a keystream segment, we suppose that the segment is generated by an internal state belonging to Ω (m) and we employ a dedicated TMD-TO attack to check the hypothesis. The complexities of this cryptanalysis and a related one are illustrated in Table 2.12.

Table 2.12 An illustrative numerical comparison of two algorithms for cryptanalysis of Grain-v1
Full size table