After AES, NIST is Defining the Next Great Standard for Encryption … Light-weight Crypto

NIST have created a number of competitions around the standardization of cryptography. This included select Rindael for the AES standard…
Photo by Harrison Broadbent on Unsplash

After AES, NIST is Defining the Next Great Standard for Encryption … Light-weight Crypto

NIST has created a number of competitions around the standardization of cryptography. This included select Rindael for the AES standard and Keccak for the SHA-3 method. Currently, they have reached the final stage for two important standards: post-quantum cryptography; and light-weight cryptography. The finalists for light-weight cryptography are [here]:

  • ASCON. ASCON implements a hashing method for a 256-bit hash, and uses a 320-bit permutation. It was created by Christoph Dobraunig Maria Eichlseder Florian Mendel and Martin Schläffer [link]. ASCON can also be used to create authenticated encryption [link].
  • Elephant. In Cybersecurity, Where Would You Find Dumbo, Jumbo and a Pink Elephant?[link].
  • GIFT-COFB. GIFT: A Small Present for Cybersecurity and IoT: here.
  • Grain128-AEAD. Grain is a Light Weight Stream Cipher and was written by Martin Hell, Thomas Johansson and Willi Meier. It has a relatively low gate count, power consumption and memory. It has an 80-bit key, and has two shift registers and a nonlinear output function [paper][link].
  • ISAP. Isap is a light weight block cipher and was written by Christoph Dobraunig, Maria Eichlseder, Stefan Mangard, Florian Mendel, Bart Mennink, Robert Primas and Thomas Unterluggauer. It is focused on robustness against power analysis and fault attacks and where there is a node for small codesize. Overall it uses a sponge-based mode with SPN permutations. Isap has mechanisms to protec gain fault attacks. Isap uses an Encrypt-then-MAC design with two keys for IsapMac and IsapEnc. This page outlines the ASCON version: [link].
  • Photon-Beetle. PHOTON-BEETLE uses a sponge authenticated encryption and sponge hash, and has a 256-bit permutation. It uses PHOTON256 at its core [link].
  • Romulus. Duel of the Cybersecurity Titans for Lightweight Crypto: Meet Romulus: [link].
  • Sparkle. Esch256 (Efficient, Sponge-based, and Cheap Hashing) is from the Sparkle permutation family. This page implements the hashing method for a 256-bit hash, and has a block size of 16 bytes, a security level of 128 bits and a data limit up to 2132. It was designed by Christof Beierle, Alex Biryukov, Luan Cardoso dos Santos, Johann Großschädl, Léo Perrin, Aleksei Udovenko, Vesselin Velichkov, and Qingju Wang. More [details][link][link].
  • TinyJambu.
  • Xoodyak. KangarooTwelve is part of Xoodyak submission to NIST. NIST created a competition for SHA-3, and it was Keccak that was crowned the champion. Since then, SHA-3 has received good adoption levels, but you’ll also see BLAKE2 — one of the finalists — being used in many applications. Keccak won because it was fast, and where BLAKE2 was submitted too late to compete against it. Since many have seen BLAKE2 as the better alternative [article]. So, in 2016, the Keccak research team came up with a new method: KangarooTwelve. For this they managed to get significant speed improvements and managed to reduce the number of rounds from 24 to 12 (and with a security level of around 128 bits). A new method of tree hashing has also been added, and which supports the parallel hashing of large files [article][link].

The deadline for updates is 17 May, and the key metrics for the evaluation are side channel and fault attack resistance, cost, performance, third-party analysis, and suitability for hardware and software.

Conventional and light-weight cryptography

While AES and SHA work well together within computer systems, they struggle in an IoT/embedded world as they take up: too much processing power; too much physical space; and consume too much battery power. So NIST outlines a number of methods that can be used for lightweight cryptography, and which could be useful in IoT and RFID devices [1]. They define the device spectrum as:

  • Conventional cryptography. Servers and Desktops. Tablets and smart phones.
  • Light-weight cryptography. Embedded Systems. RFID and Sensor Networks.

Embedded systems

With embedded systems, we commonly see 8-bit, 16-bit and 32-bit microcontrollers, and which would struggle to cope with real-time demands for conventional cryptography methods. And in the 40+ years since the first 4-bit processor, there is even a strong market for 4-bit processors. RFID and sensor network devices, especially, have limited numbers of gates available for security, and are often highly constrained with the power drain on the device.

So AES is typically a non-starter for many embedded devices. In light-weight cryptography, we often see smaller block size (typically 64 bits or 80 bits), smaller keys (often less than 90 bits) and less complex rounds (and where the S-boxes often just have 4-bits).

The constraints of IoT

For light-weight cryptography, the main constraints that we have are typically related to power requirements, gate equivalents (GEs), and timing. With passive RFID devices, we do not have an associated battery for the power supply, and where the chip must power itself from energy coupled from the radio wave. An RFID device is thus likely to be severely constrained in the power drain associated with any cryptography functions, along with being constrained for the timing requirements and for the number of gates used. Even if an RFID device has an associated battery (active RFID), it may be difficult to recharge the battery, so the drain on power must often be minimised.

There is thus often a compromise between the cryptography method used and the overall security of the method. Thus often lightweight cryptography methods balance performance (throughput) against power drain and GE, and do not perform as well as mainstream cryptography standards (such as AES and SHA-256). Along with this, the method must also have a low requirement for RAM (where the method requires the usage of running memory to perform its operation) and ROM (where the method is stored on the device). In order to assess the strengths of various methods we often define the area that the cryptography function will use on the device — and which is defined in µm².

Within cryptography, we use symmetric key encryption, and which is either a block cipher or a stream cipher. Generally, stream ciphers are faster and have a smaller overhead on providing memory buffers.

For light-weight cryptography PHOTON [2], SPONGENT [3] and Lesamanta-LW [4] are defined as standards for hashing methods within ISO/IEC 29192–5:2016, PRESENT and CLEFIA for block methods within ISO/IEC 29192–2:2012, and Enocoro and Trivium for stream methods within ISO/IEC 29192–3:2012.

References

[1]	K. A. McKay, L. Bassham, M. S. Turan, and N. Mouha, “Report on lightweight cryptography,” 2017.
[2]	J. Guo, T. Peyrin, and A. Poschmann, “The PHOTON Lightweight Hash Functions Family,” Crypto, pp. 222–239, 2000.
[3]	A. Bogdanov, M. Knežević, G. Leander, D. Toz, K. Varici, and I. Verbauwhede, “{SPONGENT}: The Design Space of Lightweight Cryptographic Hashing,” 2011.
[4]	S. Hirose, K. Ideguchi, H. Kuwakado, T. Owada, B. Preneel, and H. Yoshida, “A Lightweight 256-Bit Hash Function for Hardware and Low-End Devices: Lesamnta-LW,” Springer, Berlin, Heidelberg, 2011, pp. 151–168.