Triathlon of Lightweight Block Ciphers for the Internet of Things
Daniel Dinu, Yann Le Corre, Dmitry Khovratovich, Léo Perrin, Johann Großschädl,
and Alex Biryukov
SnT and CSC, University of Luxembourg
Maison du Nombre, 6, Avenue de la Fonte, L–4364 Esch-sur-Alzette, Luxembourg
{dumitru-daniel.dinu,yann.lecorre,dmitry.khovratovich,leo.perrin}@uni.lu
{johann.groszschaedl,alex.biryukov}@uni.lu
Abstract. In this paper we introduce a framework for the benchmarking of lightweight block ciphers
on a multitude of embedded platforms. Our framework is able to evaluate the execution time, RAM
footprint, as well as binary code size, and allows one to define a custom “figure of merit” according to
which all evaluated candidates can be ranked. We used the framework to benchmark implementations
of 19 lightweight ciphers, namely AES, Chaskey, Fantomas, HIGHT, LBlock, LEA, LED, Piccolo, PRE-
SENT, PRIDE, PRINCE, RC5, RECTANGLE, RoadRunneR, Robin, Simon, SPARX, Speck, and
TWINE, on three microcontroller platforms: 8-bit AVR, 16-bit MSP430, and 32-bit ARM. Our results
bring some new insights to the question of how well these lightweight ciphers are suited to secure the
Internet of Things (IoT). The benchmarking framework provides cipher designers with an easy-to-use
tool to compare new algorithms with the state-of-the-art and allows standardization organizations to
conduct a fair and consistent evaluation of a large number of candidates.
Keywords: IoT, lightweight cryptography, block ciphers, evaluation framework, benchmarking.
1 Introduction
The Internet of Things (IoT) is a frequently-used term to describe the currently ongoing evolution of the
Internet into a network of smart objects (“things”) with the ability to communicate with each other and to
access centralized resources via the IPv6 (resp. 6LoWPAN) protocol [5]. Today, the two most important and
widely noticed exponents of the IoT are RFID technology (which has become a major enabler of modern
supply-chain management and industrial logistics) and Wireless Sensor Networks (WSNs), which have found
widespread adoption in several application domains ranging from home automation over environmental
surveillance and traffic control to medical monitoring. A recent white paper by Cisco IBSG estimates up to
50 billion devices being connected to the Internet by the year 2020 [28], which implies that, in the not so
distant future, every person in the developed world will be surrounded by dozens of sensors, actuators, RFID
tags, and many other kinds of smart objects yet to be developed. This evolution from the Internet of people
to the Internet of things will have a huge impact on our daily life and change the way we interact with the
physical world surrounding us [5]. However, it is also evident that 50 billion smart devices connected to the
Internet introduce unprecedented challenges to the security and privacy of their owners or users.
It is widely accepted that symmetric-key cryptosystems play a major role in the security arena of the
IoT, but they need to be designed and implemented efficiently enough to not exhaust the scarce resources
of typical IoT devices. Gligor defined in [30] lightweight cryptography as cryptographic primitives, schemes
and protocols tailored to extremely constrained environments such as sensor nodes or RFID tags. A standard
sensor node (e.g. the MICAz mote) is equipped with an 8-bit microcontroller (e.g. the ATmega128) clocked
at 7.8 MHz and features 4 kB of RAM. Passive RFID tags do not even have a (software-programmable)
processor, which means that performing cryptography on such tags is only possible through hardware imple-
mentation. The efficient implementation of cryptographic primitives so that they become applicable in the
constrained regimes of sensor nodes and RFID tags is a challenging task since, for example, performance is
conflicting with other metrics of interest like silicon area and power consumption (in the case of hardware
implementation) or memory consumption and code size (for software). In addition, lightweight primitives
should be able to withstand all known cryptanalytic attacks (e.g. linear and differential cryptanalysis when
thinking of block ciphers) since lightweight cryptography is not meant to be “weak” cryptography in the
sense that a lightweight primitive should not be the weakest link in the security of a system [30].
In this paper we present a survey of lightweight block ciphers along with software benchmarking results
obtained on embedded 8, 16, and 32-bit microcontrollers. We consider three metrics of interest: execution
1
time, memory (i.e. RAM) requirement, and binary code size. To ensure a fair and consistent evaluation, we
developed a benchmarking toolsuite that we make available to the cryptographic research community fol-
lowing the spirit of the well-known and widely-used eBACS system [9]. Our benchmarking tool is “open” in
various aspects; first, it is possible to upload implementations of new ciphers as well as new (i.e. improved)
implementations of ciphers that are already included. Second, the tool was developed from the ground up
with the goal of supporting a wide range of embedded platforms through both cycle-accurate instruction
set simulation and actual measurements on development boards. Currently, our tool includes cycle-accurate
instruction set simulators for AVR ATmega and TI MSP430, as well as an ARM development board equipped
with a Cortex-M3 processor
1
. We use GCC for all these platforms, but other compilers could be supported
as well. Third, our tool is also open with respect to the evaluation metrics. Currently, it can evaluate three
basic metrics, namely execution time, RAM footprint, and binary code size. Other metrics can be derived
thereof or are, at least, closely related. For example, the energy consumption of a block cipher executed on
an embedded processor operating in a certain power mode can be estimated by the product of execution
time, supply voltage, and average power dissipation. However, since our framework supports development
boards, it could be extended to acquire more accurate energy figures by simply measuring the processor’s
power dissipation while it executes a cryptographic algorithm.
Our benchmarking toolsuite accepts source codes written either in “pure” ANSI C or in C with inlined
Assembly sections for the three processor architectures mentioned above. In this way, the toolsuite supports
various trade-offs between performance and portability. At one end of the spectrum are highly-optimized
implementations for which the complete encryption/decryption function consists of hand-crafted Assembly
code. Assembly programming allows one to fully exploit the architectural features of a processor and, in
this way, reach peak performance. The speed-up due to the integration of hand-crafted Assembly code is
especially pronounced if a cipher performs a large number of operations that are significantly less efficient in
C than in Assembly language (e.g. multi-word arithmetic, certain bit manipulations). Benchmarking results
obtained from carefully-optimized Assembler implementations played an important role in the evaluation
of candidates for cryptographic standards like the AES [43] and SHA-3 [45], and this will also be the case
for future standardization activities in the area of lightweight cryptography for the IoT [44]. However, an
implementation of a cipher written in Assembly language is architecture-dependent and, consequently, not
portable. At the other end of the performance-portability spectrum are pure C implementations, which are
highly portable but, in general, less efficient than their hand-crafted Assembly counterparts.
While the importance of benchmarking hand-optimized Assembly implementations is out of dispute, we
argue that it makes also sense to benchmark portable C implementations of lightweight ciphers. Our argu-
ment is twofold and based on the specific properties and constraints of the IoT. First, it has to be noticed
that there is no single dominating hardware platform in the IoT, in contrast to the “conventional” Internet
of commodity computers, where the Intel architecture has a market share of over 90%. In fact, the IoT is
populated by billions of heterogenous devices with largely incompatible processors and different operating
systems. Supporting a large number of platforms with optimized Assembly code is tedious and error-prone
since, for each processor architecture, a separate code base needs to be written, tested, debugged, and then
maintained. In the light of ever-increasing time-to-market pressure, cryptographic engineers may value the
portability of C code more than the performance of Assembly code. Our second argument is related to the
steadily increasing research interest in lightweight ciphers with new designs being published (almost) every
month. Implementations written in C often serve as proof-of-concept in the design phase of a new primitive
to explore e.g. different candidates for a round function. Benchmarks generated from C implementations
allow cipher designers to quickly evaluate the impact of various design options (e.g. round function, number
of rounds) on execution time, RAM footprint and code size. In this way, designers can already assess in an
early phase of the design cycle how a new primitive may compare with the state-of-the-art.
We report detailed benchmarking results for a total of 19 lightweight block ciphers, namely the AES
[43], Chaskey [42], Fantomas [31], HIGHT [35], LBlock [58], LEA [34], LED [32], Piccolo [50], PRESENT
[12], PRIDE [1], PRINCE [13], RC5 [48], RECTANGLE [61], RoadRunneR [6], Robin [31], Simon [7], SPARX
[23], Speck [7], and TWINE [52]. Our rationale for selecting exactly the mentioned 19 ciphers is twofold;
first, each of these candidates has some special property or feature that makes it interesting for applications
in the IoT. Second, they cover a wide range of different design strategies and approaches. Our evaluation
considers two application scenarios or use cases; the first relates to the encryption of messages transmitted
in a Wireless Sensor Network (WSN) and the second is a simple challenge-response authentication protocol
with applications in e.g. object identification or access control. To accommodate the different requirements
1
The main reason for evaluating the execution time for ARM on a development board is that we could not find a
cycle-accurate Cortex-M instruction set simulator of good quality that is freely available.
2
of these application scenarios, we evaluated at least two versions of most of the 19 ciphers, including a low-
memory variant and a speed-optimized variant. The former can be seen as a “minimalist” implementation
that favors low memory footprint and small code size over performance. On the other hand, the second
implementation includes certain optimizations that increase code size and/or memory footprint (e.g. partial
loop unrolling, use of small lookup tables) with the goal of improving performance. Roughly half of the
implementations were written from scratch by us, whereby we put a comparable effort into optimizing each
cipher to ensure a consistent and fair evaluation. The other half was either taken from other open-source
projects or contributed by the designers of the algorithms or by volunteers; in all these cases we carefully
reviewed the source codes and further optimized them whenever possible. In this way, we tried to minimize
the impact of varying programming skills and/or experience. Most of our implementations are faster or on
par with the best execution times reported in the literature on the platforms we consider. Therefore, these
implementations form a solid code base for the benchmarking of lightweight block ciphers.
Related Work. There exist a number of related research projects that evaluate software implementations
of lightweight block ciphers, but none of them analyzed execution time, RAM footprint, and code size on
different 8, 16, and 32-bit platforms. We studied previous benchmarking initiatives in detail, but in the end
we decided to develop a new benchmarking framework from scratch instead of contributing to an existing
one since each of the existing frameworks has a certain issue or limitation that would have been difficult
to fix. Nevertheless, understanding the strengths and weaknesses of other benchmarking initiatives helped
us to design a flexible and powerful framework capable of collecting accurate and detailed results about the
execution time, RAM consumption and code size of lightweight ciphers.
In the course of the BLOC project [17], a total of 16 lightweight block ciphers were evaluated on an
MSP430 microcontroller. The provided C library [16] shows that the project does not insist on a common
interface for all ciphers and there seems to be no way to easily integrate new platforms. By inspecting the
benchmarking code we discovered a bug in the calculation of the RAM requirements because the authors
assumed that a variable of type unsigned int has a size of one byte instead of two. Furthermore, some
implementations did not verify the test vectors provided in the cipher specification
2
. For the block ciphers
considered both in our paper and in [17], our results on MSP430 are, on average, three times better.
During the ECRYPT II project, a survey paper [25] with the results of a performance evaluation of 12
low-cost block ciphers on an 8-bit AVR ATtiny45 device was published. Among the analyzed ciphers are
only designs that were introduced before 2012, i.e. more recent ciphers, such as Simon and Speck [7], are
not included. The authors describe their evaluation methodology and the implementation guidelines they
followed to ensure a fair comparison of the 12 lightweight ciphers. Although the Assembly source codes are
available [27], there is no framework provided that can help users to asses the performance of new designs
under the same conditions. The Assembly implementation results of this survey on AVR ATtiny45 are on
par with our Assembly implementation results on AVR ATmega128.
The XBX extension [57] to SUPERCOP [9] allows one to benchmark hash functions on embedded devices
and adds two new metrics, namely RAM footprint and ROM consumption. Unfortunately, the framework is
currently not maintained any more, but still worth mentioning because of the consistent evaluation across
several platforms and the importance of the benchmarking results for the SHA-3 competition [45].
Our Contributions. First, we designed and implemented a framework for fair and consistent benchmark-
ing of lightweight cryptographic primitives on 8, 16, and 32-bit processors. Our work is motivated by the
lack of a well-accepted and widely-used tool that allows the cryptographic research community to analyze
and compare the execution time, RAM requirements and code size of lightweight primitives on a range
of embedded platforms. These three metrics can be extracted at a very detailed level for different operations
(e.g. encryption, decryption, key expansion) through a well-defined API. We make the entire source code
of our framework available under GPL version 3 to facilitate the establishment of a completely free and
open benchmarking environment for lightweight cryptosystems. The source code can be downloaded from
the CryptoLUX wiki [19].
Second, we survey 19 lightweight block ciphers and analyze, in particular, their suitability for software
implementation on resource-restricted devices. This set of ciphers covers a wide range of different design
principles and includes a number of recent proposals with highly interesting properties, e.g. Simon/Speck
[7], Robin/Fantomas [31], and SPARX [23]. We collected between two and up to 24 implementations of each
cipher to account for different trade-offs between execution time, RAM footprint, and code size. For nine
2
The maintainers of the BLOC project merged our pull request on GitHub that fixed the mentioned issues, see
http://github.com/kmarquet/bloc/pull/2.
3
out of the 19 ciphers we have not only C implementations, but also optimized Assembly code for the three
platforms we consider. In total, our repository includes over 250 implementations, of which we developed
roughly half from scratch and the rest we took over (and slightly modified) from other open-source projects
or they were contributed by the cipher designers. The source code of all our implementations is available
under GPL and can be downloaded from the CryptoLUX wiki
3
.
Third, we present detailed timing, RAM consumption, and code size figures of all 19 ciphers, which we
generated with the help of our benchmarking toolsuite. Furthermore, we define two typical usage scenarios
that aim to resemble security-related operations commonly carried out by “real” IoT devices. The results
we obtained shed some new light on the relative efficiency of lightweight block ciphers because (i) several
of our implementations are much faster or smaller than that of other survey and benchmarking efforts, and
(ii) we include a few designs that have been published only very recently. Since lightweight cryptography is
a rapidly progressing area of research, we also maintain a web page [19] with the latest results, which gets
automatically updated when users provide new implementations. Our framework allows the user to define
a custom “Figure Of Merit” (FOM) according to which an overall ranking of a set of block ciphers can be
assembled. The FOM metric can use different weight factors for execution time, RAM footprint, and code
size, and may even consider (cryptanalytic) security aspects.
To the best of our knowledge, this paper is the first to analyze a broad range of lightweight block ciphers
on different processors in a comprehensive and consistent fashion, taking into account the specific constraints
and requirements of the IoT. Our results allow one to infer some interesting relations between cipher design
principles and performance figures, and, in this way, contribute to a better understanding of how to design
and implement lightweight block ciphers.
2 Benchmarking Framework
Most papers introducing a new block cipher report some kind of results of some kind of performance eval-
uation on some kind of platform using some kind of implementation. These results are then used by the
authors to claim that the proposed cipher has some kind of “advantage” over existing ciphers or compares
“favorably” with the state of the art. However, the practical relevance of such comparisons is questionable
since it is not easily possible to take differences in the characteristics of the target platforms or differences
in the simulation/measurement conditions into account. Consequently, it is difficult to assess the relative
efficiency of the numerous proposals for lightweight ciphers in a fair and consistent fashion. This motivated
us to develop a benchmarking toolsuite that allows for a unified evaluation of a large number of candidates
by collecting accurate and comprehensive results for execution time, RAM footprint, and code size. The
toolsuite is currently able to extract these metrics from implementations for 8-bit AVR, 16-bit MSP430, and
32-bit ARM Cortex-M processors, but other platforms could be supported as well. We make the full source
code of the benchmarking framework available under GPL to facilitate its acceptance in the cryptographic
research community and to maximize transparency in the evaluation of lightweight block ciphers.
We developed our framework with the goal of being easy to use, but we also aimed for high flexibility in
order to support various optimization strategies for lightweight ciphers. Therefore, the benchmarking frame-
work accepts implementations written in C, which can optionally contain inlined Assembly segments to
speed up performance-critical operations. New ciphers typically come with a reference implementation in C
that can be easily cross-compiled for the three platforms mentioned above. This allows cipher designers to
quickly assess the performance of a new block cipher on different 8, 16, and 32-bit processors. Currently, the
GNU Compiler Collection (GCC) is used for all three platforms, but our toolsuite could be easily extended
with other compilers. The benchmarking framework applies different combinations of compiler switches to
optimize the code generation and achieve best possible results. To ensure a fair and consistent evaluation
of ciphers, each implementation has to adhere to a pre-defined Application Program Interface (API) and
follow a set of guidelines to meet certain constraints. A detailed description of the framework requirements
can be found in Appendix B.
As stated in the previous section, we consider benchmarking results obtained with C implementations
to be useful for cipher designers and for cryptographic engineers who prefer portable C code over platform-
optimized Assembly code. Since cipher designers tend to write reference implementations in ANSI C, the
effort of evaluating a new cipher boils down to adapting the C source code to meet the requirements of the
framework. However, benchmarks generated with C implementations do often not reflect the full potential
of a lightweight cipher because ANSI C can not efficiently express multi-word arithmetic operations and
3
All results reported in this paper are based on version 1.1.20 of the FELICS framework, which can be downloaded
from http://www.cryptolux.org/index.php/File:FELICS.zip
4
certain bit manipulations. In addition, the quality of the C compiler (i.e. its ability to apply sophisticated
optimizations) may impact the relative performance of lightweight ciphers. To mitigate these issues, and to
serve cryptographic engineers who are primarily interested in high speed rather than high portability, the
toolsuite supports the benchmarking of hand-optimized Assembly implementations for the three considered
platforms. We had both C and Assembly implementations available for nine of the 19 lightweight ciphers
we benchmarked; the remaining ten ciphers were evaluated using C source codes only. In total, we analyzed
more than 250 different C and Assembly implementations of 19 lightweight block ciphers. We make the full
source code of all implementations available under GPL to ensure the reproducibility of our results and, in
this way, increase the transparency and trustability of our evaluation process.
2.1 Evaluation Metrics
The benchmarking framework is able to extract three primary metrics, namely execution time, run-time
memory (i.e. RAM) consumption, and code size. We consider these metrics as “primary” because (i) they
determine to a large extent how well a block cipher meets the constraints and requirements of the IoT, and
(ii) they can not be derived from other metrics. Since reaching high performance is the main design goal
of essentially any software-oriented cipher, it is clear that a benchmarking framework needs to be capable
to evaluate the execution time in a comprehensive and precise fashion. In addition, other metrics, such as
the energy consumption of a cipher, have a strong correlation with the execution time
4
. While most existing
papers that present implementation results for a lightweight block cipher only report execution times, we
consider it important to take also RAM footprint and code size into account. Many IoT devices are so
constrained that they feature only a few hundred bytes of RAM and a few kB of flash memory, which means
RAM footprint and code size are crucial criterions for cryptographic engineers when selecting a lightweight
cipher. In addition, since it is not possible to optimize all three metrics simultaneously, one has to find a
trade-off. For example, common approaches to reduce the execution time, such as loop unrolling or the use
of a lookup table to speed up the round function, generally increase the code size or RAM consumption
or both. Our benchmarking framework allows a cryptographic engineer to analyze such trade-offs and, in
this way, determine the best optimization strategy for the requirements of the target application and the
constraints of the target device. The execution time, RAM footprint, and code size of an implementation
can be combined into a single number by defining a Figure-of-Merit (FOM), which makes it possible to rank
different implementations. We describe in Subsection 4.1 a FOM that is basically a weighted sum of the
three metrics across the three platforms we support.
Execution Time. The execution time is quantified through the number of clock cycles required for the
execution of each of the four basic operations of a block cipher, namely encryption, decryption, encryption
key schedule, and decryption key schedule (see Appendix B). As mentioned earlier, our framework supports
instruction-set simulators as well as the acquisition of real measurements from development boards. Con-
cretely, the cycle-accurate simulators Avrora [55,54] and MSPDebug [8] are used to evaluate the execution
times for the 8-bit AVR and 16-bit MSP430 platform, respectively. On the other hand, the cycle counts on
the ARM Cortex-M3 are determined with help of the system timer by reading the SysTick Current Value
Register (SYST_CVR). This register gets decremented with each processor clock and allows for very precise
measurement of elapsed cycle counts. The framework automatically inserts C code for reading the system
timer immediately before and immediately after the operation to be measured and calculates the execution
time as the difference of the two timer values. However, the obtained execution time may vary by a few
cycles depending on how the compiler translates the C code for reading the timer into Assembly instructions
in different contexts and how the data types are aligned in memory. Therefore, it is possible to get slightly
varying execution times for one and the same operation in different usage scenarios. We collected the timings
for ARM reported in Section 4 using an Arduino Due board [2] with a Cortex-M3 [3] processor.
RAM Footprint. The RAM footprint is determined by the size of the data section (which contains all
static variables that are initialized to a non-zero value) and the maximum stack consumption. There is no
need to take the bss section into account since the two usage scenarios we developed for the benchmarking
of lightweight ciphers (described further below) operate without uninitialized static data. In addition, the
heap is not used at all because the framework does not permit any dynamically-allocated variables. The
4
One can get a rough estimate of the energy consumption by simply forming the product of execution time, average
power consumption of the target processor, and supply voltage. More accurate energy figures could be obtained
by extending the framework to support power measurements on microprocessor development boards.
5
