22
A. Mileva et al.
tography Lounge, 1 [89, 260, 391]). Most recent cryptographic competitions such
as NIST’s SHA-3 Cryptographic Hash Algorithm Competition 2 and eSTREAM
project 3 (with the Profile 2) had requirements that support implementations for
highly constrained devices. Additionally, NIST currently is working on a special
call 4 to create a portfolio of lightweight algorithms through an open standardization
process.
The lightweightness of a given cryptographic algorithm can be obtained in
two ways, by optimized implementations with respect to different constraints or
by dedicated designs which use smaller key sizes, smaller internal states, smaller
building blocks, simpler rounds, simpler key schedules, etc. There are several
relevant metrics for assessing lightweight algorithms, such as power and energy
consumption, latency, throughput and resource requirements [404]. Power and
energy consumption are important for devices that are battery-oriented or energy
harvesting. Latency is the time taken to perform a given task, and is important
for applications where fast response time is necessary (e.g., Advanced Driver
Assistance Systems), while throughput can be defined as the rate at which the
plaintext is processed per time unit, and is measured in Bps.
Resource requirements are expressed differently in hardware and software
implementations. In the hardware case, they are described as gate area, expressed by
logic blocks for FPGAs or by Gate Equivalents (GEs) for ASIC implementations.
However, these measures highly depend on the particular technology, so it is not
possible to do a fair and relevant comparison of the lightweight algorithm implementations exactly across different technologies. In the software case, resource
requirements are described as number of registers, RAM and ROM consumption
in bytes. ROM consumption corresponds in fact with the code size.
Hardware implementations are suitable for highly constrained devices. For
example, on the low end, low-cost passive RFID tags may have a total of 1000–
10,000 gates, with only 200–2000 budgeted for security purposes [309]. Software
implementations are suitable for less constrained devices, and they are optimized
for throughput and energy consumption.
Some design choices related to dedicated lightweight cryptographic algorithms
have influences on the security margins. For example, smaller key sizes such as 80
bits or 96 bits are in conflict with the current NIST minimum key size requirement
of 112 bits. Smaller block and output sizes in some algorithms may lead to plaintext
recovery or codebook attacks. Simpler key schedules may enable different attacks
using related keys, weak keys, etc. Smaller internal state (IS) and digest sizes in
hash functions may lead to collision attacks. Simpler rounds sometimes means that
more iterations are required to achieve security.
1 https://cryptolux.org/index.php/Lightweight_Cryptography.
2 Part 2.B.2, Federal Register Notice (2 November 2007).
3 http://www.ecrypt.eu.org/stream/call/.
4 https://csrc.nist.gov/CSRC/media/Projects/Lightweight-Cryptography/documents/Draft-LWCSubmission-Requirements-April2018.pdf.
A. Mileva et al.
tography Lounge, 1 [89, 260, 391]). Most recent cryptographic competitions such
as NIST’s SHA-3 Cryptographic Hash Algorithm Competition 2 and eSTREAM
project 3 (with the Profile 2) had requirements that support implementations for
highly constrained devices. Additionally, NIST currently is working on a special
call 4 to create a portfolio of lightweight algorithms through an open standardization
process.
The lightweightness of a given cryptographic algorithm can be obtained in
two ways, by optimized implementations with respect to different constraints or
by dedicated designs which use smaller key sizes, smaller internal states, smaller
building blocks, simpler rounds, simpler key schedules, etc. There are several
relevant metrics for assessing lightweight algorithms, such as power and energy
consumption, latency, throughput and resource requirements [404]. Power and
energy consumption are important for devices that are battery-oriented or energy
harvesting. Latency is the time taken to perform a given task, and is important
for applications where fast response time is necessary (e.g., Advanced Driver
Assistance Systems), while throughput can be defined as the rate at which the
plaintext is processed per time unit, and is measured in Bps.
Resource requirements are expressed differently in hardware and software
implementations. In the hardware case, they are described as gate area, expressed by
logic blocks for FPGAs or by Gate Equivalents (GEs) for ASIC implementations.
However, these measures highly depend on the particular technology, so it is not
possible to do a fair and relevant comparison of the lightweight algorithm implementations exactly across different technologies. In the software case, resource
requirements are described as number of registers, RAM and ROM consumption
in bytes. ROM consumption corresponds in fact with the code size.
Hardware implementations are suitable for highly constrained devices. For
example, on the low end, low-cost passive RFID tags may have a total of 1000–
10,000 gates, with only 200–2000 budgeted for security purposes [309]. Software
implementations are suitable for less constrained devices, and they are optimized
for throughput and energy consumption.
Some design choices related to dedicated lightweight cryptographic algorithms
have influences on the security margins. For example, smaller key sizes such as 80
bits or 96 bits are in conflict with the current NIST minimum key size requirement
of 112 bits. Smaller block and output sizes in some algorithms may lead to plaintext
recovery or codebook attacks. Simpler key schedules may enable different attacks
using related keys, weak keys, etc. Smaller internal state (IS) and digest sizes in
hash functions may lead to collision attacks. Simpler rounds sometimes means that
more iterations are required to achieve security.
1 https://cryptolux.org/index.php/Lightweight_Cryptography.
2 Part 2.B.2, Federal Register Notice (2 November 2007).
3 http://www.ecrypt.eu.org/stream/call/.
4 https://csrc.nist.gov/CSRC/media/Projects/Lightweight-Cryptography/documents/Draft-LWCSubmission-Requirements-April2018.pdf.