|
Lightweight Cryptography Primitives
|
|
Lightweight Cryptography Primitives
|
This page lists all of the submissions to the second round 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-2020 the NIST competition has not yet whittled the list down or decided on final 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.
Some of the submissions to NIST use AES as the inner block cipher in the AEAD implementation. I haven't implemented any of those algorithms. AES is notoriously difficult to implement in software in a manner that avoids cache timing attacks. It is best to ignore AES and do something else.
From a high level point of view, if AES is already suitable as a lightweight cipher, then there's really no point to the NIST competition. The most the competition can produce is a new block cipher mode, and that mode could just as easily be used with a different block cipher that is not subject to cache timing attacks.
Every submission to the NIST competition takes the form of an Authenticated Encryption with Associated Data (AEAD) scheme. Such schemes typically take as input a key and a packet-specific nonce to encrypt a given plaintext and to authenticate the ciphertext plus some associated data (AD) that is not encrypted.
In the documentation for most AEAD schemes you will prominently find a prescription that "The nonce must be unique for every packet. If it isn't, then the scheme is not secure". Beginners to encryption can sometimes overlook this and not take sufficient care to make the nonce unique (usually a constantly-incrementing packet sequence number is sufficient).
To demonstrate why nonce reuse is bad, I'll briefly describe how AES-GCM works as it is typical of AEAD schemes:
Now let's see what happens when we reuse the nonce. We will have two packets with the same keystream:
If an attacker was able to guess Plaintext1 because it is a standard protocol header or similar, then they can trivially determine the keystream and the other plaintext with:
This is why it is so important that the nonce be unique for every packet. It is trivial to break many AEAD schemes if the nonce is chosen poorly.
Not all AEAD schemes are as vulnerable to nonce reuse. SUNDAE-GIFT has a variant with a zero-length nonce! The SUNDAE-GIFT specification states that as long as the combination (AD, Plaintext) is unique for each packet, then there is no need for a nonce: the associated data AD acts like a nonce. But obviously you still need to be careful to make the combination (AD, Plaintext) unique!
Below we will state any special considerations if the algorithm is resistant against nonce reuse. In the absence of any special considerations, you should assume that changing the nonce for each packet is vital for security.
A few bugs were found in the reference code for some of the algorithms. The bugs and their fixes are documented on this page.
The following table summarises the interesting properties of all (non-AES) NIST submissions. More details are provided in the sections below.
| Algorithm | Key Sizes | Core | Mode | Inverse Free | Nonce Reuse | Side Channels | Post Quantum | Hashing |
| ACE | 128 | ACE | ACE | Digest | ||||
| ASCON | 128/160 | ASCON | MonkeyDuplex | K | Digest/XOF | |||
| COMET | 128 | CHAM-128/CHAM-64/SPECK-64 | CTR/Beetle | |||||
| DryGASCON | 128/256 | GASCON | DryGASCON | Y | K | Digest | ||
| Elephant | 128 | Spongent/Keccak | Elephant | |||||
| ESTATE | 128 | GIFT-128 | FCBC/OFB | Y | ||||
| ForkAE | 128 | ForkSkinny | PAEF/SAEF | N | ||||
| GIFT-COFB | 128 | GIFT-128 | COFB | |||||
| Gimli | 256 | Gimli | Duplex | Y | Digest/XOF | |||
| Grain-128AEAD | 128 | Grain-128 | Grain-128AEAD | |||||
| HYENA | 128 | GIFT-128 | HyFB | |||||
| ISAP | 128 | ASCON/Keccak | Duplex | Y | ||||
| KNOT | 128/192/256 | KNOT | MonkeyDuplex | K | Digest | |||
| LOTUS-AEAD | 128 | GIFT-64 | OTR | |||||
| LOCUS-AEAD | 128 | GIFT-64 | OCB | N | ||||
| ORANGE | 128 | PHOTON-256 | ORANGE | Digest | ||||
| Oribatida | 128 | SimP | Masked Duplex | |||||
| PHOTON-Beetle | 128 | PHOTON-256 | Beetle | Digest | ||||
| Pyjamask | 128 | Pyjamask-128/Pyjamask-96 | OCB | N | M | |||
| Romulus-N | 128 | SKINNY-128 | Romulus-N | |||||
| Romulus-M | 128 | SKINNY-128 | Romulus-M | Y | ||||
| Saturnin | 256 | Saturnin | CTR/Cascade | Y | Digest | |||
| Saturnin-Short | 256 | Saturnin | ECB | N | Y | |||
| SKINNY-AEAD | 128 | SKINNY-128 | ΘCB3 | N | Digest | |||
| SPARKLE | 128/192/256 | SPARKLE | Beetle | K | Digest | |||
| SPIX | 128 | sLiSCP-light-256 | MonkeyDuplex | |||||
| SpoC | 128 | sLiSCP-light-256/192 | SpoC | |||||
| Spook | 128 | Clyde-128/Shadow | S1P | Y | M | |||
| Subterranean | 128 | Subterranean | Duplex | Digest | ||||
| SUNDAE-GIFT | 128 | GIFT-128 | SUNDAE | Y | ||||
| TinyJAMBU | 128/192/256 | TinyJAMBU | TinyJAMBU | K | ||||
| WAGE | 128 | WAGE | Duplex | |||||
| 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.
"Inverse Free" is "N" to indicate that the core block operation is used in both the encryption and decryption directions, or blank if the AEAD mode only needs encryption.
"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 DryGASCON and 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: ace.h
ACE is an authenticated encryption algorithm with a 128-bit key, a 128-bit nonce, and a 128-bit tag. It uses a duplex construction on top of a 320-bit permutation. The permutation is a generalised version of sLiSCP-light, extended from 256 bits to 320 bits. ACE also has a companion hash algorithm with a 256-bit output.
Similar Algorithms: SPIX, SpoC
Definition: ascon128.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 and ASCON-XOF 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: comet.h
COMET is a family of authenticated encryption algorithms that are built around an underlying block cipher. This library implements three members of the family:
There is also another family member COMET-128_AES-128/128 that is built around AES but this library does not implement that version.
COMET-128_CHAM-128/128 has good performance in software on 32-bit platforms.
Recommendation: The specification recommends COMET-128_AES-128/128 but we don't implement AES-based schemes in this library. Recommend to use COMET-128_CHAM-128/128 instead.
Definition: drygascon.h
DryGASCON is a family of authenticated encryption algorithms based around a generalised version of the ASCON permutation. DryGASCON is designed to provide some protection against power analysis.
There are four algorithms in the DryGASCON family:
Recommendation: The specification recommends DryGASCON128 and DryGASCON128-HASH.
Definition: elephant.h
Elephant is a family of authenticated encryption algorithms based around the Spongent-pi and Keccak permutations.
Recommendation: The specification recommends Dumbo.
Definition: estate.h
Nonce Reuse: Resistant against nonce reuse as long as the combination of the associated data (AD) and plaintext is unique.
ESTATE_TweGIFT-128 is an authenticated encryption algorithm with a 128-bit key, a 128-bit nonce, and a 128-bit tag. It is a two-pass algorithm that is built around a tweaked version of the GIFT-128 block cipher, the FCBC authentication mode, and the OFB encryption mode.
ESTATE is resistant against nonce reuse as long as the combination of the associated data and plaintext is unique.
If a nonce is reused then two packets with the same nonce, associated data, and plaintext will encrypt to the same ciphertext. This will leak that the same plaintext has been sent for a second time but will not reveal the plaintext itself.
The ESTATE family also includes variants built around tweaked versions of the AES block cipher. We do not implement those variants in this library.
Similar Algorithms: GIFT-COFB, SUNDAE-GIFT, HYENA
Definition: forkae.h
ForkAE is a family of authenticated encryption algorithms based on a modified version of the SKINNY tweakable block cipher. The modifications introduce "forking" where each input block produces two output blocks for use in encryption and authentication. There are six members in the ForkAE family:
The PAEF variants support parallel encryption and decryption for higher throughput. The SAEF variants encrypt or decrypt blocks sequentially.
ForkAE is designed to be efficient on small packet sizes so most of the PAEF algorithms have a limit of 64k or 128k on the amount of payload in a single packet. Obviously the input can be split into separate packets for larger amounts of data.
Recommendation: The specification recommends PAEF-ForkSkinny-128-288.
Definition: gift-cofb.h, gift-cofb-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.
Similar Algorithms: SUNDAE-GIFT, HYENA, ESTATE
Definition: gimli24.h, gimli24-masked.h
GIMLI-24-CIPHER has a 256-bit key, a 128-bit nonce, and a 128-bit tag. It is the spiritual successor to the widely used ChaCha20 and has a similar design.
The library also includes an implementation of the hash algorithm GIMLI-24-HASH in both regular hashing and XOF modes.
This library also provides a masked implementation of Gimli.
Definition: grain128.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: hyena.h
HYENA is an authenticated encryption algorithm that implements a hybrid feedback mode where a mixture of plaintext and ciphertext are mixed into the state each block operation.
HYENA has a 128-bit key, a 96-bit nonce, and a 128-bit authentication tag. It makes a single pass over the associated data and plaintext.
The block cipher in HYENA is the nibble-based version of GIFT-128. This makes HYENA slightly slower than GIFT-COFB in this implementation because nibble-based GIFT-128 is implemented as a wrapper around the bit-sliced version. Using the bit-sliced version of GIFT-128 with HYENA would make it slightly faster than GIFT-COFB.
Note: This library implements both the v1 and v2 versions of HYENA from the authors. The v1 version has a known forgery attack, but is provided because it is part of the second round algorithm set. The v2 version should be used in practice.
Similar Algorithms: GIFT-COFB, SUNDAE-GIFT, ESTATE
Definition: isap.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 specification recommends ISAP-K-128A, although ISAP-A-128A may be a better choice on 32-bit platforms for performance reasons.
Definition: knot.h
KNOT is a family of authenticated encryption and hash algorithms built around a permutation and the MonkeyDuplex sponge construction. The family members are:
This library also provides masked implementations of all KNOT encryption algorithms.
Recommendation: The specification recommends KNOT-AEAD-128-256 and KNOT-HASH-256-256.
Definition: lotus-locus.h
LOTUS-AEAD and LOCUS-AEAD are authenticated encryption algorithms that are based around a tweakable variant of the GIFT-64 block cipher called TweGIFT-64. Both AEAD algorithms have a 128-bit key, a 128-bit nonce, and a 64-bit tag.
The two algorithms have the same key initialization, associated data processing, and tag generation mechanisms. They differ in how the input is encrypted with TweGIFT-64.
LOTUS-AEAD uses a method similar to the block cipher mode OTR. TweGIFT-64 is essentially converted into a 128-bit block cipher using a Feistel construction and four TweGIFT-64 block operations every 16 bytes of input.
LOCUS-AEAD uses a method similar to the block cipher mode OCB with two TweGIFT-64 block operations for every 8 bytes of input. LOCUS-AEAD requires both the block encrypt and block decrypt operations of TweGIFT-64, which increases the overall code size. LOTUS-AEAD only needs the block encrypt operation.
Recommendation: The specification recommends LOTUS-AEAD.
Based on AES. Not implemented.
Definition: orange.h
ORANGE is a family of algorithms built around the PHOTON-256 permutation. There are two members of the family at present:
Definition: oribatida.h
Oribatida is a family of authenticated encryption algorithms based on the SimP-256 and SimP-192 permutations which are built around reduced-round variants of the Simon-128-128 and Simon-96-96 block ciphers. There are two algorithms in the family:
Recommendation: The specification recommends Oribatida-256-64.
Definition: photon-beetle.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: pyjamask.h, pyjamask-masked.h
Pyjamask AEAD is a family of authenticated encryption algorithms that are built around the Pyjamask-128 and Pyjamask-96 block ciphers in OCB mode. Pyjamask-128-AEAD has a 128-bit key, a 96-bit nonce, and a 128-bit authentication tag. Pyjamask-96-AEAD has a 128-bit key, a 64-bit nonce, and a 96-bit authentication tag.
Pyjamask is claimed to be resistant against power analysis side channels when implemented as a masked block cipher. This library implements both the masked and unmasked versions of Pyjamask.
The implementation of the block cipher in this library is very slow at the moment (patches welcome to address this).
Note that OCB is covered by patents so it may not be usable in all applications. Open source applications should be covered, but for others you will need to contact the patent authors to find out if you can use it or if a paid license is required.
License information: https://web.cs.ucdavis.edu/~rogaway/ocb/license.htm
Recommendation: The specification recommends Pyjamask-128-AEAD.
Definition: romulus.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 algorithms that are built around the SKINNY-128 tweakable block cipher. There are six members in the family:
The Romulus-M variants are 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 block padding and domain separation schemes are quite complex, so it is one of the larger algorithms to implement in software.
Recommendation: The specification recommends Romulus-N1, or Romulus-M1 if resistance against nonce reuse is desirable. The specification recommends that Romulus should be paired with the SKINNY-tk2-HASH and SKINNY-tk3-HASH algorithms from the SKINNY-AEAD submission if hashing is required.
Based on AES. Not implemented.
Definition: saturnin.h
Saturnin is a block cipher mode with a 256-bit key, a 128-bit nonce, and a 256-bit authentication tag. It is built around a bit-sliced variant of AES that has a 256-bit block compared with AES's traditional 128-bit block. The authors claim that the increased block size and the 256-bit key size should give added protection against quantum computers.
Saturnin comes in two variants: SATURNIN-CTR-Cascade and SATURNIN-Short. SATURNIN-CTR-Cascade works on arbitrary-sized inputs using a two-pass combination of CTR mode with the Cascade authentication mode.
SATURNIN-Short is designed to work on short inputs of no more than 15 bytes with no assoicated data and involves only a single block operation. It is very fast compared to other NIST submissions on short data.
The library also includes an implementation of the companion hash algorithm SATURNIN-Hash.
Recommendation: SATURNIN-CTR-Cascade is the recommended variant from the NIST submission.
Definition: skinny-aead.h
SKINNY-AEAD is a family of authenticated encryption algorithms that are built around the SKINNY tweakable block cipher. There are six members in the family:
This library's implementation of SKINNY-128-384 requires 464 bytes of RAM for the key schedule, which makes it one of the heavier algorithms amongst the NIST submissions when it comes to RAM size.
If the SKINNY_128_SMALL_SCHEDULE macro is defined to 1 in the "internal-skinny128.h" header, then an alternative implementation is used that reduces the key schedule for SKINNY-128-384 to 48 bytes, and the key schedule for SKINNY-128-256 to 32 bytes. The full key schedule is expanded on the fly, which comes at the cost of performance. The AVR implementation enables the small schedule version by default.
The SKINNY-AEAD family also includes two hash algorithms:
The hash algorithms use a more memory-efficient version of SKINNY-128 that expands the key schedule on the fly because the key needs to change every block. It does however have a performance cost to do this.
Recommendation: SKINNY-AEAD-M1 and SKINNY-tk3-HASH are the recommended variants from the NIST submission.
Definition: sparkle.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: spix.h
SPIX is an authenticated encryption algorithm with a 128-bit key, a 128-bit nonce, and a 128-bit tag. It uses the MonkeyDuplex construction on top of the 256-bit sLiSCP-light permutation.
This library also provides a masked implementation of SPIX.
Definition: spoc.h
SpoC is a family of authenticated encryption algorithms with two members, SpoC-128 and Spoc-64. The algorithms use a Beetle-like sponge construction built on top of the sLiSCP-light permutation.
Spoc-128 has good performance on small packets (16 bytes or less) on 32-bit embedded platforms.
This library also provides masked implementations of SpoC-128 and SpoC-64.
Recommendation: The specification recommends SpoC-64.
Definition: spook.h, spook-masked.h
Spook is a family of authenticated encryption algorithms that are built around a tweakable block cipher and a permutation.
If the tweakable block cipher is implemented as a masked block cipher, then Spook provides protection against power analysis side channels. This library implements both the masked and unmasked versions of Spook.
There are four members in the Spook family:
In this library, the "mu" (multi-user) variants combine the 128-bit key and the 128-bit public tweak into a single 256-bit key value. Applications can either view this as a cipher with a 256-bit key, or they can split the key value into secret and public halves. Even with the use of 256-bit keys, Spook only has 128-bit security.
Recommendation: The specification recommends Spook-128-512-su.
Definition: subterranean.h
Subterranean (technically "Subterranean 2.0") is a family of algorithms built around the 257-bit Subterranean permutation:
The Subterranean permutation is intended for hardware implementation. It is not structured for efficient software implementation. Despite that, this library's implementation is still fairly competitive, with similar performance to SKINNY-based authenticated encryption schemes like SKINNY-AEAD.
Definition: sundae-gift.h
Nonce Reuse: Resistant against nonce reuse as long as the combination of the associated data (AD) and plaintext is unique.
The SUNDAE-GIFT family consists of several related algorithms:
SUNDAE-GIFT is built around the GIFT-128 block cipher in bit-sliced mode. Two passes are made over the input data. The first pass computes the authentication tag over the nonce, associated data, and plaintext. The second pass encrypts the plaintext to produce the ciphertext.
SUNDAE-GIFT is resistant against nonce reuse as long as the combination of the associated data and plaintext is unique.
If a nonce is reused (or there is no nonce in the case of SUNDAE-GIFT-0), then two packets with the same associated data and plaintext will encrypt to the same ciphertext. This will leak that the same plaintext has been sent for a second time but will not reveal the plaintext itself.
Recommendation: SUNDAE-GIFT-96 is the recommended variant in the NIST submission, with SUNDAE-GIFT-0 as the next-recommended variant.
Similar Algorithms: GIFT-COFB, HYENA, ESTATE
Definition: tinyjambu.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 comparable to this library's implementation of GIMLI-24.
Recommendation: TinyJAMBU-128 is the recommended variant in the NIST submission. Use TinyJAMBU-256 if you need a greater security margin.
WAGE is an authenticated encryption algorithm that is built around the 259-bit WAGE permutation. The algorithm has a 128-bit key, a 128-bit nonce, and a 128-bit authentication tag. It is an evolution of the WG series of stream ciphers.
Definition: xoodyak.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
