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 early2020 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 indepth security analysis. The above algorithms could fall to an attack tomorrow but for now they have good space and speed tradeoffs when implemented in software on 32bit 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 packetspecific 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 constantlyincrementing packet sequence number is sufficient).
To demonstrate why nonce reuse is bad, I'll briefly describe how AESGCM 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. SUNDAEGIFT has a variant with a zerolength nonce! The SUNDAEGIFT 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 (nonAES) 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  CHAM128/CHAM64/SPECK64  CTR/Beetle  
DryGASCON  128/256  GASCON  DryGASCON  Y  K  Digest  
Elephant  128  Spongent/Keccak  Elephant  
ESTATE  128  GIFT128  FCBC/OFB  Y  
ForkAE  128  ForkSkinny  PAEF/SAEF  N  
GIFTCOFB  128  GIFT128  COFB  
Gimli  256  Gimli  Duplex  Y  Digest/XOF  
Grain128AEAD  128  Grain128  Grain128AEAD  
HYENA  128  GIFT128  HyFB  
ISAP  128  ASCON/Keccak  Duplex  Y  
KNOT  128/192/256  KNOT  MonkeyDuplex  K  Digest  
LOTUSAEAD  128  GIFT64  OTR  
LOCUSAEAD  128  GIFT64  OCB  N  
ORANGE  128  PHOTON256  ORANGE  Digest  
Oribatida  128  SimP  Masked Duplex  
PHOTONBeetle  128  PHOTON256  Beetle  Digest  
Pyjamask  128  Pyjamask128/Pyjamask96  OCB  N  M  
RomulusN  128  SKINNY128  RomulusN  
RomulusM  128  SKINNY128  RomulusM  Y  
Saturnin  256  Saturnin  CTR/Cascade  Y  Digest  
SaturninShort  256  Saturnin  ECB  N  Y  
SKINNYAEAD  128  SKINNY128  ΘCB3  N  Digest  
SPARKLE  128/192/256  SPARKLE  Beetle  K  Digest  
SPIX  128  sLiSCPlight256  MonkeyDuplex  
SpoC  128  sLiSCPlight256/192  SpoC  
Spook  128  Clyde128/Shadow  S1P  Y  M  
Subterranean  128  Subterranean  Duplex  Digest  
SUNDAEGIFT  128  GIFT128  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 postquantum 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 postquantum 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 128bit key, a 128bit nonce, and a 128bit tag. It uses a duplex construction on top of a 320bit permutation. The permutation is a generalised version of sLiSCPlight, extended from 256 bits to 320 bits. ACE also has a companion hash algorithm with a 256bit output.
Similar Algorithms: SPIX, SpoC
Definition: ascon128.h
The ASCON family consists of the following AEAD algorithms:
ASCON128 is the recommended algorithm from the NIST submission. ASCON128a is faster but does not mix the input state quite as much as ASCON128. ASCON80pq is essentially the same as ASCON128 but it has a 160bit key which may give added resistance against quantum computers.
The library also implements the ASCONHASH and ASCONXOF hashing algorithms as companions to the AEAD mode.
This library also provides a masked implementation of ASCON.
Recommendation: Use ASCON128 for now unless you consider the 128bit key length to be too short, in which case you should use ASCON80pq.
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 COMET128_AES128/128 that is built around AES but this library does not implement that version.
COMET128_CHAM128/128 has good performance in software on 32bit platforms.
Recommendation: The specification recommends COMET128_AES128/128 but we don't implement AESbased schemes in this library. Recommend to use COMET128_CHAM128/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 DryGASCON128HASH.
Definition: elephant.h
Elephant is a family of authenticated encryption algorithms based around the Spongentpi 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_TweGIFT128 is an authenticated encryption algorithm with a 128bit key, a 128bit nonce, and a 128bit tag. It is a twopass algorithm that is built around a tweaked version of the GIFT128 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: GIFTCOFB, SUNDAEGIFT, 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 PAEFForkSkinny128288.
Definition: giftcofb.h, giftcofbmasked.h
GIFTCOFB is an authenticated encryption algorithm that combines the COFB (COmbined FeedBack) block cipher mode with the bitsliced version of the GIFT128 block cipher. The algorithm has a 128bit key, a 128bit nonce, and a 128bit authentication tag.
The GIFT128 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.
GIFTCOFB is a singlepass encryption algorithm, compared to the twopass algorithm used by SUNDAEGIFT. Out of all the GIFT128 based submissions to NIST, GIFTCOFB has the best software performance, although HYENA is fairly close.
This library also implements a masked version of GIFTCOFB to provide protection against power analysis side channels.
Similar Algorithms: SUNDAEGIFT, HYENA, ESTATE
Definition: gimli24.h, gimli24masked.h
GIMLI24CIPHER has a 256bit key, a 128bit nonce, and a 128bit 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 GIMLI24HASH in both regular hashing and XOF modes.
This library also provides a masked implementation of Gimli.
Definition: grain128.h
Grain128AEAD is an authenticated encryption algorithm based around a combination of a 128bit linear feedback shift register (LFSR) and a 128bit nonlinear 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 128bit key, a 96bit nonce, and a 128bit authentication tag. It makes a single pass over the associated data and plaintext.
The block cipher in HYENA is the nibblebased version of GIFT128. This makes HYENA slightly slower than GIFTCOFB in this implementation because nibblebased GIFT128 is implemented as a wrapper around the bitsliced version. Using the bitsliced version of GIFT128 with HYENA would make it slightly faster than GIFTCOFB.
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: GIFTCOFB, SUNDAEGIFT, ESTATE
Definition: isap.h
ISAP is a family of authenticated encryption algorithms that are built around the Keccakp[400] or ASCON permutations. There are four algorithms in the family, each of which have a 128bit key, a 128bit nonce, and a 128bit 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 Keccakp[400] permutation is slower than ASCON on 32bit platforms.
Recommendation: The specification recommends ISAPK128A, although ISAPA128A may be a better choice on 32bit 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 KNOTAEAD128256 and KNOTHASH256256.
Definition: lotuslocus.h
LOTUSAEAD and LOCUSAEAD are authenticated encryption algorithms that are based around a tweakable variant of the GIFT64 block cipher called TweGIFT64. Both AEAD algorithms have a 128bit key, a 128bit nonce, and a 64bit 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 TweGIFT64.
LOTUSAEAD uses a method similar to the block cipher mode OTR. TweGIFT64 is essentially converted into a 128bit block cipher using a Feistel construction and four TweGIFT64 block operations every 16 bytes of input.
LOCUSAEAD uses a method similar to the block cipher mode OCB with two TweGIFT64 block operations for every 8 bytes of input. LOCUSAEAD requires both the block encrypt and block decrypt operations of TweGIFT64, which increases the overall code size. LOTUSAEAD only needs the block encrypt operation.
Recommendation: The specification recommends LOTUSAEAD.
Based on AES. Not implemented.
Definition: orange.h
ORANGE is a family of algorithms built around the PHOTON256 permutation. There are two members of the family at present:
Definition: oribatida.h
Oribatida is a family of authenticated encryption algorithms based on the SimP256 and SimP192 permutations which are built around reducedround variants of the Simon128128 and Simon9696 block ciphers. There are two algorithms in the family:
Recommendation: The specification recommends Oribatida25664.
Definition: photonbeetle.h
PHOTONBeetle is a family of authenticated encryption algorithms based on the PHOTON256 permutation and using the Beetle sponge mode. There are three algorithms in the family:
Recommendation: The specification recommends PHOTONBeetleAEADENC128.
Definition: pyjamask.h, pyjamaskmasked.h
Pyjamask AEAD is a family of authenticated encryption algorithms that are built around the Pyjamask128 and Pyjamask96 block ciphers in OCB mode. Pyjamask128AEAD has a 128bit key, a 96bit nonce, and a 128bit authentication tag. Pyjamask96AEAD has a 128bit key, a 64bit nonce, and a 96bit 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 Pyjamask128AEAD.
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 SKINNY128 tweakable block cipher. There are six members in the family:
The RomulusM 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 RomulusN1, or RomulusM1 if resistance against nonce reuse is desirable. The specification recommends that Romulus should be paired with the SKINNYtk2HASH and SKINNYtk3HASH algorithms from the SKINNYAEAD submission if hashing is required.
Based on AES. Not implemented.
Definition: saturnin.h
Saturnin is a block cipher mode with a 256bit key, a 128bit nonce, and a 256bit authentication tag. It is built around a bitsliced variant of AES that has a 256bit block compared with AES's traditional 128bit block. The authors claim that the increased block size and the 256bit key size should give added protection against quantum computers.
Saturnin comes in two variants: SATURNINCTRCascade and SATURNINShort. SATURNINCTRCascade works on arbitrarysized inputs using a twopass combination of CTR mode with the Cascade authentication mode.
SATURNINShort 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 SATURNINHash.
Recommendation: SATURNINCTRCascade is the recommended variant from the NIST submission.
Definition: skinnyaead.h
SKINNYAEAD 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 SKINNY128384 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 "internalskinny128.h" header, then an alternative implementation is used that reduces the key schedule for SKINNY128384 to 48 bytes, and the key schedule for SKINNY128256 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 SKINNYAEAD family also includes two hash algorithms:
The hash algorithms use a more memoryefficient version of SKINNY128 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: SKINNYAEADM1 and SKINNYtk3HASH 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 256bit, 384bit, and 512bit state sizes. The algorithms in the family are:
SPARKLE has good performance in software on 32bit platforms.
Recommendation: Schwaemm256128 and Esch256 are the recommended variants from the NIST submission.
Definition: spix.h
SPIX is an authenticated encryption algorithm with a 128bit key, a 128bit nonce, and a 128bit tag. It uses the MonkeyDuplex construction on top of the 256bit sLiSCPlight permutation.
This library also provides a masked implementation of SPIX.
Definition: spoc.h
SpoC is a family of authenticated encryption algorithms with two members, SpoC128 and Spoc64. The algorithms use a Beetlelike sponge construction built on top of the sLiSCPlight permutation.
Spoc128 has good performance on small packets (16 bytes or less) on 32bit embedded platforms.
This library also provides masked implementations of SpoC128 and SpoC64.
Recommendation: The specification recommends SpoC64.
Definition: spook.h, spookmasked.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" (multiuser) variants combine the 128bit key and the 128bit public tweak into a single 256bit key value. Applications can either view this as a cipher with a 256bit key, or they can split the key value into secret and public halves. Even with the use of 256bit keys, Spook only has 128bit security.
Recommendation: The specification recommends Spook128512su.
Definition: subterranean.h
Subterranean (technically "Subterranean 2.0") is a family of algorithms built around the 257bit 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 SKINNYbased authenticated encryption schemes like SKINNYAEAD.
Definition: sundaegift.h
Nonce Reuse: Resistant against nonce reuse as long as the combination of the associated data (AD) and plaintext is unique.
The SUNDAEGIFT family consists of several related algorithms:
SUNDAEGIFT is built around the GIFT128 block cipher in bitsliced 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.
SUNDAEGIFT 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 SUNDAEGIFT0), 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: SUNDAEGIFT96 is the recommended variant in the NIST submission, with SUNDAEGIFT0 as the nextrecommended variant.
Similar Algorithms: GIFTCOFB, HYENA, ESTATE
Definition: tinyjambu.h
TinyJAMBU is a family of encryption algorithms that are built around a lightweight 128bit 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 TinyJAMBU128 is comparable to this library's implementation of GIMLI24.
Recommendation: TinyJAMBU128 is the recommended variant in the NIST submission. Use TinyJAMBU256 if you need a greater security margin.
WAGE is an authenticated encryption algorithm that is built around the 259bit WAGE permutation. The algorithm has a 128bit key, a 128bit nonce, and a 128bit 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 384bit Xoodoo permutation that is similar in structure to Keccak but is more efficient than Keccak on 32bit embedded devices. The Cyclist mode of operation is used to convert the permutation into a sponge for the higherlevel algorithms.
The Xoodyak encryption mode has a 128bit key, a 128bit nonce, and a 128bit authentication tag. The Xoodyak hashing mode has a 256bit fixed hash output and can also be used as an extensible output function (XOF).
The Xoodyak specification describes a rekeying 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 rekeying.
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.