# A MAC Mode for Lightweight Block Ciphers

- 14 Citations
- 1.2k Downloads

## Abstract

Lightweight cryptography strives to protect communication in constrained environments without sacrificing security. However, security often conflicts with efficiency, shown by the fact that many new lightweight block cipher designs have block sizes as low as 64 or 32 bits. Such low block sizes lead to impractical limits on how much data a mode of operation can process per key. MAC (message authentication code) modes of operation frequently have bounds which degrade with both the number of messages queried and the message length. We present a MAC mode of operation, LightMAC, where the message length has *no effect* on the security bound, allowing an order of magnitude more data to be processed per key. Furthermore, LightMAC is incredibly simple, has almost no overhead over the block cipher, and is parallelizable. As a result, LightMAC not only offers compact authentication for resource-constrained platforms, but also allows high-performance parallel implementations. We highlight this in a comprehensive implementation study, instantiating LightMAC with PRESENT and the AES. Moreover, LightMAC allows flexible trade-offs between rate and maximum message length. Unlike PMAC and its many derivatives, LightMAC is not covered by patents. Altogether, this makes it a promising authentication primitive for a wide range of platforms and use cases.

## Keywords

Lightweight MAC LightMAC Message length Birthday bound Integrity Verification## 1 Introduction

With the rise of the Internet of Things, connected devices are being placed everywhere, resulting in a wide variety of efficiency, robustness, and feature requirements for communication. Securing the communcation remains important, and as a result, many block ciphers have been created to work efficiently in constrained environments. These block ciphers offer a range of block and key sizes, from 128 to 32 bits; see Table 1 for a sample.

The key size is often chosen carefully to ensure a sufficiently high security level, resulting in the block size becoming the dominant factor in determining security. As is well known, reducing block size can increase the chance of an inner state collision when block ciphers are used in so-called *modes of operation*: constructions which repeatedly apply a block cipher to achieve functionality beyond what a block cipher offers.

*q*, and the length of the messages measured in blocks, \(\ell \); see Table 2 for a list of modes with their dependence on \(\ell \). For many modes, an adversary which is able to tag

*q*messages of length \(\ell \) blocks will have a success probability of roughly

*n*is the block size of the underlying block cipher. With a 32 bit block size and a guarantee that adversaries do not forge with probability more than one in a million, one gets a restriction of the form

Supported block sizes are often small, and can be as low as 32 bits.

Block size (bits) | 32 | 48 | 64 | 80 | 96 | 128 | 256 |
---|---|---|---|---|---|---|---|

AES [15] | \(\times \) | ||||||

CLEFIA [38] | \(\times \) | ||||||

DESLX [27] | \(\times \) | ||||||

Fantomas [19] | \(\times \) | ||||||

HIGHT [23] | \(\times \) | ||||||

ITUbee [26] | \(\times \) | ||||||

KLEIN [18] | \(\times \) | ||||||

KATAN [13] | \(\times \) | \(\times \) | \(\times \) | ||||

LBlock [42] | \(\times \) | ||||||

LED [21] | \(\times \) | ||||||

LEA [22] | \(\times \) | ||||||

mCrypton [28] | \(\times \) | ||||||

Mysterion [25] | \(\times \) | \(\times \) | |||||

Noekeon [14] | \(\times \) | ||||||

Piccolo [37] | \(\times \) | ||||||

PRESENT [11] | \(\times \) | ||||||

PRIDE [1] | \(\times \) | ||||||

PRINCE [12] | \(\times \) | ||||||

RC5 [36] | \(\times \) | \(\times \) | \(\times \) | ||||

Rectangle [48] | \(\times \) | ||||||

RoadRunneR [2] | \(\times \) | ||||||

Robin [19] | \(\times \) | ||||||

SEA [39] | \(\times \) | ||||||

SIMECK [43] | \(\times \) | \(\times \) | \(\times \) | ||||

Simon [3] | \(\times \) | \(\times \) | \(\times \) | \(\times \) | \(\times \) | ||

Speck [3] | \(\times \) | \(\times \) | \(\times \) | \(\times \) | \(\times \) | ||

TWINE [40] | \(\times \) | ||||||

XTEA [33] | \(\times \) | ||||||

Zorro [17] | \(\times \) |

The table below contains the coefficients of the powers of \(\ell \) contained in the security bounds for adversaries making *q* queries of length \(\ell \), with block size *n* bits. References are to papers proving the bounds. In the bound for EMAC, the function \(d'(\ell )\) has been replaced by \(\ell \).

Mode | 1 | \(\ell \) | \(\ell ^2\) | \(\ell ^3\) | \(\ell ^4\) |
---|---|---|---|---|---|

3kf9 [47] | \(\frac{4q}{2^n}+\frac{4q^3}{2^{2n}}\) | \(\frac{4q}{2^n} + \frac{4q^3}{2^{2n}} \) | \(\frac{2q^3}{2^{2n}}\) | \(\frac{4q^3}{2^{2n}}\) | |

CBC-MAC [6] | \(\frac{12q^2}{2^{n}}\) | \(\frac{64q^2}{2^{2n}}\) | |||

EMAC [6] | \(\frac{q^2}{2^n}\) | \(\frac{32q^2}{2^{2n}}\) | |||

OMAC [31] | \(\frac{5q^2}{2^n}\) | \(\frac{8q^2}{2^{2n}}\) | |||

PMAC [32] | \(\frac{-3.5q^2}{2^n}\) | \(\frac{5q^2}{2^n}\) | |||

PMAC_Plus [45] | \(\frac{3q}{2^n}\) | \(\frac{27q^3}{2^{2n}}\) | |||

\(\underset{\tiny (m = 14, l = 12)}{\text {PMACX}}\) [49] | \(\frac{72+1.5q^2}{2^n} + \frac{576q^2}{2^{2n}}\) | \(\frac{576q^2}{2^{2n}}\) | \(\frac{144 q^2}{2^{2n}}\) | ||

PMAC with Parity [46] | \(\frac{q^2}{2^n}\) | \(\frac{q^2}{2^{2n}}\) | |||

Sum of CBCs [44] | \(\frac{12q^3}{2^{2n}}\) |

### 1.1 Contributions

We present a MAC mode, LightMAC, which enables one to tag much longer messages than typically possible. LightMAC is depicted in Fig. 2 and Algorithm 1.

*s*to 16, roughly 64 messages can be tagged with length up to \(2^{15}\) blocks. Note that keys are used most efficiently when the messages are as long as possible: up to \(64 \cdot 2^{15} \cdot 32 = 2^{26}\) bits, or

*8 MiB*of data can be tagged per key. LightMAC uses two independent keys, but even after normalizing by the number of keys, the amount of data processed per key is still 4 MiB, a significant improvement over 1 KiB.

Figure 1 compares LightMAC to the other published modes from Table 2. The figure shows that LightMAC starts with a factor \(2^4\) improvement over many of the modes, which grows to roughly \(2^{10}\) as the number of queries increases. Modes such as PMAC with Parity and PMACX were designed to handle long message lengths and offer competitive bounds, at the cost of increased design complexity. LightMAC’s advantage over these modes is its simplicity and low overhead.

Like PMAC [10], LightMAC allows block cipher calls to be made in parallel, but unlike PMAC, LightMAC is based on Bernstein’s *protected counter sum* [8], and hence should not suffer from patent issues.

A disadvantage of LightMAC is that its rate is low. In order to tag messages of length up to \(2^{n/2-1}\) blocks, *n* / 2 bits of the block must be sacrificed for a counter, hence two block cipher calls must be called per block of data. However, the rate can be improved: if the maximum message length that will be communicated is known to be less than \(2^s(n-s)\) bits, then the rate can be set to \((n-s)/n\) blocks per block cipher call. For example, using a 32 bit block cipher, if the message lengths are less than \(2^9\) blocks, then the rate can be set to 2 / 3 blocks per call. Therefore, unlike other modes, LightMAC can be optimized according to the application: the shorter the messages, the more efficient LightMAC is, while allowing the same number of message to be queried. Section 5 presents implementation results for LightMAC instantiated with the AES [15] and PRESENT [11], and discusses LightMAC’s efficiency in more detail.

### 1.2 Related Work

In 1995, Bellare et al. [4] described the *XOR MACs*, which XORed together finite-input-length pseudorandom functions (PRF) to create stateful and randomized MACs. In 1999, Bernstein [8] introduced the protected counter sum, which composes an XOR MAC with an independent PRF call to create a stateless, deterministic MAC. In 2012, Yasuda [46] explained the basic idea for LightMAC in his paper’s introduction, which can be viewed as an adaptation of Bernstein’s protected counter sum using block ciphers.

Another MAC algorithm designed for lightweight use is Chaskey [30]. The Chaskey paper includes a block cipher and a permutation mode, but both have bounds which deteriorate quadratically with respect to message length.

In certain cases the bounds in Table 2 can be improved. For example, for \(\ell \le 2^{n/8}\) and \(q\ge \ell ^2\), EMAC’s bound becomes \(\frac{16q^2}{2^n} + \frac{128q^2\ell ^8}{2^{2n}}\) as shown by Pietrzak [34]. For the sum of CBCs, Yasuda [44] also showed that if \(\ell \le 2^{2n/5}\), the advantage becomes \(\frac{40\ell ^3q^3}{2^{2n}}\).

## 2 Preliminaries

The set \(\left\{ 0,1\right\} ^n\) represents all bit-strings of length *n*; the set \(\left\{ 0,1\right\} ^{\le n}\) is all bit-strings of length less than or equal to *n*. For two bit-strings *A* and *B*, we write \(A\Vert B\) and *AB* interchangeably for the concatenation of *A* and *B*. Let *r* be an integer, then \(M[1]M[2]\cdots M[\ell ] \xleftarrow {r} M\) represents splitting *M* into *r*-bit blocks with the length of the last block, \(M[\ell ]\), being anywhere from zero to \(r-1\) bits.

A block cipher is a function \(E:\left\{ 0,1\right\} ^k\times \left\{ 0,1\right\} ^n\rightarrow \left\{ 0,1\right\} ^n\) where \(E(K,\cdot )\) defines a permutation for all \(K\in \left\{ 0,1\right\} ^k\). The integer *n* is the *block length* of *E* and we write \(E_K(X)\) to mean *E*(*K*, *X*). Given a block length *n*, concatenation of \(10^*\) to a string means appending a one followed by the minimum number of zeros to make the total string length a multiple of *n* bits.

The symbol \(0^n\) represents the *n*-bit string consisting of only zeros. Given a string *A* of length *n*, and an integer \(t\le n\), then \(\lfloor A\rfloor _t\) denotes the *t* least significant bits of *A*.

For an integer \(1\le i\le 2^s\), \(i_s\) represents some *s*-bit constant with the property that if \(1\le i < j\le 2^s\) then \(i_s\ne j_s\). For example, \(i_s\) could be an *s*-bit representation of the integer *i*, or the *i*th *s*-bit Gray code.

## 3 LightMAC

Let \(E:\left\{ 0,1\right\} ^k\times \left\{ 0,1\right\} ^n\rightarrow \left\{ 0,1\right\} ^n\) be a block cipher. Let *s* and *t* be integers not greater than *n* / 2 and *n*, respectively, and fix some representation for \(i_s\) (see Sect. 2). LightMAC accepts two independent and uniformly generated keys \(K_1\) and \(K_2\) from \(\left\{ 0,1\right\} ^k\), and a message *M* of length at most \(2^s(n-s)\) bits. LightMAC produces an output of length *t* bits. Figure 2 and Algorithm 1 depict how the output is produced.

LightMAC can be used as either a pseudorandom function (PRF) or a MAC (see Sects. 4.2 and 4.3 for definitions). When used as a PRF, LightMAC is fully described by Algorithm 1. When used as a MAC, tags are generated using Algorithm 1, and verification of a message-tag pair (*M*, *T*) is done by comparing LightMAC (*M*) with *T*: if the two are equal, verification succeeds, otherwise not.

*s*and

*t*, the representation of \(i_s\), and the block cipher

*E*, which implicity fixes

*k*and

*n*. The parameters must be agreed upon before a session starts, and remain constant during.

## 4 Security

Although Bellare, Guérin, and Rogaway [4] describe how to instantiate an XOR MAC using the Data Encryption Standard, they only provide proofs for pseudorandom functions, not pseudorandom permutations. Hence, even though the XOR MACs were proven to have bounds with no message length dependence, subsequent application of the PRP-PRF switching lemma would establish quadratic message length dependence. A similar explanation applies to the protected counter sum’s security bound. Therefore a direct security proof is necessary for LightMAC.

The XOR MACs and protected counter sum did not exhibit any message length dependence because the XOR of independent, uniformly distributed random variables is still uniformly distributed. In this section we use the fact that roughly the same applies to the XOR of distinct block cipher outputs to achieve message length independence for LightMAC.

### 4.1 Block Cipher Security

The security of LightMAC is reduced to that of its underlying block cipher, that is, if an attack is found against LightMAC, then the attack can be reduced to an attack against the block cipher. The quality of the reduction is measured by the security bounds computed in Theorems 1 and 2.

The statements of the theorems include terms describing the quality of the underlying block cipher, which is measured as follows.

### Definition 1

*E*of adversaries \(\mathcal {A}\) making

*q*queries and running in time \(\tau \) is

*A*outputs 1 when given access to oracle

*O*, and

*K*is uniformly distributed over \(\mathsf {K}\).

### 4.2 LightMAC as a PRF

A PRF \(\varPhi :\mathsf {K}\times \mathsf {M}\rightarrow \mathsf {T}\) is a construction which should be computationally indistinguishable from a uniformly distributed random function (URF), that is, a uniformly distributed random variable over the set of all functions from \(\mathsf {M}\) to \(\mathsf {T}\). The quality of the PRF is measured via the PRF-advantage of adversaries.

### Definition 2

*A*in distinguishing the PRF \(\varPhi :\mathsf {K}\times \mathsf {M}\rightarrow \mathsf {T}\) from the URF \(\$:\mathsf {M}\rightarrow \mathsf {T}\) is

*A*outputs 1 when given access to oracle

*O*, and

*K*is uniformly distributed over \(\mathsf {K}\).

### Theorem 1

*q*queries of length at most \(2^s(n-s)\) bits is bounded above by

*n*is the block size in bits, \(\tau _1 \in \tau + O(q\cdot (2^s-1))\), and \(\tau _2 \in \tau + O(q)\).

### Proof

*A*be a PRF-adversary against LightMAC running in time \(\tau \) and making at most

*q*queries of length at most \(2^s(n-s)\) bits. Construct the PRP adversary \(B_1\) against \(E_{K_1}\) as follows: \(B_1\) simulates \(E_{K_2}\) by uniformly randomly choosing key \(K_2\), runs

*A*, and responds to

*A*’s queries using a combination of its own oracle and the simulated \(E_{K_2}\); \(B_1\) forwards

*A*’s response as its own. Construct the PRP adversary \(B_2\) against \(E_{K_2}\) similarly. Then

*A*’s PRF-advantage against LightMAC is bounded above by

*A*’s PRF-advantage against LightMAC with its \(E_{K_1}\) and \(E_{K_2}\) calls replaced with \(\pi _1\) and \(\pi _2\) calls, respectively, where \(\pi _1\) and \(\pi _2\) are independent, uniformly distributed random permutations.

*A*’s PRF-advantage against \(\varPhi \).

*F*denote the function contained in the call to \(\phi \) in Eq. 8. Then, as long as

*F*’s outputs are distinct, each input to \(\phi \) is unique, meaning \(\varPhi \) will be indistinguishable from \(\$\). In other words,

*A*. The maximum on the right hand side is computed in Sect. 4.4, resulting in the bound

### 4.3 LightMAC as a MAC

A MAC consists of a tagging and a verification algorithm. The tagging algorithm accepts messages from some message set \(\mathsf {M}\) and produces tags from a tag set \(\mathsf {T}\). The verification algorithm receives message-tag pairs (*M*, *T*) as input, and outputs 1 if the pair (*M*, *T*) is valid, and 0 otherwise. The insecurity of a MAC is measured as follows.

### Definition 3

Let *A* be an adversary with access to a MAC. The advantage of *A* in breaking the MAC is the probability that *A* is able to produce a message-tag pair (*M*, *T*) for which the verification algorithm outputs 1, where *M* has not been previously queried to the tagging algorithm.

### Theorem 2

*q*tagging queries and

*v*verification queries of length at most \(2^s(n-s)\) bits, is bounded above by

*n*is the block size in bits, \(\tau _1\in \tau + O(q\cdot (2^s-1))\), \(\tau _2\in \tau + O(q)\), and \(\tau _3\in \tau + O(v2^s)\).

### Proof

*F*from Sect. 4.4 as the “hash” part, hence applying Proposition 1 from their paper we get an upper bound of

### 4.4 Collision Probability of *F*

### Proposition 1

*F*to be

### Proof

- 1.
\(\ell _1 = \ell _2\), \(M_1[\ell _1]10^* \ne M_2[\ell _2]10^*\), and \(M_1[i] = M_2[i]\) for all

*i*, or - 2.
either \(\ell _1\ne \ell _2\) or there exists an

*i*such that \(M_1[i] \ne M_2[i]\).

*i*, and we can simplify the problem to calculating the probability that

### Lemma 1

### Proof

*N*possibilities. Since \(y_2\) cannot equal \(y_1\), there are \(N-1\) possibilities for \(y_2\). Continuing this way, we have that there are \(N-i\) possibilities for \(y_{i+1}\), with \(i \le \ell -2\). For \(y_{\ell }\) there is at most one possibility, namely \(c\oplus y_1\oplus y_2\oplus \cdots y_{\ell -1}\). All \(y_j\) for \(j > \ell \) must be distinct from all preceding \(y_i\), hence in total there are at most

## 5 Implementation

In this section, we discuss the implementation characteristics of LightMAC and compare it to the serial two-key CBC-MAC with last block encryption, EMAC [6], and to PMAC with Parity (PMAC/P) [46], which provides a parallelizable rate 2/3 construction and can be considered its main competitor.

### 5.1 Implementation Characteristics of LightMAC

LightMAC is a mode with very low overhead: besides the block cipher calls, it only requires an *s*-bit counter generator and one additional *n*-bit state for summing the block cipher outputs.

This means that the code size (for embedded software or microcontrollers) and area requirements (for hardware implementations) of LightMAC can be estimated as roughly equivalent to CBC-MAC with encryption of the last block by a second key. Compared to PMAC with Parity, LightMAC uses only two keys instead of four. In comparison to all PMAC variants, the absence of finite field doubling further improves its implementation characteristics on embedded platforms or hardware.

In terms of throughput, a compact serial implementation of LightMAC will give a performance of about \(n/(n-s)\) block cipher call equivalents per message block of \(n-s\) bits, which means that the serial performance of LightMAC on a given platform can readily be evaluated based on the performance of the best available implementation of the chosen underlying block cipher. Except for very short messages, the overhead imposed by the final block cipher call is negligible.

Like PMAC and its derivatives, LightMAC has the advantage that the individual block cipher calls can be parallelized. While this is typically less important on lightweight platforms, where compactness and power/energy consumption are the prime concerns, this property enables high-performance implementations for the server side: since exactly the same lightweight algorithms used on small devices will also have to be used by the servers communicating with them, they should ideally also have good implementation characteristics in high-performance software environments. The importance of this was for instance pointed out in [29]. Many lightweight algorithms and modes of operation are inherently serial in nature and therefore inefficient in software. Our implementation study therefore focuses on this scenario.

### 5.2 The Setting

We explore the high-performance parallel software implementation possibilities for LightMAC, with the following choices regarding platform and instantiation parameters:

**Underlying Block Ciphers.** We use the block ciphers PRESENT [11] and AES [15] for our implementations. PRESENT is a lightweight 64-bit block cipher that was recently standardised by ISO, and AES serves as a baseline.

**Choice of**

**s****and**

*We always use full tag lengths \(t=n\), meaning 64-bit tags for PRESENT and 128-bit tags for AES. We furthermore instantiate LightMAC with the following values of*

**t.***s*:

- 1.
\(s=n/2\) for the maximum supported message length (and correspondingly lowest rate 1 / 2);

- 2.
\(s=n/3\), rounded to the nearest multiple of 8, for a mode with rate 2 / 3;

- 3.
\(s=8\), for a short maximum message length with the highest rate (\(1-8/n\)).

Altogether, these parameter choices illustrate a wide spectrum of use cases.

**Platform.** We implement LightMAC on Intel’s recent Skylake microarchitecture, using the 256-bit AVX2 instruction set. PRESENT was implemented in a bitsliced fashion processing 8 blocks in parallel. Other implementation strategies are known to yield a significantly lower performance, see [7] for a comprehensive study. For the AES, the AES-NI instruction set [20] was used. The key scheduling was precomputed for both ciphers. Since byte-aligned *s*-bit addition is inexpensive on this platform, the counters \(i_s\) are implemented as the *s*-bit representation of the integer *i*.

**Message Lengths.** We provide performance data for all message lengths of \(\ell =2^b\) bytes, with \(7 \le b \le 13\), wherever \(8\ell \le 2^s(n-s)\).

### 5.3 Performance Measurements

Baseline performance of ciphers PRESENT and AES on Skylake (AVX2, AES-NI).

Block cipher | Encryption [cycles/byte] | Key schedule [cycles] |
---|---|---|

PRESENT (table-based) | 57.83 | 353 |

PRESENT (8 blocks bitsliced) | 11.23 | 790 |

AES (AES-NI, serial) | 2.57 | 116 |

AES (AES-NI, pipelined) | 0.63 | 116 |

Software performance of LightMAC, EMAC and PMAC with Parity (PMAC/P), instantiated with PRESENT and AES on the Intel Skylake platform (AVX2, AES-NI). All numbers are given in cycles per byte (cpb). Data is provided for message lengths smaller than \(2^{s}(n-s)\) bits.

Message length (bytes) | |||||||||
---|---|---|---|---|---|---|---|---|---|

Algorithm | | Rate | 128 | 256 | 512 | 1024 | 2048 | 4096 | 8192 |

EMAC-PRESENT | – | 1 | 63.02 | 61.21 | 60.28 | 59.80 | 59.57 | 59.41 | 59.32 |

PMAC/P-PRESENT | – | 2/3 | 39.62 | 32.44 | 28.82 | 27.07 | 26.48 | 26.14 | 26.00 |

LightMAC -PRESENT | 32 | 1/2 | 25.50 | 23.67 | 22.75 | 22.32 | 22.08 | 21.97 | 21.92 |

LightMAC -PRESENT | 24 | 2/3 | 25.70 | 21.21 | 20.17 | 19.03 | 18.09 | 17.80 | 17.80 |

LightMAC -PRESENT | 8 | 7/8 | 20.31 | 18.34 | 14.65 | 13.48 | – | – | – |

EMAC-AES | – | 1 | 3.42 | 3.19 | 3.03 | 2.91 | 2.74 | 2.68 | 2.67 |

PMAC/P-AES | – | 2/3 | 1.53 | 1.48 | 1.33 | 1.24 | 1.17 | 1.15 | 1.14 |

LightMAC -AES | 64 | 1/2 | 1.33 | 1.29 | 1.27 | 1.26 | 1.26 | 1.26 | 1.25 |

LightMAC -AES | 40 | 2/3 | 1.37 | 1.31 | 1.12 | 1.04 | 0.95 | 0.95 | 0.92 |

LightMAC -AES | 8 | 15/16 | 1.38 | 1.00 | 0.82 | 0.80 | 0.72 | – | – |

**Discussion.** One can observe that with both PRESENT and the AES as the underlying block ciphers, LightMAC provides a performance of about the inverse of its rate times the baseline block cipher speed. This confirms that LightMAC imposes very low overhead in addition to the block cipher invocations.

In contrast to the serial EMAC, LightMAC provides significantly greater performance despite featuring a smaller rate. This demonstrates the advantage of parallelisability over a sequential algorithm.

Comparing the LightMAC instantiations with rate 2/3 to PMAC with Parity (PMAC/P), we note that the use of the same key throughout the message processing (as opposed to three different keys in PMAC/P) significantly improves the performance for the PRESENT-based implementation: LightMAC is consistently around 50 % faster. This is largely due to the fact that the parts of each subkey of PMAC/P’s three bitsliced keys have to be interleaved in an appropriate way. The effect is less pronounced for the AES where no conversion to bitsliced format is needed, and due to the AES-NI instructions which freely accept both registers and memory locations for the subkeys. Still, LightMAC is about 20 % faster, while additionally providing a flexible range of trade-offs between rate and maximum message length.

## 6 Conclusions

We proposed LightMAC, a new MAC mode of operation specifically suited to lightweight applications. Its security bound was shown in Sect. 4 to not depend on the message length, allowing an order of magnitude more data to be processed per key.

Featuring a simple design with very low overhead over the block cipher, it not only offers compact authentication for resource-constrained platforms, but also allows high-performance parallel implementations, as demonstrated by the implementation study of LightMAC instantiated with PRESENT and the AES in Sect. 5. Furthermore, the implementation results show how the *s*-parameter translates directly to a trade-off between rate and maximum message length.

Unlike PMAC and its many derivatives, LightMAC is not covered by patents. Altogether, this makes it a promising authentication solution for a wide range of platforms and use cases.

## Notes

### Acknowledgments

We would like to thank the various anonymous reviewers for providing useful comments. This work was supported in part by the Research Council KU Leuven: GOA TENSE (GOA/11/007). In addition, this work was supported by the Research Fund KU Leuven, OT/13/071. Atul Luykx is supported by a Ph.D. Fellowship from the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWT-Vlaanderen).

## References

- 1.Albrecht, M.R., Driessen, B., Kavun, E.B., Leander, G., Paar, C., Yalçın, T.: Block ciphers – focus on the linear layer (feat. PRIDE). In: Garay, J.A., Gennaro, R. (eds.) CRYPTO 2014, Part I. LNCS, vol. 8616, pp. 57–76. Springer, Heidelberg (2014). doi: 10.1007/978-3-662-44371-2_4 CrossRefGoogle Scholar
- 2.Baysal, A., Sahin, S.: RoadRunneR: a small and fast bitslice block cipher for low cost 8-bit processors. In: Güneysu, T., Leander, G., Moradi, A. (eds.) LightSec 2015. LNCS, vol. 9542, pp. 58–76. Springer, Heidelberg (2016). doi: 10.1007/978-3-319-29078-2_4 CrossRefGoogle Scholar
- 3.Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S., Weeks, B., Wingers, L.: The SIMON and SPECK families of lightweight block ciphers. Cryptology ePrint Archive, Report 2013/404 (2013). http://eprint.iacr.org/
- 4.Bellare, M., Guérin, R., Rogaway, P.: XOR MACs: new methods for message authentication using finite pseudorandom functions. In: Coppersmith, D. (ed.) CRYPTO 1995. LNCS, vol. 963, pp. 15–28. Springer, Heidelberg (1995). doi: 10.1007/3-540-44750-4_2 Google Scholar
- 5.Bellare, M., Kilian, J., Rogaway, P.: The security of cipher block chaining. In: Desmedt, Y.G. (ed.) CRYPTO 1994. LNCS, vol. 839, pp. 341–358. Springer, Heidelberg (1994). doi: 10.1007/3-540-48658-5_32 Google Scholar
- 6.Bellare, M., Pietrzak, K., Rogaway, P.: Improved security analyses for CBC MACs. In: Shoup, V. (ed.) CRYPTO 2005. LNCS, vol. 3621, pp. 527–545. Springer, Heidelberg (2005). doi: 10.1007/11535218_32 CrossRefGoogle Scholar
- 7.Benadjila, R., Guo, J., Lomné, V., Peyrin, T.: Implementing lightweight block ciphers on x86 architectures. In: Lange, T., Lauter, K., Lisoněk, P. (eds.) SAC 2013. LNCS, vol. 8282, pp. 324–352. Springer, Heidelberg (2014). doi: 10.1007/978-3-662-43414-7_17 CrossRefGoogle Scholar
- 8.Bernstein, D.J.: How to stretch random functions: the security of protected counter sums. J. Cryptology
**12**(3), 185–192 (1999). doi: 10.1007/s001459900051 MathSciNetCrossRefzbMATHGoogle Scholar - 9.Biryukov, A. (ed.): FSE 2007. LNCS, vol. 4593. Springer, Heidelberg (2007)zbMATHGoogle Scholar
- 10.Black, J.A., Rogaway, P.: A block-cipher mode of operation for parallelizable message authentication. In: Knudsen, L.R. (ed.) EUROCRYPT 2002. LNCS, vol. 2332, pp. 384–397. Springer, Heidelberg (2002). doi: 10.1007/3-540-46035-7_25 CrossRefGoogle Scholar
- 11.Bogdanov, A.A., Knudsen, L.R., Leander, G., Paar, C., Poschmann, A., Robshaw, M., Seurin, Y., Vikkelsoe, C.: PRESENT: an ultra-lightweight block cipher. In: Paillier, P., Verbauwhede, I. (eds.) CHES 2007. LNCS, vol. 4727, pp. 450–466. Springer, Heidelberg (2007). doi: 10.1007/978-3-540-74735-2_31 CrossRefGoogle Scholar
- 12.Borghoff, J., Canteaut, A., Güneysu, T., Kavun, E.B., Knezevic, M., Knudsen, L.R., Leander, G., Nikov, V., Paar, C., Rechberger, C., Rombouts, P., Thomsen, S.S., Yalçin, T.: PRINCE - a low-latency block cipher for pervasive computing applications - extended abstract. In: Wang, X., Sako, K. (eds.) [41], pp. 208–225. http://dx.org/10.1007/978-3-642-34961-4_14
- 13.De Cannière, C., Dunkelman, O., Knežević, M.: KATAN and KTANTAN — a family of small and efficient hardware-oriented block ciphers. In: Clavier, C., Gaj, K. (eds.) CHES 2009. LNCS, vol. 5747, pp. 272–288. Springer, Heidelberg (2009). doi: 10.1007/978-3-642-04138-9_20 CrossRefGoogle Scholar
- 14.Daemen, J., Peeters, M., Van Assche, G., Rijmen, V.: Nessie proposal: Noekeon. In: First Open Nessie Workshop (2000)Google Scholar
- 15.Daemen, J., Rijmen, V.: AES proposal: Rijndael. In: First Advanced Encryption Standard (AES) Conference (1998)Google Scholar
- 16.Dodis, Y., Pietrzak, K.: Improving the security of MACs via randomized message preprocessing. In: Biryukov, A. (ed.) [9], pp. 414–433. http://dx.org/10.1007/978-3-540-74619-5_26
- 17.Gérard, B., Grosso, V., Naya-Plasencia, M., Standaert, F.-X.: Block ciphers that are easier to mask: how far can we go? In: Bertoni, G., Coron, J.-S. (eds.) CHES 2013. LNCS, vol. 8086, pp. 383–399. Springer, Heidelberg (2013). doi: 10.1007/978-3-642-40349-1_22 CrossRefGoogle Scholar
- 18.Gong, Z., Nikova, S., Law, Y.W.: KLEIN: a new family of lightweight block ciphers. In: Juels, A., Paar, C. (eds.) RFIDSec 2011. LNCS, vol. 7055, pp. 1–18. Springer, Heidelberg (2012). doi: 10.1007/978-3-642-25286-0_1 Google Scholar
- 19.Grosso, V., Leurent, G., Standaert, F.-X., Varıcı, K.: LS-designs: bitslice encryption for efficient masked software implementations. In: Cid, C., Rechberger, C. (eds.) FSE 2014. LNCS, vol. 8540, pp. 18–37. Springer, Heidelberg (2015). doi: 10.1007/978-3-662-46706-0_2 Google Scholar
- 20.Gueron, S.: Intel Advanced Encryption Standard (AES) Instructions Set. Intel White paper, September 2012Google Scholar
- 21.Guo, J., Peyrin, T., Poschmann, A., Robshaw, M.J.B.: The LED block cipher. In: Preneel, B., Takagi, T. (eds.) [35], pp. 326–341. http://dx.org/10.1007/978-3-642-23951-9_22 Google Scholar
- 22.Hong, D., Lee, J.-K., Kim, D.-C., Kwon, D., Ryu, K.H., Lee, D.-G.: LEA: a 128-bit block cipher for fast encryption on common processors. In: Kim, Y., Lee, H., Perrig, A. (eds.) WISA 2013. LNCS, vol. 8267, pp. 1–24. Springer, Heidelberg (2014). doi: 10.1007/978-3-319-05149-9_1 CrossRefGoogle Scholar
- 23.Hong, D., Sung, J., Hong, S.H., Lim, J.-I., Lee, S.-J., Koo, B.-S., Lee, C.-H., Chang, D., Lee, J., Jeong, K., Kim, H., Kim, J.-S., Chee, S.: HIGHT: a new block cipher suitable for low-resource device. In: Goubin, L., Matsui, M. (eds.) CHES 2006. LNCS, vol. 4249, pp. 46–59. Springer, Heidelberg (2006). doi: 10.1007/11894063_4 CrossRefGoogle Scholar
- 24.Iwata, T., Kurosawa, K.: Stronger security bounds for OMAC, TMAC, and XCBC. In: Johansson, T., Maitra, S. (eds.) INDOCRYPT 2003. LNCS, vol. 2904, pp. 402–415. Springer, Heidelberg (2003). doi: 10.1007/978-3-540-24582-7_30 CrossRefGoogle Scholar
- 25.Journault, A., Standaert, F.X., Varici, K.: Improving the security and efficiency of block ciphers based on LS-designs. In: Proceedings of the 9th International Workshop on Coding and Cryptography, WCC 2015 (2015)Google Scholar
- 26.Karakoç, F., Demirci, H., Harmancı, A.E.: ITUbee: a software oriented lightweight block cipher. In: Avoine, G., Kara, O. (eds.) LightSec 2013. LNCS, vol. 8162, pp. 16–27. Springer, Heidelberg (2013). doi: 10.1007/978-3-642-40392-7_2 CrossRefGoogle Scholar
- 27.Leander, G., Paar, C., Poschmann, A., Schramm, K.: New lightweight DES variants. In: Biryukov, A. (ed.) [9], pp. 196–210. http://dx.org/10.1007/978-3-540-74619-5_13
- 28.Lim, C.H., Korkishko, T.: mCrypton – a lightweight block cipher for security of low-cost RFID tags and sensors. In: Song, J.-S., Kwon, T., Yung, M. (eds.) WISA 2005. LNCS, vol. 3786, pp. 243–258. Springer, Heidelberg (2006). doi: 10.1007/11604938_19 CrossRefGoogle Scholar
- 29.Matsuda, S., Moriai, S.: Lightweight cryptography for the cloud: exploit the power of bitslice implementation. In: Prouff, E., Schaumont, P. (eds.) CHES 2012. LNCS, vol. 7428, pp. 408–425. Springer, Heidelberg (2012). doi: 10.1007/978-3-642-33027-8_24 CrossRefGoogle Scholar
- 30.Mouha, N., Mennink, B., Van Herrewege, A., Watanabe, D., Preneel, B., Verbauwhede, I.: Chaskey: an efficient MAC algorithm for 32-bit microcontrollers. In: Joux, A., Youssef, A. (eds.) SAC 2014. LNCS, vol. 8781, pp. 306–323. Springer, Heidelberg (2014). doi: 10.1007/978-3-319-13051-4_19 CrossRefGoogle Scholar
- 31.Nandi, M.: Improved security analysis for OMAC as a pseudorandom function. J. Math. Cryptology
**3**(2), 133–148 (2009)MathSciNetCrossRefzbMATHGoogle Scholar - 32.Nandi, M., Mandal, A.: Improved security analysis of PMAC. J. Math. Cryptology
**2**(2), 149–162 (2008)MathSciNetCrossRefzbMATHGoogle Scholar - 33.Needham, R.M., Wheeler, D.J.: Tea extensions. Computer Laboratory, University of Cambridge (Technical report), October 1997. http://www.cix.co.uk/~klockstone/xtea.pdf.
- 34.Pietrzak, K.: A tight bound for EMAC. In: Bugliesi, M., Preneel, B., Sassone, V., Wegener, I. (eds.) ICALP 2006. LNCS, vol. 4052, pp. 168–179. Springer, Heidelberg (2006). doi: 10.1007/11787006_15 CrossRefGoogle Scholar
- 35.Preneel, B., Takagi, T. (eds.): CHES 2011. LNCS, vol. 6917. Springer, Heidelberg (2011). doi: 10.1007/978-3-642-23951-9 zbMATHGoogle Scholar
- 36.Rivest, R.L.: The RC5 encryption algorithm. In: Preneel, B. (ed.) FSE 1994. LNCS, vol. 1008, pp. 86–96. Springer, Heidelberg (1995). doi: 10.1007/3-540-60590-8_7 CrossRefGoogle Scholar
- 37.Shibutani, K., Isobe, T., Hiwatari, H., Mitsuda, A., Akishita, T., Shirai, T.: Piccolo: an ultra-lightweight blockcipher. In: Preneel, B., Takagi, T. (eds.) [35], pp. 342–357. http://dx.org/10.1007/978-3-642-23951-9_23 Google Scholar
- 38.Shirai, T., Shibutani, K., Akishita, T., Moriai, S., Iwata, T.: The 128-bit blockcipher CLEFIA (extended abstract). In: Biryukov, A. (ed.) [9], pp. 181–195. http://dx.org/10.1007/978-3-540-74619-5_12 Google Scholar
- 39.Standaert, F.-X., Piret, G., Gershenfeld, N., Quisquater, J.-J.: SEA: a scalable encryption algorithm for small embedded applications. In: Domingo-Ferrer, J., Posegga, J., Schreckling, D. (eds.) CARDIS 2006. LNCS, vol. 3928, pp. 222–236. Springer, Heidelberg (2006). doi: 10.1007/11733447_16 CrossRefGoogle Scholar
- 40.Suzaki, T., Minematsu, K., Morioka, S., Kobayashi, E.: TWINE: a lightweight block cipher for multiple platforms. In: Knudsen, L.R., Wu, H. (eds.) SAC 2012. LNCS, vol. 7707, pp. 339–354. Springer, Heidelberg (2013). doi: 10.1007/978-3-642-35999-6_22 CrossRefGoogle Scholar
- 41.Wang, X., Sako, K. (eds.): ASIACRYPT 2012. LNCS, vol. 7658. Springer, Heidelberg (2012). doi: 10.1007/978-3-642-34961-4 Google Scholar
- 42.Wu, W., Zhang, L.: LBlock: a lightweight block cipher. In: Lopez, J., Tsudik, G. (eds.) ACNS 2011. LNCS, vol. 6715, pp. 327–344. Springer, Heidelberg (2011). doi: 10.1007/978-3-642-21554-4_19 CrossRefGoogle Scholar
- 43.Yang, G., Zhu, B., Suder, V., Aagaard, M.D., Gong, G.: The simeck family of lightweight block ciphers. In: Güneysu, T., Handschuh, H. (eds.) CHES 2015. LNCS, vol. 9293, pp. 307–329. Springer, Heidelberg (2015). doi: 10.1007/978-3-662-48324-4_16 CrossRefGoogle Scholar
- 44.Yasuda, K.: The sum of CBC MACs is a secure PRF. In: Pieprzyk, J. (ed.) CT-RSA 2010. LNCS, vol. 5985, pp. 366–381. Springer, Heidelberg (2010). doi: 10.1007/978-3-642-11925-5_25 CrossRefGoogle Scholar
- 45.Yasuda, K.: A new variant of PMAC: beyond the birthday bound. In: Rogaway, P. (ed.) CRYPTO 2011. LNCS, vol. 6841, pp. 596–609. Springer, Heidelberg (2011). doi: 10.1007/978-3-642-22792-9_34 CrossRefGoogle Scholar
- 46.Yasuda, K.: PMAC with parity: minimizing the query-length influence. In: Dunkelman, O. (ed.) CT-RSA 2012. LNCS, vol. 7178, pp. 203–214. Springer, Heidelberg (2012). doi: 10.1007/978-3-642-27954-6_13 CrossRefGoogle Scholar
- 47.Zhang, L., Wu, W., Sui, H., Wang, P.: 3kf9: enhancing 3GPP-MAC beyond the birthday bound. In: Wang, X., Sako, K. (eds.) [41], pp. 296–312. http://dx.org/10.1007/978-3-642-34961-4_19 Google Scholar
- 48.Zhang, W., Bao, Z., Lin, D., Rijmen, V., Yang, B., Verbauwhede, I.: RECTANGLE: A Bit-slice Lightweight Block Cipher Suitable for Multiple Platforms. Cryptology ePrint Archive, Report 2014/084 (2014). http://eprint.iacr.org/
- 49.Zhang, Y.: Using an error-correction code for fast, beyond-birthday-bound authentication. In: Nyberg, K. (ed.) CT-RSA 2015. LNCS, vol. 9048, pp. 291–307. Springer, Heidelberg (2015). doi: 10.1007/978-3-319-16715-2_16 Google Scholar