Abstract
The last several years have witnessed a surge of activity in lightweight cryptographic design. Many lightweight block ciphers have been proposed, targeted mostly at hardware applications. Typically software performance has not been a priority, and consequently software performance for many of these algorithms is unexceptional. Simon and Speck are lightweight block cipher families developed by the U.S. National Security Agency for high performance in constrained hardware and software environments. In this paper, we discuss software performance and demonstrate how to achieve high performance implementations of Simon and Speck on the AVR family of 8-bit microcontrollers. Both ciphers compare favorably to other lightweight block ciphers on this platform. Indeed, Speck seems to have better overall performance than any existing block cipher — lightweight or not.
The rights of this work are transferred to the extent transferable according to title 17 § 105 U.S.C.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Similar content being viewed by others
Notes
- 1.
Simon 64/96 and Speck 64/96, for example, have implementations requiring just 809 and 860 gate equivalents, respectively. Some block ciphers, like KTANTAN [9], have a fixed key and so do not require flip-flops to store it. Such algorithms can have smaller hardware implementations than Simon or Speck, but not allowing keys to change contracts the application space, and can lead to security issues [22].
- 2.
This is because one is likely to use encrypt-only modes in lightweight cryptography. But the techniques discussed here should serve as a starting point for other kinds of implementations, useful for a broad range of applications. Regarding decryption functionality, we note that the Simon and Speck encryption and decryption algorithms consume similar resources and are easy to implement. Simon, in particular, has a decryption algorithm that is closely related to the encryption algorithm, and so little additional code is necessary to enable decryption.
- 3.
The Simon and Speck specification paper [2] did not count these cycles required for loading, although it seems proper to do so. The current performance numbers include these costs.
- 4.
This rotation is also easily implemented (but not for free) on some common 16-bit microcontrollers, like the MSP430, and using x86 SSE instructions (where no rotate is available but a byte permutation operation is).
- 5.
We do not know, for a fact, that the high-speed AES implementations, which require frequent calls to RAM, are more energy efficient than the high-speed Speck implementations which use mostly register-to-register operations.
- 6.
No data for the other finalist, Rabbit [5], was available.
- 7.
The rank is similar to the metric found in [21] except we have imposed a penalty for using too much RAM — hence the factor of 2. Without the factor of 2, flash and RAM have the same cost, which seems unjustifiable.
- 8.
The HC-128 stream cipher implementation does not actually fit on the ATmega128 due to its excessive use of RAM. The C implementation of HC-128 described in [17] has a setup cost of over 2,000,000 cycles.
References
Atmel Corporation. 8-bit AVR Instruction Set, Rev. 0856I-AVR-07/10. http://www.atmel.com/images/doc0856.pdf
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/
Berbain, C., Billet, O., Canteaut, A., Courtois, N., Gilbert, H., Goubin, L., Gouget, A., Granboulan, L., Lauradoux, C., Minier, M., Pornin, T., Sibert, H. SOSEMANUK, a fast software-oriented stream cipher. In: CoRR, abs/0810.1858 (2008)
Bernstein, D.: The Salsa20 family of stream ciphers. In: Robshaw, M., Billet, O. (eds.) New Stream Cipher Designs. LNCS, vol. 4986, pp. 84–97. Springer, Heidelberg (2008)
Boesgaard, M., Vesterager, M., Pedersen, T., Christiansen, J., Scavenius, O.: Rabbit: a new high-performance stream cipher. In: Johansson, T. (ed.) Fast Software Encryption, vol. 2887, pp. 307–329. Springer, Heidelberg (2003)
Bogdanov, A., Knudsen, L.R., Leander, G., Paar, C., Poschmann, A., Robshaw, M.J.B., 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)
Borghoff, J., Canteaut, A., Güneysu, T., Kavun, E.B., Knežević, M., Knudsen, L.R., Leander, G., Nikov, V., Parr, C., Rechberger, C., Rombouts, P., Thomsen, S.S., Yalçın, T.: PRINCE – a low-latency block cipher for pervasive computing applications. In: Wang, X., Sako, K. (eds.) ASIACRYPT 2012. LNCS, vol. 7658, pp. 208–225. Springer, Heidelberg (2012)
Bos, J., Osvik, D., Stefan, D.: Fast Implementations of AES on Various Platforms. Cryptology ePrint Archive, Report 2009/501 (2009). http://eprint.iacr.org/
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)
Eisenbarth, T., Gong, Z., Güneysu, T., Heyse, S., Indesteege, S., Kerckhof, S., Koeune, F., Nad, T., Plos, T., Regazzoni, F., Standaert, F., van Oldeneel tot Oldenzeel, L.: Compact implementation and performance evaluation of block ciphers in attiny devices. In: Mitrokotsa, A., Vaudenay, S. (eds.) AFRICACRYPT 2012. LNCS, vol. 7374, pp. 172–187. Springer, Heidelberg (2012)
Eisenbarth, T., Kumar, S., Paar, C., Poschmann, A., Uhsadel, L.: A survey of lightweight cryptography implementations. IEEE Des. Test Comput. 24(6), 522–533 (2007)
Gong, Z., Nikova, S., Law, Y.W.: KLEIN: a new family of lightweight block ciphers. In: Juels, A., Paar, C. (eds.) RFID. Security and Privacy. LNCS, vol. 7055, pp. 1–18. Springer, Heidelberg (2011)
Guo, J., Peyrin, T., Poschmann, A., Robshaw, M.: The LED block cipher. In: Preneel, B., Takagi, T. (eds.) CHES 2011. LNCS, vol. 6917. Springer, Heidelberg (2011)
Hong, D., Sung, J., Hong, S., Lim, J., Lee, S., Koo, B., Lee, C., Chang, D., Lee, J., Jeong, K., Kim, H., Kim, J., Chee, S.: HIGHT: A new block cipher suitable for low-resource device. In: Goubin, L., Matsui, M. (eds.) CHES 2006. LNCS, vol. 4249, pp. 45–59. Springer, Heidelberg (2006)
Hutter, M., Schwabe, P.: NaCl on 8-bit AVR microcontrollers. In: Youssef, A., Nitaj, A., Hassanien, A.E. (eds.) AFRICACRYPT 2013. LNCS, vol. 7918, pp. 156–172. Springer, Heidelberg (2013)
Karakoç, F., Demirci, H., Emre Harmancı, A.: ITUBEE: a software oriented lightweight block cipher. In: Avoine, G., Kara, O. (eds.) Lightweight Cryptography for Security and Privacy. LNCS, vol. 8162, pp. 16–27. Springer, Heidelberg (2013)
Meiser, G.: Efficient implementation of stream ciphers on embedded processors. Masters Thesis, Ruhr-University Bochum (2007)
Rinne, S., Eisenbarth, T., Paar, C.: Performance analysis of contemporary lightweight block ciphers on 8-bit microcontrollers. In: SPEED - Software Performance Enhancement for Encryption and Decryption (2007)
Shibutani, K., Isobe, T., Hiwatari, H., Mitsuda, A., Akishita, T., Shirai, T.: Piccolo: an ultra-lightweight blockcipher. In: Preneel, B., Takagi, T. (eds.) CHES 2011. LNCS, vol. 6917, pp. 342–357. Springer, Heidelberg (2011)
Shirai, T., Shibutani, K., Akishita, T., Moriai, S., Iwata, T.: The 128-bit blockcipher CLEFIA (extended abstract). In: Biryukov, A. (ed.) Fast Software Encryption. LNCS, vol. 4593, pp. 181–195. Springer, Heidelberg (2007)
Suzaki, T., Minematsu, K., Morioka, S., Kobayashi, E.: TWINE: a lightweight, versatile block cipher. www.nec.co.jp/rd/media/code/research/images/twine_LC11.pdf
Wei, L., Rechberger, C., Guo, J., Wu, H., Wang, H., Ling, S.: Improved meet-in-the-middle cryptanalysis of KTANTAN. Inf. Secur. Priv. ACISP 2011, 433–438 (2011)
Wheeler, D., Needham, R.: TEA, a tiny encryption algorithm. In: Preneel, B. (ed.) Fast Software Encryption. LNCS, vol. 1008, pp. 363–366. Springer, Heidelberg (1995)
Wu, H.: The stream cipher HC-128. www.ecrypt.eu.org/stream/p3ciphers/hc/hc128_p3.pdf
Wu, W., Zhang, L.: LBlock: a lightweight block cipher. In: Lopez, J., Tsudik, G. (eds.) Applied Cryptography and Network Security. LNCS, vol. 6715, pp. 327–327. Springer, Heidelberg (2011)
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Appendices
A Simon and Speck AVR Performance
In this section we present the results of our three AVR implementations of Simon (Table 8) and Speck (Table 7). The headings of each column indicate the block size/key size in bits. The first three rows of data correspond to the low flash implementation, the next three rows to the low RAM implementation and the last three rows are for the low cost (i.e., high-speed/low-energy) implementation. RAM and flash are measured in bytes and cost is measured in cycles/byte. For none of the algorithms is any sort of functionality for the decryption operator included, although for Simon decryption is essentially the same as encryption, and Speck decryption uses about the same amount of resources as Speck encryption.
B Comparison Data and Methodology
Fair comparisons adhere to a common framework. The framework provides three important pieces of information. First, it provides a high-level, device-independent description of what the cipher is expected to do. At a lower level, device-dependent implementation details are provided. Finally, a performance metric is chosen to make the comparisons meaningful. Needless to say, any ranking depends on the framework used, especially the performance metric. The following application types are especially relevant to lightweight cryptography.
-
Fixed Key/Small Data. Fixed key applications assume the key will never (or rarely) be changed. In hardware, area requirements can be reduced (depending on the design and the implementation) because state for a key schedule may not be required. In software, the key, or better yet the expanded key, can be stored in long-term memory and the key schedule can be relinquished. For small data size comparisons, we may assume we are encrypting just a single block and so incur the full cost of any setup. This application type may be appropriate for simple authentication applications.
-
Fixed Key/Large Data. This is the same as the previous type except that the data stream is assumed to be large. For comparison purposes, we may assume the amount of encrypted data approaches infinity, amortizing away the setup costs. This may be appropriate for various sensor applications.
-
Flexible Key/Small Data. Here, we assume the key is changed often. In hardware or software, this necessitates the inclusion of the key schedule. For comparison purposes, we may assume that we are encrypting a single block of data with a never-before-seen key. This type of application may be appropriate when the block cipher is contained in a general purpose crypto module and the key enters the device from outside of the module.
-
Flexible Key/Large Data. Similar to the preceeding except the data stream is large. For comparison purposes, we may again assume the data stream is (effectively) infinite, amortizing away all setup costs.
It is generally recognized in lightweight cryptography that use of the decryption operator should be avoided, if possible, in order to conserve resources. If resources are not a big concern, one should use AES. For software applications on a microcontroller, implementations should be assembly coded in order to reduce compiler vagaries and to provide for maximal performance (i.e., to reduce code size and memory usage and to increase throughput).
For our comparisons, shown in Table 9, we (mostly) used the Fixed Key/Small Data framework. For our implementations, expanded key is stored in flash and only encryption functionality is provided. Key schedules are also absent. The encryption procedure begins by loading the plaintext from RAM into registers. The plaintext is then transformed into the ciphertext using the encryption operator. The resulting ciphertext is then loaded in RAM. This completes the encryption process. RAM for holding the plaintext and ciphertext is not costed but RAM used for temporary storage (e.g., on the stack) is. Our low-RAM implementations of Simon and Speck were appropriate for this comparison. For the other ciphers, implementations fitting the framework were based on the best existing code (or performance data) we could find which maximized the overall performance metric, rank, which is defined to be
higher values of rank correspond to better performance.Footnote 7 In some cases, this just amounted to stripping out the code for the decryption and key schedule algorithms in existing implementations. In other cases, we wrote the code ourselves.
Note that our performance metric is an overall measure of performance and takes into account flash, RAM and throughput. However, depending on priorities, this metric may be irrelevant. If the main concern is energy efficiency, then a more appropriate metric is just throughput and a fair comparison will require implementations optimized for this purpose, resulting in altered rankings. We have already alluded to this in our discussion in Sect. 6.
Referring to Table 9, all implementations, except for HC-128, were assembly coded. Size is block size/key size for block ciphers and state size/key size for stream ciphers. The cost is the number of cycles per byte to transform a block of plaintext into a block of ciphertext.
The ITUbee data is taken directly from its specification paper [16]. Data for SEA, IDEA and Klein are taken from [10, 11, 18], respectively. In some cases, code size estimates had to be made to fit our framework. The TEA and Hight implementations are our own. For AES, our numbers were kindly provided by Dag Arne Osvik, one of the authors of [8], who made suitable code modifications to fit our framework. The Twine data, fitting our framework, was provided by two of the Twine designers, Kazuhiko Minematsu and Tomoyasu Suzaki. Our numbers for Salsa 20/12 were obtained by scaling down the cost of the Salsa 20/20 implementation provided in [15]. Data for Sosemanuk and HC-128 was obtained from [17]. We did not include the considerable setup time for HC-128 and the moderate setup time for Sosemanuk, and of course this setup time should be considered in the Fixed Key/Small Data framework.Footnote 8
Rights and permissions
Copyright information
© 2015 Springer International Publishing Switzerland 2015 (outside the US)
About this paper
Cite this paper
Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S., Weeks, B., Wingers, L. (2015). The Simon and Speck Block Ciphers on AVR 8-Bit Microcontrollers. In: Eisenbarth, T., Öztürk, E. (eds) Lightweight Cryptography for Security and Privacy. LightSec 2014. Lecture Notes in Computer Science(), vol 8898. Springer, Cham. https://doi.org/10.1007/978-3-319-16363-5_1
Download citation
DOI: https://doi.org/10.1007/978-3-319-16363-5_1
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-319-16362-8
Online ISBN: 978-3-319-16363-5
eBook Packages: Computer ScienceComputer Science (R0)