|
Lightweight Cryptography Primitives
|
|
Lightweight Cryptography Primitives
|
This page lists all 10 finalists of the NIST Lightweight Cryptography Competition and the degree of support for each algorithm in the library.
This is a tough question given that as of early-2021 the NIST competition has whittled the list down to 10 final candidates but there is still a lot of variation in the candidates. But if you want to get encrypting now:
Note that these are my own personal preferences and are not based on any in-depth security analysis. The above algorithms could fall to an attack tomorrow but for now they have good space and speed trade-offs when implemented in software on 32-bit platforms.
The following table summarises the interesting properties of the 10 finalists to the NIST Lightweight Cryptography competition. More details are provided in the sections below.
| Algorithm | Key Sizes | Core | Mode | Nonce Reuse | Side Channels | Post Quantum | Hashing |
| ASCON | 128/160 | ASCON | MonkeyDuplex | M | K | Digest/XOF | |
| Elephant | 128 | Spongent/Keccak | Elephant | ||||
| GIFT-COFB | 128 | GIFT-128 | COFB | M | |||
| Grain-128AEAD | 128 | Grain-128 | Grain-128AEAD | ||||
| ISAP | 128 | ASCON/Keccak | Duplex | Y | |||
| PHOTON-Beetle | 128 | PHOTON-256 | Beetle | Digest | |||
| Romulus-N | 128 | SKINNY-128-384+ | Romulus-N | Digest/XOF | |||
| Romulus-M | 128 | SKINNY-128-384+ | Romulus-M | Y | Digest/XOF | ||
| Romulus-T | 128 | SKINNY-128-384+ | Romulus-T | Y | Digest/XOF | ||
| SPARKLE | 128/192/256 | SPARKLE | Beetle | K | Digest/XOF | ||
| TinyJAMBU | 128/192/256 | TinyJAMBU | TinyJAMBU | M | K | ||
| Xoodyak | 128 | Xoodoo | Cyclist | R | Digest/XOF |
"Core" indicates the core block operation that the sponge or block cipher mode is built around, and "Mode" indicates the mode itself.
All 10 finalists to the competition are inverse-free. In particular, the finalists that use block ciphers (GIFT-COFB and Romulus) only use the block encryption operation.
"Nonce Reuse" indicates that the algorithm provides some resistance against nonce reuse.
"Side Channels" indicates that the algorithm provides some resistance against power analysis side channels: "Y" indicates that the resistance is built in, "M" indicates that the resistance is present only if the core block operation is masked, and "R" indicates that the resistance is present only if the cipher is rekeyed after every packet.
"Post Quantum" indicates if the algorithm has resistance against post-quantum adversaries: "Y" indicates that all key sizes are resistant, "K" indicates that key sizes larger than 128 bits (e.g. 160, 192, or 256) provide the post-quantum resistance.
The following algorithm implementations in this library attempt to provide some protection against power analysis side channels:
These implementations have not yet been subjected to rigorous analysis, so the level of protection may not be as great as hoped.
In the case of ISAP, the protection is built into the algorithm. For the others, the "individual" directory contains "*_masked" variants side by side with the original unprotected versions.
Definition: ascon-aead.h, ascon-aead-masked.h, ascon-hash.h, ascon-xof.h
The ASCON family consists of the following AEAD algorithms:
ASCON-128 is the recommended algorithm from the NIST submission. ASCON-128-a is faster but does not mix the input state quite as much as ASCON-128. ASCON-80pq is essentially the same as ASCON-128 but it has a 160-bit key which may give added resistance against quantum computers.
The library also implements the ASCON-HASH, ASCON-HASHA, ASCON-XOF, and ASCON-XOFA hashing algorithms as companions to the AEAD mode.
This library also provides a masked implementation of ASCON.
Recommendation: Use ASCON-128 for now unless you consider the 128-bit key length to be too short, in which case you should use ASCON-80pq.
Definition: elephant-delirium.h, elephant-dumbo.h, elephant-jumbo.h
Elephant is a family of authenticated encryption algorithms based around the Spongent-pi and Keccak permutations.
Recommendation: The specification recommends Dumbo.
Definition: gift-cofb-aead.h, gift-cofb-aead-masked.h
GIFT-COFB is an authenticated encryption algorithm that combines the COFB (COmbined FeedBack) block cipher mode with the bit-sliced version of the GIFT-128 block cipher. The algorithm has a 128-bit key, a 128-bit nonce, and a 128-bit authentication tag.
The GIFT-128 block cipher was designed with hardware FPGA/ASIC implementations in mind, but with the fixsliced representation it is possible to acheive good software performance as well. This library implements fixslicing by default.
GIFT-COFB is a single-pass encryption algorithm, compared to the two-pass algorithm used by SUNDAE-GIFT. Out of all the GIFT-128 based submissions to NIST, GIFT-COFB has the best software performance, although HYENA is fairly close.
This library also implements a masked version of GIFT-COFB to provide protection against power analysis side channels.
Definition: grain-aead.h
Grain-128AEAD is an authenticated encryption algorithm based around a combination of a 128-bit linear feedback shift register (LFSR) and a 128-bit non-linear feedback shift register (NFSR). It is a member of the Grain family of stream ciphers.
Definition: isap-a-aead.h, isap-k-aead.h
ISAP is a family of authenticated encryption algorithms that are built around the Keccak-p[400] or ASCON permutations. There are four algorithms in the family, each of which have a 128-bit key, a 128-bit nonce, and a 128-bit tag:
ISAP is designed to provide some protection against adversaries using differential power analysis to determine the key. The downside is that key setup is very slow. The Keccak-p[400] permutation is slower than ASCON on 32-bit platforms.
Recommendation: The final round version of the specification recommends ISAP-A-128A. If hashing is required, then ISAP-A-128A should be paired with ASCON-HASH.
Definition: photon-beetle-aead.h, photon-beetle-hash.h
PHOTON-Beetle is a family of authenticated encryption algorithms based on the PHOTON-256 permutation and using the Beetle sponge mode. There are three algorithms in the family:
Recommendation: The specification recommends PHOTON-Beetle-AEAD-ENC-128.
Definition: romulus-m-aead.h, romulus-n-aead.h, romulus-t-aead.h, romulus-hash.h
Nonce Reuse: Resistant against nonce reuse as long as the combination of the associated data (AD) and plaintext is unique.
Romulus is a family of authenticated encryption and hash algorithms that are built around the SKINNY-128-384+ tweakable block cipher. There are several members in the family in round 3 of the competition:
The Romulus-M variant i resistant to nonce reuse as long as the combination of the associated data and plaintext is unique. If the same associated data and plaintext are reused under the same nonce, then the scheme will leak that the same plaintext has been sent for a second time but will not reveal the plaintext itself.
The Romulus-T variant is designed to provide leakage resilience.
The Romulus-N and Romulus-M padding and domain separation schemes are quite complex, so they are some of the larger algorithms to implement in software.
Recommendation: The specification recommends Romulus-N, or Romulus-M if resistance against nonce reuse is desirable.
Definition: sparkle-aead.h, sparkle-hash.h
SPARKLE is a family of encryption and hash algorithms that are based around the SPARKLE permutation. There are three versions of the permutation with 256-bit, 384-bit, and 512-bit state sizes. The algorithms in the family are:
SPARKLE has good performance in software on 32-bit platforms.
Recommendation: Schwaemm256-128 and Esch256 are the recommended variants from the NIST submission.
Definition: tinyjambu-aead.h, tinyjambu-aead-masked.h
TinyJAMBU is a family of encryption algorithms that are built around a lightweight 128-bit permutation. There are three variants of TinyJAMBU with different key sizes:
TinyJAMBU has one of the smallest RAM and flash memory footprints out of all of the NIST algorithms. Performance of TinyJAMBU-128 is also excellent.
Recommendation: TinyJAMBU-128 is the recommended variant in the NIST submission. Use TinyJAMBU-256 if you need a greater security margin.
Definition: xoodyak-aead.h, xoodyak-hash.h, xoodyak-masked.h
Xoodyak is an authenticated encryption and hash algorithm pair based around the 384-bit Xoodoo permutation that is similar in structure to Keccak but is more efficient than Keccak on 32-bit embedded devices. The Cyclist mode of operation is used to convert the permutation into a sponge for the higher-level algorithms.
The Xoodyak encryption mode has a 128-bit key, a 128-bit nonce, and a 128-bit authentication tag. The Xoodyak hashing mode has a 256-bit fixed hash output and can also be used as an extensible output function (XOF).
The Xoodyak specification describes a re-keying mechanism where the key for one packet is used to derive the key to use on the next packet. This provides some resistance against side channel attacks by making the session key a moving target. This library does not currently implement re-keying.
This library also provides a masked implementation of Xoodyak.
Recommendation: There is only one encryption algorithm and one hash algorithm in the Xoodyak family, so they the recommended ones.
Many of the algorithms are built on top of internal block ciphers and sponge block operations. Some of these operations are shared between multiple algorithms so they are provided in a common internal location.
All of the internal block operations are implemented in source files that start with the internal- prefix. They are not intended to be part of the public API for the AEAD algorithms.
If you wish to improve the performance of an algorithm implementation with assembly code or vector instructions, then the best place to start is with the internal block operation code.
1.8.6
