SIMON and SPECK: Block Ciphers for the Internet of Things

Ray Beaulieu Douglas Shors Jason Smith Stefan Treatman-Clark Bryan Weeks Louis Wingers

National Security Agency 9800 Savage Road, Fort Meade, MD, 20755, USA

rayb@ccrwest.org, {djshors, jksmit3, sgtreat, beweeks, lrwinge}@tycho.ncsc.mil

9 July 2015

Abstract

The U.S. National Security Agency (NSA) developed the Simon and Speck families of lightweight block ciphers as an aid for securing applications in very constrained environments where AES may not be suitable. This paper summarizes the algorithms, their design rationale, along with current cryptanalysis and implementation results.

1 Introduction

Biologists make a distinction between specialist species, which occupy narrow ecological niches, and generalists, which can survive in a broader variety of environmental conditions. Specialists include Kirtland's warbler, a bird that only nests in 5–20 year-old jack pine forests, and the koala, which feeds (almost) exclusively on eucalyptus leaves. Generalists such as the American crow and the coyote are able to adapt to a variety of dierent environments. In a stable world, it's a good strategy to specialize, but when conditions change rapidly, specialists don't always fare so well.

The new age of pervasive computing is nothing if not rapidly changing. And yet, in the world of lightweight cryptography, specialists abound. Of course there are important research challenges associated with optimizing performance on particular platforms, and the direction taken by many in the eld has been to take on such challenges, generally quite successfully. This can involve optimizing with respect to the instruction set for a certain microcontroller, or designing algorithms for a particular ASIC

application (e.g., with hard-wired key or for IC printing), or designing specically for low-latency applications, and so on.

We would argue that what's needed in the Internet of Things (IoT) era is not more Kirtland's warblers and koalas, as wonderful as such animals may be, but crows and coyotes. An animal that eats only eucalyptus leaves, even if it outcompetes the koala, will never become widely distributed. Similarly, a block cipher highly optimized for performance on a particular microcontroller will likely be outcompeted on other platforms, and could be of very limited utility in 15 years when its target platform is obsolete.

Of course it's hard to get a handle on block cipher performance on devices that don't yet exist. But what we can do is strive for simplicity, by designing algorithms around very basic operations that are certain to be supported by any future device capable of computation. Simon and Speck aim to be the sort of generalist block ciphers that we think will be required for future applications in the IoT era.

It would be unsatisfactory if we had to defer any discussion of performance because we're waiting for the arrival of future devices. But we can measure performance on current platforms, and in this paper we demonstrate the sort of performance that is achieved by Simon and Speck on a broad range of existing software and hardware platforms. We emphasize, however, that the main point is not the performance of Simon and Speck with respect to other algorithms on any particular platform. Rather, it's that by limiting the operations we rely on to a small list that works well in hardware and software, we obtain algorithms that are likely to perform well just about anywhere.

^∗This paper was accepted for the NIST Lightweight Cryptography Workshop, 20-21 July 2015.

2 AES and Lightweight Cryptography

Before focusing our discussion on Simon and Speck, we'd like to better establish the state of play. In particular, we note that quite a lot of eort has gone into reshaping the current go-to block cipher, AES, into a solution for lightweight applications. Indeed, great strides have been made in this direction in the past 15 years or so. ASIC implementations of AES-128 have been developed with an area of just 2400 gate equivalents (GE) [\[41\]](#page-13-0) and fast software implementations are available for 8-bit [\[44\]](#page-14-0) and 16-bit [\[21\]](#page-13-1) microcontrollers.

However, there are limits as to how far these types of adaptations can be pushed. They tend to fall short of what is required for today's most constrained environments, and surely won't meet tomorrow's needs. For example, the consensus has long been that a budget of 2000 GE is all the chip area that might reasonably be allocated for security on the most constrained RFID tags [\[36\]](#page-13-2), and this is well out of reach for AES implementations. On microcontrollers, AES implementations can be very fast but they also tend to be large and complex. Implementations that decrease size or complexity certainly exist, but small implementations tend to be complex (and slow), while simple implementations tend to be large (and slow).

One further point about AES: not every application requires the same high level of security that AES is designed to provide. When resources are scarce, it doesn't always make sense to lavish them on an algorithm providing 128 (or 192 or 256) bits of security when 96 might suce. In addition, the AES block size of 128 bits is not always optimal. An RFID authentication protocol may only ask that 64-bit quantities be encrypted, and demanding 128 bits of state when only 64 are necessary can amount to a signicant waste of chip area.

These are the principal reasons for the development of new lightweight block ciphers, and many new algorithms have been proposed. Since the limitations of AES are more apparent in hardware than in software, most of the best eorts to date have focused on this aspect of the problem. This work has produced designs including PRESENT [\[17\]](#page-12-0), KATAN [\[22\]](#page-13-3), and Piccolo [\[52\]](#page-14-1), each of which has a very small hardware footprint. But none was meant to provide high performance on constrained software-based devices, e.g., 8- and 16-bit microcontrollers. The designers of LED [\[35\]](#page-13-4) and TWINE [\[57\]](#page-14-2) are more intent on

supporting software implementations, but these algorithms retain a bias toward hardware performance.

We believe a lightweight block cipher should be "light" on a wide range of hardware- and softwarebased devices, including ASICs, FPGAs, and 4-, 8-, 16-, and 32-bit microcontrollers. Moreover, as noted in [\[11\]](#page-12-1), many of these devices will interact with a backend server, so a lightweight block cipher should also perform well on 64-bit processors.

It seems clear to us that there is a need for exible secure block ciphers, i.e., ones which can perform well on all of these platforms. Our aim, with the design of Simon and Speck, is to make this sort of block cipher available for future use.

3 The Simon and Speck Block Ciphers

In 2011, prompted by potential U.S. government requirements for lightweight ciphers (e.g., SCADA and logistics applications) and the concerns with existing cryptographic solutions which we've noted above, we began work on the Simon and Speck block cipher families on behalf of the Research Directorate of the U.S. National Security Agency (NSA).

Because our customers will rely on commercial devices, we determined that the only realistic way to make the algorithms available would be to put them in the public domain. Furthermore, because cost will be such an important driver in this area—a fraction of a penny per device may make the dierence between whether a cryptographic solution is viable or not—we were motivated to make Simon and Speck as simple, exible, and lightweight as we could. Our hope was that their availability would make it possible to raise the security bar for future IoT devices.

The development process culminated in the publication of the algorithm specics in June 2013 [\[9\]](#page-12-2). Prior to this, Simon and Speck were analyzed by NSA cryptanalysts and found to have security commensurate with their key lengths; i.e., no weaknesses were found. Perhaps more importantly, the algorithms have been pretty heavily scrutinized by the international cryptographic community for the last two years (see, e.g., [\[2\]](#page-12-3), [\[3\]](#page-12-4), [\[5\]](#page-12-5), [\[4\]](#page-12-6), [\[1\]](#page-12-7), [\[6\]](#page-12-8), [\[15\]](#page-12-9), [\[16\]](#page-12-10), [\[20\]](#page-12-11), [\[27\]](#page-13-5), [\[29\]](#page-13-6), [\[37\]](#page-13-7), [\[47\]](#page-14-3), [\[51\]](#page-14-4), [\[53\]](#page-14-5), [\[56\]](#page-14-6), [\[59\]](#page-14-7), [\[62\]](#page-14-8), [\[60\]](#page-14-9), [\[30\]](#page-13-8), [\[7\]](#page-12-12), [\[25\]](#page-13-9), [\[42\]](#page-13-10), [\[24\]](#page-13-11)). Table 1 summarizes the cryptanalytic results as of this writing that attack the most rounds of Simon and Speck. (We note that the recent paper [\[7\]](#page-12-12) purports to attack 24 rounds of Simon 32/64. The author informs us that this paper is currently under revision,

Table 1: Security of Simon and Speck.

and we have therefore not included those results in Table 1. For more, see the comments regarding this work in [\[24\]](#page-13-11).) The content of the table is simple: there are no attacks on any member of the Simon or Speck families, and each block cipher maintains a healthy security margin.

As we see in the table, Simon and Speck are not simply block ciphers, but are block cipher families, each family comprising ten distinct block ciphers with differing block and key sizes to closely t application requirements.

We will write Simon 2n/mn to mean the Simon block cipher with a 2n-bit block and m-word (mn-bit) key. We will sometimes suppress mention of the key and just write Simon 128, for example, to refer to a version of Simon with a 128-bit block. The analogous notation is used for Speck.

The block and key sizes we support are shown in Table 2. The range here goes from tiny to large: a 32 bit block with a 64-bit key at the low end, to a 128-bit block with a 256-bit key at the high end.

We note that key lengths below 80 bits or so do not provide an especially high level of security, but they may still be useful for certain highly constrained applications where nothing better is possible.

Table 2: Simon and Speck parameters.

The desire for exibility through simplicity motivated us to limit the operations used within Simon and Speck to the following short list:

• modular addition and subtraction, + and −,
• bitwise XOR, ⊕,
• bitwise AND, &,
• left circular shift, S j , by j bits, and
• right circular shift, S −j , by j bits.

Speck gets its nonlinearity from the modular addition operation, which slightly favors software performance over hardware. Simon's nonlinear function is a bitwise AND operation, which tends to favor hardware over software. But modular addition can be computed eciently in hardware, and similarly, bitwise AND is easy and natural in software.

The round functions for Simon 2n and Speck 2n each take as input an n-bit round key k, together with two n-bit intermediate ciphertext words. For Simon, the round function is the 2-stage Feistel map

where f (x) (Sx & S ⁸x) ⊕ S ²x and k is the round key. For Speck, the round function is the (Feistelbased) map

with rotation amounts α 7 and β 2 if n 16 (block size 32) and α 8 and β 3 otherwise.

The round functions are composed some number of times which depends on the block and key size. See Table 1.

Each algorithm also requires a key schedule to turn a key into a sequence of round keys. We briey describe the key schedules, but refer the reader to [\[9\]](#page-12-2) for complete details.

For Simon, if we let the key value be k0, . . . , km−¹ (m ∈ {2, 3, 4} is the number of key words), the sequence of round keys is k0, k1, k2, . . . , where

depending on whether m is 2, 3, or 4, respectively. The values Cⁱ , Dⁱ , and Eⁱ are round constants which serve to eliminate slide properties; we omit discussion of them here. I is the n × n identity matrix.

Like Simon, Speck has 2-, 3-, and 4-word key schedules. Speck's key schedules are based on its round function, as follows. We let m be the number of words of key, and we write the key as (<em>m</em>−2, . . . , 0, k0). We then generate two sequences kⁱ and `ⁱ by

\ell_{i+m-1} = (k_i + S^{-\alpha}\ell_i) \oplus i and k_{i+1} = S^{\beta}k_i \oplus \ell_{i+m-1}.

The value kⁱ is the ith round key, for i ≥ 0. Note the round counter i here which serves to eliminate slide properties.

Eciency and security are competing goals in cryptographic design, and understanding how to strike the right balance is the primary challenge faced by a designer. If security is not important, eciency is easy: do nothing! Conversely, if eciency doesn't matter, then it makes sense to build a round function using the most secure cryptographic components available, and then iterate an absurdly large number of times. But in the real world both of these things matter, and we'd like to design algorithms that are maximally ecient, while still providing the advertised level of security, as determined by the key size.

There is an important intellectual challenge associated with understanding optimally secure cryptographic components such as 8-bit S-boxes. However, we would argue that the way to design ecient cryptography, particularly cryptography for constrained platforms, is to forgo them in favor of very simple components, iterating an appropriate number of times to obtain a secure algorithm. Such simple components are by their nature cryptographically weak, making them unappealing to some designers. But

simplicity enables compact implementations, and deciding on appropriate numbers of rounds is possible with analysis.

The question is whether there is something inherently wrong with this approach. It seems clear to us that there isn't: After all, a complex round function can always be factored into a composition of simple functions (transpositions, even), and so every block cipher is a composition of simple functions. It's just that in general the decomposition into simple functions is not useful to an implementer, because the factors tend to be unrelated, and so there is no associated ecient implementation of the algorithm. Viewed this way, we could imagine that Simon and Speck are based on complex round functions—a "round" in this sense may in fact mean eight of the usual rounds but we've worked to make those complex round functions factor into identical functions, at least up to the translations by round key.

We now discuss in a bit more detail the thinking that went into the design of Simon and Speck.

Nonlinear and Linear Components

Most designers of lightweight block ciphers employ Sboxes to provide nonlinearity; a notable feature of Simon and Speck is their lack of dependence on S-boxes. The appeal of S-boxes is that, when used as a part of a substitution-permutation network (SPN), they allow for relatively easy security arguments, at least with respect to standard attacks. But for eciency on constrained platforms, we believe that these sorts of designs are not optimal. We prefer to increase the one-time work necessary to do the cryptanalysis, in order to reduce the every-time work of encryption and decryption.

Lightweight block ciphers often use bit permutations as part of an SPN. The role of these bit permutations is to spread bits around in some optimal manner, and therefore allow SPN-style security arguments. If the target platform is an ASIC this is a perfectly reasonable thing to do, as such permutations are essentially free. But if we care about software implementations at all, then extreme care must be taken to ensure that the bit permutation can be done eciently on a microprocessor. The bit permutations we use are all circular shifts, which are easy to eect on just about any platform. While we lose something in diusion rates as compared with more general bit permutations, we are able to achieve signicant

improvements in software performance, even when increased round numbers are factored in.

One might argue that arbitrary bit permutations are ne in software, because ecient bit-sliced implementations are possible. However, it doesn't seem wise to rely on these, as they have drawbacks including relatively expensive data transpose operations on the plaintext and ciphertext, and the inability to eciently encrypt single plaintext blocks (and single encryptions will be necessary for many lightweight communication and authentication protocols). In addition, the code size and the RAM requirements tend to be quite large, making such implementations unsuitable for some lightweight applications.

Parameters

Both Simon and Speck are equipped with a single set of rotation parameters for all variants (with the exception of the smallest version of Speck, which has its own set of parameters). Besides allowing a succinct description of the family, this uniformity helps reduce the risk of coding errors whereby a programmer might mistakenly use the Simon 64/128 parameters, say, for Simon 128/128.

Many microcontrollers only support shifts by a single bit; the result is that a rotation by two bits is twice as expensive as a rotation by one bit. On the other hand, 8-bit rotations tend to be easy on 8 bit microcontrollers, as they correspond to simple relabelings of registers, and well supported through byte-swap or byte-shue operations on machines with larger word sizes. So for eciency on a variety of software platforms, it's best to keep rotation amounts as close to multiples of eight as possible.

The Simon and Speck rotation amounts were carefully chosen with this consideration in mind. Both algorithms employ 8-bit rotations, and the other rotations used are as close to multiples of 8 as we could make them, without sacricing security.

In-place Operations in Software

Speck's superior performance in software is due in part to the fact that it's possible to implement it entirely with in-place operations, and so moves are unnecessary. This can be seen in the following pseudocode for a round of Speck:

Simon requires some moves, because multiple operations are done on a single word of intermediate ciphertext, and copies need to be made. This fact (combined with the fact that Simon uses a weaker nonlinear function than Speck, and so more rounds are required), makes Speck outperform Simon in software.

Encrypt/Decrypt Symmetry

To enable compact joint implementations of the encryption and decryption algorithms, it's best to make encryption look like decryption. Simon decryption can be accomplished by swapping ciphertext words, reading round keys in reverse order, and then swapping the resulting plaintext words.

We note that Simon beats Speck in this regard (Speck decryption requires modular subtraction, and the rotations are reversed), because its Feistel stepping performs all operations on one word, which is precisely why its software implementations required moves.

Key Schedule Considerations

Speck's reuse of the round function for key scheduling allows for reductions in code size and improves performance for software implementations requiring on-the-y round key generation.

Because Simon was optimized for hardware, it does not take advantage of this software-oriented optimization. Instead, it uses a key schedule which was designed to be a little lighter than the round function.

Of course it is possible to have key schedules even simpler than the ones we have used for Simon and Speck; for example, one can produce round keys simply by cycling through key words. This leads to the possibility of "hard-wiring" the key in an ASIC implementation, thereby saving considerably on area by eliminating any ip-ops needed for holding the key. But such an approach, when used together with very simple round functions, can lead to related-key issues, and we therefore avoided it.

We believe the ability to use hard-wired key is of limited utility, and it runs counter to our exibility goal by optimizing for a particular sort of use, perhaps to the detriment of other uses in the form of increased numbers of rounds or cryptanalytic weaknesses. Our key schedules do the minimal mixing that we thought would eliminate the threat of relatedkey attacks.

Both block ciphers include round constants, which serve to eliminate slide issues. Speck, where design choices were made to favor software over hardware, uses one-up counters. Simon achieves a small savings in hardware (at a small cost in software) by using a sequence of 1-bit constants generated by a 5-bit linear register.

As a nal point, we omit plaintext and ciphertext key whitening operations, as such operations would increase circuit and code sizes. This means that the rst and last rounds of the algorithms do nothing cryptographically, beyond introducing the rst and last round keys.

We conclude this section by pointing to some work that we think helps to validate our approach to the design of Simon and Speck. Designing an algorithm to perform well on a particular platform is a straightforward proposition; we believe the real test is performance on unintended platforms, in particular platforms which may not even exist today.

As we've noted, it's hard to get a handle on an issue like this, but we have one data point that's interesting: Because of its simplicity (more precisely, its low multiplicative depth), Simon has been picked up by more than one team [\[38\]](#page-13-12), [\[23\]](#page-13-13) for use in the decidedly non-lightweight world of homomorphic encryption.

In this section, we quickly summarize implementation results for Simon and Speck on constrained platforms, beginning with ASICs and FPGAs, and then moving on to microcontrollers.

ASICs

Until recently, designers of lightweight cryptography primarily took aim at ASIC performance. As a result there are a number of excellent ASIC designs (see Table 3\), all of which can be implemented with substantially less area than the 2400 GE required by

AES. Much of this improvement is possible because of the hardware complexity of AES components, in particular its S-box. But a signicant gain comes from the recognition that a 128-bit block size is not always required for constrained applications, and there is a considerable area savings to be had by reducing to a 64-bit block.

As we've noted, care must be taken with an ASIC design, or else software performance can suer. Software performance is indeed a weakness of a number of existing algorithms. Simon and Speck have improved on the state of the art for hardware implementation, while also oering leading software performance.

Simon has ASIC implementations with the smallest areas achieved to date, when compared with block ciphers with the same block and key size and with exible key. This is because the logic required for a bit-serial implementation (meaning that only one bit of the round function is computed per clock cycle) is minimal: computing a bit of the round function requires just one AND and three XORs, and so there isn't much room for further improvement. There is of course additional logic required for control (which we've also worked to minimize), and a few XORs are needed in the key schedule, etc., but for the smallest implementations, almost all the area is used by the ip-ops required to store the state.

Because the logic required to compute a bit of the round function is so small, implementations of Simon scale nicely: two bits or more can be updated in one clock cycle with minimal impact on area.

Speck is not far behind Simon with respect to small ASIC implementations. The primary dierences are that Simon's AND gets replaced with a full adder, and some additional multiplexing is required because of how the state updates. Its area also scales well, but not quite as well as Simon's.

In the remainder of this section, we provide area and throughput data to illustrate the ASIC performance of Simon and Speck.

Our ASIC implementations were done in VHDL and synthesized using Synopsys Design Compiler 11.09-SP4 to target the ARM SAGE-X v2.0 standard cell library for IBM's 8RF 130 nm (CMR8SF-LPVT) process. Worst-case operating conditions were assumed. We did not proceed to place and route: in an actual chip there will be interconnect delays that haven't been accounted for, and these delays will likely signicantly aect clock speeds. But we note

that most work in this field—in particular the work cited in this paper—uses this approach, similarly ignoring interconnect delays, so this shouldn't bias our comparisons.

The smallest flip-flop available to us had an area of 4.25 GE. For a block cipher with a 64-bit block and 128-bit key, this means at least 4.25 \cdot 192 = 816 GE are required for flip-flops. Our bit-serial implementations of Simon 64/128 and Speck 64/128 have areas of 958 GE and 996 GE, respectively. This means that they require (at most) 958 – 816 = 142 GE and 996 – 816 = 180 GE, respectively, for all the logic required to compute the round function, key schedule, and do the control, which includes loading the plaintext and reading out ciphertext. And of the 142 GE not devoted to storing the cipher and key for Simon 64/128, 11 \cdot 4.25 = 46.75 GE, or about a third, are flip-flops needed to count rounds in order to signal the end of encryption.

Table 3 compares size-optimized ASIC implementations of Simon, Speck, and some other prominent block ciphers, listing the area and throughput at a fixed 100 kHz clock rate. Note that we show our absolute smallest implementations of Simon and Speck, with correspondingly low throughputs. Throughputs can be doubled, quadrupled, etc., for small area increases. See [9] for data regarding additional implementations. For example, quadrupling the throughput for Simon 128/128 and Speck 128/128 increases the area by just 29 GE and 116 GE, respectively.

An important caveat is that these comparisons consider implementations done by different authors, with perhaps different levels of effort, and using different cell libraries, so it's hard to make really meaningful inferences regarding small differences in the table.

Large differences, on the other hand, are meaningful, and comparing Simon and Speck with AES shows the dramatic savings possible with a lightweight block cipher. At the same security level, Simon and Speck nearly halve AES's 2400 GE area to 1234 and 1280 GE, respectively. Keeping the same 128-bit key size and reducing the block size to 64 bits further drops the areas to 958 and 996 GE. Using smaller block or key sizes results in even greater area reductions.

Some applications won't require areas to be minimized; rather it may be important to maximize efficiency (throughput divided by area, in kbps/GE). The implementations in Table 3 have low efficiency,

Table 3: ASIC performance comparisons at a 100 kHz clock speed optimized for size.

but efficiency can easily be raised by doing additional computation during each clock cycle, in effect to begin to amortize away the fixed cost of storing the state. The flexibility of Simon and Speck mean that many sorts of implementations are possible. See Section 6 for data regarding efficient implementations; in particular implementations which compute a full round per clock cycle, and implementations which fully unroll the algorithms.

We conclude this section by discussing latency, i.e., the time required to encrypt one plaintext block. Low-latency implementations of block ciphers have recently been much discussed; the leading voices have been the authors of [19]. The algorithm they propose, PRINCE, is a clever design which can encrypt in one clock cycle at the impressively small area of 8679 GE [19]. (We note that registers were not counted in this total, and a real system would probably need to register the data, thus increasing the area by about 10% to around 9500 GE.). The recent paper [39] increases the area to 9522 GE (about 10500 GE counting registers), but achieves a record latency of 22.9 ns.

Table 4: Low-latency encrypt-only implementations of PRINCE, Simon, and Speck at 130 nm. The Simon and Speck implementations count 64 + 128 flip flops; the PRINCE implementation doesn't.

It would appear that Simon and Speck are not lowlatency designs, because they require many rounds. However, because of their simplicity, it's possible to compute multiple rounds per clock cycle, while maintaining reasonably good clock speeds. Indeed for Si-MON 64/128, we've found an implementation (at the same 130 nm feature size used in [39]) that almost exactly matches PRINCE's latency and area; it implements the combinational logic for 5 rounds, and encrypts in \lfloor \frac{44}{5} \rfloor = 9 cycles. In spite of its need to compute carry chains, Speck can get within a factor of 2.5 of PRINCE's latency, at a much smaller area. (Three rounds are computed per clock cycle, for a total of \frac{27}{3} + 1 = 10 cycles—our current Speck implementation requires a load cycle, which it should be possible to eliminate with a little more work.) Of course these are not single-cycle implementations, but we don't see a compelling case that such implementations are necessary, particularly at what seem to be artificiallyconstrained clock speeds, and on the sort of devices considered in [39] where clocks are easy to generate. See Table 4, where one Speck and two Simon implementations are shown; many other latency/area trade-offs are possible but are omitted here.

FPGAs

We've shown that it's possible to realize considerable reductions in ASIC area by using Simon or Speck instead of an algorithm such as AES. The advantages of Simon and Speck become even more pronounced on FPGA platforms.

In this section we briefly discuss implementations of the algorithms on the Spartan-3, a low-end FPGA which is often used by cryptographers for comparisons. Table 5 presents some of these results for AES and PRESENT, alongside results for our algorithms.

Table 5: FPGA performance comparisons on low-cost Xilinx Spartan FPGAs. All implementations are on the Spartan-3. Results marked with a † are our work. The Simon implementation labeled (DPA) is resistant to first-order DPA.

On this platform, the smallest reported implementation of AES-128 requires 184 slices [26]. Remarkably, Simon 128/128 can be implemented in just 28 slices (15% of the size of AES), and Speck 128/128 can be done in 36 slices (20% of AES's size). Comparisons with PRESENT also show dramatic area reductions: PRESENT-128 requires 117 slices; the comparable Simon 64/128 and Speck 64/128 algorithms require 24 and 34 slices—21% and 30% of the area—respectively.

If higher throughputs are required, area reductions are still possible, as can be seen in Table 5.

Other authors have reported Simon implementation results [13, 8, 34, 49] which are in line with our results, and extend them. In [34], it is shown that a joint implementation of all 10 versions of Simon can be done using 90 slices on the Spartan-3, which is about half the size of a single AES-128 implementation. The 87-slice implementation of Simon 128/128 described in [49] provides resistance to first-order differential power analysis, again at about half the area of an unprotected AES-128 implementation.

Microcontrollers

We turn now to software implementations on 8-bit, 16-bit, and low-end 32-bit microcontrollers. Table 6

| | | | | ecient implementations | | | |

| | | | | fast implementations | | | |

Table 6: Assembly implementations on the 8-bit AVR ATmega128 and 16-bit MSP430 microcontrollers.

shows ROM and RAM usage and encryption cost (in cycles/byte) for assembly implementations of Simon, Speck, and a few other algorithms \[43, [44\]](#page-14-0). The rst half of the table shows implementations optimized for eciency1 and the second half implementations optimized for speed.

The data for PRESENT exemplies the potential diculty of adapting hardware-oriented algorithms to software; this algorithm is unable to match the performance of AES, and is easily beaten by Simon and Speck in both throughput and code size.2

For high-speed applications on the 8-bit AVR microcontroller, AES-128 is the fastest 128-bit block cipher we know of, beating Speck 128/128 by about 17%. However, because of its low memory usage, Speck 128/128 has higher eciency than AES-128. And as key sizes increase, Speck overtakes AES in throughput because of how round numbers scale. Moreover, Speck 64/128, which has the same key size as AES-128, but a smaller block, is both smaller and slightly faster than AES-128.

On the 16-bit MSP430, Speck is the highest in e ciency and throughput. It is 23% faster than AES, uses

no RAM and 81% less ROM. In [\[21\]](#page-13-1) this performance advantage resulted in a 35% lower energy consumption compared to AES. Speck 64/128 consumes even fewer resources for the many applications where a smaller block size is acceptable.

Others' work supports our conclusions. In [\[28\]](#page-13-21), C implementations of AES, Simon 64/96, Speck 64/96, and ten other lightweight algorithms are compared on the 8-bit AVR, 16-bit MSP430, and 32-bit ARM Cortex-M3 microcontrollers. Algorithms were ranked in two usage scenarios using a gure of merit balancing performance, RAM, and code size across the three platforms. Speck and Simon place rst and fourth in a large data scenario and rst and second in a scenario involving encryption of a single block.

On the 32-bit ARM processor, the authors of this paper nd Speck and Simon to be simultaneously the smallest and fastest block ciphers for both of the scenarios they consider. We point out, however, that their C implementations of AES are faster than those of Speck on the 8-bit and 16-bit platforms by about a factor of two, presumably due to the GNU C compiler's poor handling of rotations. Implementing the rotations in assembly should lead to greatly improved performance for our rotation-dependent designs.

It is our opinion that for lightweight applications on microcontrollers, if high performance is important, then Simon and Speck should be coded in assembly:

¹We dene eciency to be encryption throughput in bytes per cycle, divided by ROM + 2 · RAM. See [\[10\]](#page-12-16).

²We note that there is a faster bit-sliced implementation of PRESENT [\[45\]](#page-14-15), which encrypts at 370.875 cycles per byte, plus about 40 cycles per byte for data transposition operations. But it's much larger, requiring 3816 bytes of ROM and 256 bytes of RAM.

Table 7: Ecient, high-throughput 130 nm ASIC implementations of Simon and Speck

because of the simplicity of the algorithms, these implementations are pretty straightforward, and they can improve performance by up to a factor of ve over C implementations. Details on such implementations on the AVR microcontroller can be found in [\[10\]](#page-12-16).

Constrained devices will need to communicate with other, similar devices, but will also need to communicate with higher-end systems. These systems may perform functions such as aggregating sensor or inventory data. To facilitate these sorts of interactions, and in particular to support ecient communication with large numbers of constrained devices, lightweight algorithms will need to perform well on both lightweight and "heavyweight" platforms.

High-throughput ASIC Implementations

Table 7 shows a sample of higher-throughput implementations on the same 130 nm ASIC process used to generate the Simon and Speck data in Table 3. Decryption is not supported in these implementations, but for Simon, in particular, it could be added at low cost

due to the similarity of the encryption and decryption algorithms.

For each algorithm and block/key size an iterative and two fully-pipelined encryption implementations are presented. In the iterative case, a single copy of the round function is used to loop over the data for a number of cycles equal to the total number of rounds.

In the fully-pipelined case, a number of copies of the round function equal to the number of rounds is implemented, with registers in between. This allows a complete block of ciphertext to be output every clock cycle, once the pipeline is full. One of the fullypipelined implementations is key-agile, meaning that every plaintext block to be encrypted can have its own associated key. The second fully-pipelined implementation is not key-agile: it saves area by requiring that all blocks in the pipeline use the same key, so that only one instance of the key schedule is necessary, rather than one for each level of the pipeline. Changing key for this second sort of implementation requires the new round keys to be loaded and the pipeline to be ushed.

The exibility of Simon and Speck enables all sorts of implementations in between these performance extremes (e.g., iterated versions computing multiple rounds per clock cycle, and pipelined implementa-

Figure 1: Intel Xeon E5640 throughput in cycles/byte (smaller is better) for messages from 1–4096 bytes.

tions with multiple rounds between stages), but we do not have the space to include those results here.

Simon and Speck have compelling advantages for high-throughput ASIC applications. This seems clear, even in view of the diculties inherent in comparing implementations using dierent technologies and libraries. As a point of comparison, we consider the CLEFIA block cipher.3 The designers of that algorithm report on a joint implementation [\[55\]](#page-14-16) of the encryption and decryption algorithms4 which has an eciency of 401, using a 90 nm technology (9339 GE, 3.74 Gbit/s at 572 MHz). This is excellent performance relative to other block ciphers; indeed CLEFIA realizes the "world's highest hardware gate eciency" [\[54\]](#page-14-17).

We did ASIC implementations of Simon and Speck at this same 90 nm feature size. (Note that these results are not reported in Table 7, where the feature size is 130 nm.) Speck has a 8089 GE (encrypt-only) implementation, running at 1.404 GHz, for a throughput of 10.6 Gbit/s and an eciency of 1307. Simon is even better: for 8011 GE, an encrypt-only version runs at 3.066 GHz, for a throughput of 17.1 Gbit/s and an eciency of 2130. There may be dierences in cell libraries, etc. (and we note again that interconnect delays are not considered in our work or in the CLEFIA work), but a factor of ^{2130 401} > 5 improvement is surely signicant.

x86 and ARM Implementations

We have recently studied implementations of Simon and Speck as stream ciphers in counter mode on several higher-end 32-bit and 64-bit processors. These processors are likely to be used in systems such as smartphones, tablets, and servers communicating with constrained devices. We considered the 32 bit Samsung Exynos 5 Dual (which includes NEON SIMD instructions), based on an ARM Cortex-A15, and two 64-bit Intel processors: the Xeon E5640 and Core i7-4770, representing the Westmere and Haswell architectures, respectively. Performance was benchmarked using SUPERCOP [\[12\]](#page-12-17), making for fair comparison with the performance of highly-optimized implementations of AES and ChaCha20, in particular. The Simon and Speck code, all written in C, is available on GitHub [\[63\]](#page-14-18). Figure 1 illustrates the detailed data produced by SUPERCOP.

The overall results are similar on the ARM and the x86 platforms. The C implementations of Simon have better overall performance than the C implementations of AES for 256-bit keys and slightly worse performance for 128-bit keys. The C implementations of Speck 128/256 have better overall performance than the best C implementations of ChaCha20, a stream cipher especially noted for its speed.

Finally, we note that extremely high-performance instantiations of AES are possible on certain processors, for example using Intel's hardware AES-NI instructions. Despite this, Speck in software can come close to matching this high performance: on the Haswell architecture our C implementation of Speck 128/256 is only 33% slower than the AES-NI

³CLEFIA is a lightweight ISO standard which supports highthroughput ASIC implementations.

⁴CLEFIA's symmetry means that there is little overhead in providing decryption functionality. On the other hand, the area won't go down by much for an encrypt-only version.

version of AES-256.

7 Side-Channel Mitigations

The most secure algorithm can become vulnerable to attack if it is implemented in a way that leaks information because power usage or execution time (or something else) is correlated to secret key values. Understanding these sorts of side-channels and how to eliminate them is an important line of research, and it's particularly relevant for constrained devices, which tend to lack physical countermeasures.

We very briey discuss side-channel attacks and mitigations, and note some work in this area involving Simon and Speck.

One sort of side-channel attack exploits keydependent variations in encryption times to recover secret information. Algorithms which are implemented using lookup tables, e.g., AES, on processors with cache memory can be particularly vulnerable to these cache-timing attacks [\[18\]](#page-12-18). Since Simon and Speck have no look-up tables, they are naturally immune to this type of attack.

Perhaps the most important type of side-channel attack uses key-dependent power emanations. Implementations of block ciphers typically are susceptible to such dierential power analysis (DPA) attacks unless countermeasures are taken. Because of Simon's lowdegree round function, masking countermeasures are especially ecient; see \[50, [49\]](#page-14-14). In particular, the second of these papers demonstrate a threshold implementation of Simon 128/128 which provides resistance to rst-order DPA for 87 slices on a Spartan-3 FPGA. This makes it less than half the size of the smallest reported unprotected Spartan-3 implementation of AES, and 25% smaller than unprotected implementations of PRESENT-128. (And PRESENT-128 is not exactly a comparable algorithm, since it has a block size of 64 bits, and the version of Simon they consider has a block size of 128 bits.)

We are not aware of similar work to protect Speck, but there are other countermeasures that apply equally to both Simon and Speck. One such measure aims to confound DPA by partially unrolling an algorithm [\[14\]](#page-12-19). We've done such implementations of Simon and Speck, but don't have the space in this paper to discuss them. Briey, for the 64-bit block and 128-bit key size, there is an ASIC implementation of Simon that computes four full rounds per clock cycle and requires 3290 GE. A similar implementation of

Speck computes three rounds per clock cycle and has an area of 3120 GE. We have not done side channel analysis for these implementations.

Another mitigation uses frequent key updating [\[58\]](#page-14-20). The tiny hardware implementations of Simon and Speck in Tables 3 and 5 are key agile, meaning the key can be changed with each run without incurring a signicant performance penalty, and so they would be good candidates for use with this strategy.

8 Conclusion

We have sought in this paper to demonstrate the sort of performance that Simon and Speck can achieve. Most importantly, Simon and Speck have an edge over other algorithms not in terms of head-to-head comparisons on particular platforms (although it appears that on most platforms one of Simon or Speck is the best existing algorithm, and the other is not far behind), but by virtue of their exibility. This exibility is a consequence of the simplicity of the designs, and means the algorithms admit small ASIC, FPGA, microcontroller, and microprocessor implementations, but can also achieve very high throughput on all of these platforms. Their exibility makes Simon and Speck ideal for use with heterogeneous networks, where algorithms optimized for particular platforms or usages will not be appropriate.

The simplicity of Simon and Speck has additional benets. First, they are very easy to implement, and ecient implementations can be had for minimal work; this is in marked contrast to the situation for algorithms such as AES, where a decade of research was required to nd near-optimal implementations. Coding errors are much easier to avoid for simple algorithms. In addition, simplicity enables relatively cheap side-channel mitigations, and makes the algorithms attractive for unanticipated uses (such as homomorphic encryption). Last, but not least, simplicity makes the algorithms attractive targets for cryptanalysis. Complexity in this regard presents a barrier to entry, and this tends to limit the amount of scrutiny that an algorithm receives. Because of their simplicity (and perhaps because of their source!), Simon and Speck have been quite thoroughly vetted by the cryptographic community in the two years since their publication.

Simon and Speck are also unique among existing lightweight block ciphers in their support for a broad range of block and key sizes, allowing the cryptography to be precisely tuned to a particular application.

We are hopeful that the approach we have taken to the design of Simon and Speck means they will continue to oer high performance on tomorrow's IoT devices.

Bibliography

• [1] M. A. Abdelraheem, J. Alizadeh, H. A. Alkhzaimi, M. R. Aref, N. Bagheri, P. Gauravaram, and M. M. Lauridsen. Improved Linear Cryptanalysis of Reducedround SIMON. Cryptology ePrint Archive, Report 2014/681, 2014. http://eprint.iacr.org/2014/ 681.pdf.
• [2] F. Abed, E. List, S. Lucks, and J. Wenzel. Dierential and Linear Cryptanalysis of Reduced-Round Simon. Cryptology ePrint Archive, Report 2013/526, 2013. .
• [3] F. Abed, E. List, S. Lucks, and J. Wenzel. Dierential Cryptanalysis of Round-reduced Simon and Speck. In Fast Software Encryption, FSE 2014, LNCS. Springer, 2014.
• [4] J. Alizadeh, H. AlKhzaimi, M. R. Aref, N. Bagheri, P. Gauravaram, A. Kumar, M. M. Lauridsen, and S. K. Sanadhya. Cryptanalysis of SIMON Variants with Connections. In Saxena and Sadeghi [\[48\]](#page-14-21), pages 90– 107.
• [5] J. Alizadeh, N. Bagheri, P. Gauravaram, A. Kumar, and S. K. Sanadhya. Linear Cryptanalysis of Round Reduced Simon. Cryptology ePrint Archive, Report 2013/663, 2013. http://eprint.iacr.org/2013/ 663.pdf.
• [6] H. A. Alkhzaimi and M. M. Lauridsen. Cryptanalysis of the SIMON Family of Block Ciphers. Cryptology ePrint Archive, Report 2013/543, 2013. http: //eprint.iacr.org/2013/543.pdf.
• [7] T. Ashur. Improved Linear Trails for the Block Cipher Simon. Cryptology ePrint Archive, Report 2015/285, 2015. .
• [8] A. Aysu, E. Gulcan, and P. Schaumont. SIMON Says, Break the Area Records for Symmetric Key Block Ciphers on FPGAs. Cryptology ePrint Archive, Report 2014/237, 2014. http://eprint.iacr.org/ 2014/237.pdf.
• [9] R. Beaulieu, D. Shors, J. Smith, S. Treatman-Clark, B. Weeks, and L. Wingers. The SIMON and SPECK Families of Lightweight Block Ciphers. Cryptology ePrint Archive, Report 2013/404, 2013. http: //eprint.iacr.org/2013/404.pdf.

• [10] R. Beaulieu, D. Shors, J. Smith, S. Treatman-Clark, B. Weeks, and L. Wingers. The SIMON and SPECK Block Ciphers on AVR 8-bit Microcontrollers. In Eisenbarth and Öztürk [\[32\]](#page-13-22).
• [11] R. Benadjila, J. Guo, V. Lomné, and T. Peyrin. Implementing Lightweight Block Ciphers on x86 Architectures. Cryptology ePrint Archive, Report 2013/445, 2013. .
• [12] D. J. Bernstein and T. Lange. eBACS: ECRYPT Benchmarking of Cryptographic Systems. http://bench. cr.yp.to.
• [13] S. Bhasin, T. Graba, J. Danger, and Z. Najm. A look into SIMON from a side-channel perspective. In Hardware-Oriented Security and Trust, HOST 2014, pages 56–59. IEEE Computer Society, 2014.
• [14] S. Bhasin, S. Guilley, L. Sauvage, and J.-L. Danger. Unrolling Cryptographic Circuits: A Simple Countermeasure Against Side-Channel Attacks. In J. Pieprzyk, editor, Topics in Cryptology – CT-RSA 2010, volume 5985 of LNCS, pages 195–207. Springer, 2010.
• [15] A. Biryukov, A. Roy, and V. Velichkov. Dierential Analysis of Block Ciphers SIMON and SPECK. In Fast Software Encryption, FSE 2014, LNCS. Springer, 2014.
• [16] A. Biryukov and V. Velichkov. Automatic Search for Dierential Trails in ARX Ciphers. In J. Benaloh, editor, Topics in Cryptology - CT-RSA 2014, volume 8366 of LNCS, pages 227–250. Springer, 2014.
• [17] A. Bogdanov, L. R. Knudsen, G. Leander, C. Paar, A. Poschmann, M. J. B. Robshaw, Y. Seurin, and C. Vikkelsoe. PRESENT: An Ultra-Lightweight Blockcipher. In Cryptographic Hardware and Embedded Systems - CHES 2007, volume 4727 of LNCS, pages 450– 466. Springer, 2007.
• [18] J. Bonneau and I. Mironov. Cache-Collision Timing Attacks Against AES. In Cryptographic Hardware and Embedded Systems - CHES 2006, volume 4249 of LNCS, pages 201–215. Springer, 2006.
• [19] J. Borgho, A. Canteaut, T. Güneysu, E. B. Kavun, M. Knežević, L. R. Knudsen, G. Leander, V. Nikov, C. Paar, C. Rechberger, P. Rombouts, S. S. Thomsen, and T. Yalçın. PRINCE — A Low-latency Block Cipher for Pervasive Computing Applications (Full version). Cryptology ePrint Archive, Report 2012/529, 2012. .
• [20] C. Boura, M. Naya-Plasencia, and V. Suder. Scrutinizing and Improving Impossible Dierential Attacks: Applications to CLEFIA, Camellia, LBlock and Simon (Full Version). Cryptology ePrint Archive, Report 2014/699, 2014. http://eprint.iacr.org/ 2014/699.pdf.

• [21] B. Buhrow, P. Riemer, M. Shea, B. Gilbert, and E. Daniel. Block Cipher Speed and Energy Eciency Records on the MSP430: System Design Trade-Os for 16-bit Embedded Applications. Cryptology ePrint Archive, Report 2015/011, 2015. http://eprint. iacr.org/2015/011.pdf.
• [22] C. D. Cannière, O. Dunkelman, and M. Knezevic. KATAN and KTANTAN - A Family of Small and Ef cient Hardware-Oriented Block Ciphers. In Cryptographic Hardware and Embedded Systems - CHES 2009, volume 5747 of LNCS, pages 272–288. Springer, 2009.
• [23] B. Carmer and D. W. Archer. Block Ciphers, Homomorphically. Galois, Inc. Blog, December 2014. http://galois.com/blog/2014/12/ block-ciphers-homomorphically/.
• [24] H. Chen and X. Wang. Improved Linear Hull Attack on Round-Reduced SIMON with Dynamic Keyguessing Techniques. Cryptology ePrint Archive, Report 2015/666, July 2015. http://eprint.iacr.org/ 2015/666.pdf.
• [25] Z. Chen, N. Wang, and X. Wang. Impossible Differential Cryptanalysis of Reduced Round SIMON. Cryptology ePrint Archive, Report 2015/286, 2015. .
• [26] J. Chu and M. Benaissa. Low area memory-free FPGA implementation of the AES algorithm. In D. Koch, S. Singh, and J. Tørrensen, editors, Field Programmable Logic and Applications (FPL) 2012, pages 623–626. IEEE, 2012.
• [27] N. Courtois, T. Mourouzis, G. Song, P. Sepehrdad, and P. Susil. Combined Algebraic and Truncated Dierential Cryptanalysis on Reduced-round Simon. In M. S. Obaidat, A. Holzinger, and P. Samarati, editors, SECRYPT 2014, pages 399–404. SciTePress, 2014.
• [28] D. Dinu, Y. L. Corre, D. Khovratovich, L. Perrin, J. Großschädl, and A. Biryukov. Triathlon of Lightweight Block Ciphers for the Internet of Things. Cryptology ePrint Archive, Report 2015/209, 2015. .
• [29] I. Dinur. Improved Dierential Cryptanalysis of Round-Reduced Speck. In A. Joux and A. M. Youssef, editors, Selected Areas in Cryptography - SAC 2014, volume 8781 of LNCS, pages 147–164. Springer, 2014.
• [30] I. Dinur, O. Dunkelman, M. Gutman, and A. Shamir. Improved Top-Down Techniques in Dierential Cryptanalysis. Cryptology ePrint Archive, Report 2015/268, 2015. .
• [31] T. Eisenbarth, S. S. Kumar, C. Paar, A. Poschmann, and L. Uhsadel. A Survey of Lightweight-Cryptography Implementations. IEEE Design & Test of Computers, 24(6):522–533, 2007.

• [32] T. Eisenbarth and E. Öztürk, editors. Lightweight Cryptography for Security and Privacy - LightSec 2014, volume 8898 of LNCS. Springer, 2014.
• [33] Z. Gong, S. Nikova, and Y. W. Law. KLEIN: A New Family of Lightweight Block Ciphers. In A. Juels and C. Paar, editors, RFID Security and Privacy - RFIDSec 2011, volume 70555 of LNCS, pages 1–18. Springer, 2011.
• [34] E. Gulcan, A. Aysu, and P. Schaumont. A Flexible and Compact Hardware Architecture for the SIMON Block Cipher. In Eisenbarth and Öztürk [\[32\]](#page-13-22).
• [35] J. Guo, T. Peyrin, A. Poschmann, and M. J. B. Robshaw. The LED Block Cipher. In Cryptographic and Embedded Systems - CHES 2011, volume 6917 of LNCS, pages 326–341. Springer, 2011.
• [36] A. Juels and S. A. Weis. Authenticating Pervasive Devices with Human Protocols. In Advances in Cryptology - CRYPTO 2005, volume 3621 of LNCS, pages 293–308. Springer, 2005.
• [37] S. Kölbl, G. Leander, and T. Tiessen. Observations on the SIMON block cipher family. Cryptology ePrint Archive, Report 2015/145, 2015. http://eprint. iacr.org/2015/145.pdf.
• [38] T. Lepoint and M. Naehrig. A Comparison of the Homomorphic Encryption Schemes FV and YASHE. In D. Pointcheval and D. Vergnaud, editors, AFRICACRYPT 2014, volume 8469 of LNCS, pages 318–335. Springer, 2014.
• [39] P. Maene and I. Verbauwhede. Single-Cycle Implementations of Block Ciphers. Cryptology ePrint Archive, Report 2015/658, July 2015. http://eprint. iacr.org/2015/666.pdf.
• [40] K. Minematsu. TWINE Block Cipher. Personal communication regarding results from [\[57\]](#page-14-2), July 2014.
• [41] A. Moradi, A. Poschmann, S. Ling, C. Paar, and H. Wang. Pushing the Limits: A Very Compact and a Threshold Implementation of AES. In Advances in Cryptology - EUROCRYPT 2011, volume 6632 of LNCS, page 69. Springer, 2011.
• [42] T. Mourouzis, G. Song, N. Courtois, and M. Christoi. Advanced Dierential Cryptanalysis of Reduced-Round SIMON64/128 Using Large-Round Statistical Distinguishers. Cryptology ePrint Archive, Report 2015/481, 2015. http://eprint.iacr.org/2015/ 481.pdf.
• [43] D. A. Osvik. Fast Implementations of AES on Various Platforms. Personal communication regarding results from [\[44\]](#page-14-0), June 2014.

• [44] D. A. Osvik, J. W. Bos, D. Stefan, and D. Canright. Fast Software AES Encryption. In Fast Software Encryption, FSE 2010, volume 6147 of LNCS, pages 75–93. Springer, 2010.
• [45] K. Papagiannopoulos. High throughput in slices: the case of PRESENT, PRINCE and KATAN64 ciphers. In Saxena and Sadeghi [\[48\]](#page-14-21), pages 137–155.
• [46] A. Y. Poschmann. Lightweight Cryptography: Cryptographic Engineering for a Pervasive World. PhD thesis, Ruhr University Bochum, 2009.
• [47] R. Rabbaninejad, Z. Ahmadian, M. Salmasizadeh, and M. R. Aref. Cube and Dynamic Cube Attacks on SI-MON32/64. In ISCISC 2014, pages 98–103, 2014.
• [48] N. Saxena and A. Sadeghi, editors. Radio Frequency Identication: Security and Privacy Issues - RFIDSec 2014, volume 8651 of LNCS. Springer, 2014.
• [49] A. Shahverdi, M. Taha, and T. Eisenbarth. Silent Simon: A Threshold Implementation under 100 Slices. Cryptology ePrint Archive, Report 2015/172, 2015. .
• [50] D. Shanmugam, R. Selvam, and S. Annadurai. Differential Power Analysis Attack on SIMON and LED Block Ciphers. In R. S. Chakraborty, V. Matyas, and P. Schaumont, editors, Security, Privacy, and Applied Cryptography Engineering, SPACE 2014, volume 8804 of LNCS, pages 110–125. Springer, 2014.
• [51] D. Shi, L. Hu, S. Sun, L. Song, K. Qiao, and X. Ma. Improved Linear (hull) Cryptanalysis of Round-reduced Versions of SIMON. Cryptology ePrint Archive, Report 2014/973, 2014. http://eprint.iacr.org/ 2014/973.pdf.
• [52] K. Shibutani, T. Isobe, H. Hiwatari, A. Mitsuda, T. Akishita, and T. Shirai. Piccolo: An Ultra-Lightweight Blockcipher. In Cryptographic and Embedded Systems - CHES 2011, volume 6917 of LNCS, pages 342–357. Springer, 2011.
• [53] L. Song, L. Hu, B. Ma, and D. Shi. Match Box Meetin-the-Middle Attacks on the SIMON Family of Block Ciphers. In Eisenbarth and Öztürk [\[32\]](#page-13-22).
• [54] Sony Corporation. CLEFIA: The 128-bit Blockcipher. http://www.sony.net/Products/cryptography/ clefia/.
• [55] T. Sugawara, N. Aoki, and A. Satoh. Highperformance ASIC implementations of the 128-bit block cipher CLEFIA. In International Symposium on Circuits and Systems (ISCAS) 2008, pages 2925–2928. IEEE, 2008.

• [56] S. Sun, L. Hu, P. Wang, K. Qiao, X. Ma, and L. Song. Automatic Security Evaluation and (Related-key) Differential Characteristic Search: Application to SIMON, PRESENT, LBlock, DES(L) and Other Bit-oriented Block Ciphers. In Advances in Cryptology - ASIACRYPT 2014, volume 8874 of LNCS, pages 158–178. Springer, 2014.
• [57] T. Suzaki, K. Minematsu, S. Morioka, and E. Kobayahi. Twine: A Lightweight Block Cipher for Multiple Platforms. In L. R. Knudsen and H. Wu, editors, Selected Areas in Cryptography, SAC 2012, volume 7707 of LNCS, pages 339–354. Springer, 2012.
• [58] M. M. I. Taha and P. Schaumont. Key Updating for Leakage Resiliency With Application to AES Modes of Operation. IEEE Transactions on Information Forensics and Security, 10(3):519–528, 2015.
• [59] Y. Todo. Structural Evaluation by Generalized Integral Property. Cryptology ePrint Archive, Report 2015/090, 2015. http://eprint.iacr.org/2015/ 090.pdf.
• [60] N. Wang, X. Wang, K. Jia, and J. Zhao. Improved Dierential Attacks on Reduced SIMON Versions. Cryptology ePrint Archive, Report 2014/448, June 2014. http://eprint.iacr.org/eprint-bin/ versions.pl?entry=2014/448.
• [61] N. Wang, X. Wang, K. Jia, and J. Zhao. Dierential Attacks on Reduced SIMON Versions with Dynamic Key-guessing Techniques. Cryptology ePrint Archive, Report 2014/448, February 2015. http:// eprint.iacr.org/2014/448.pdf.
• [62] Q. Wang, Z. Liu, K. Varici, Y. Sasaki, V. Rijmen, and Y. Todo. Cryptanalysis of Reduced-round SI-MON32 and SIMON48. Cryptology ePrint Archive, Report 2014/761, 2014. http://eprint.iacr.org/ 2014/761.pdf.
• [63] L. Wingers. Software for SUPERCOP Benchmarking of SIMON and SPECK. Available at http://github. com/lrwinge/simon\\_speck\\_supercop.
• [64] P. Yalla and J.-P. Kaps. Lightweight Cryptography for FPGAs. In Recongurable Computing and FPGAs, ReConFig '09, pages 225–230, December 2009.
• [65] H. Yap, K. Khoo, A. Poschmann, and M. Henricksen. EPCBC — A Block Cipher Suitable for Electronic Product Code Encryption. In D. Lin, G. Tsudik, and X. Wang, editors, Cryptology and Network Security, CANS 2011, volume 7092 of LNCS, pages 76–97. Springer, 2011.