Abstract
Authenticated encryption satisfies the basic need for authenticity and confidentiality in our information infrastructure. In this paper, we provide the specification of Ascon128 and Ascon128a. Both authenticated encryption algorithms provide efficient authenticated encryption on resourceconstrained devices and on highend CPUs. Furthermore, they have been selected as the “primary choice” for lightweight authenticated encryption in the final portfolio of the CAESAR competition. In addition, we specify the hash function AsconHash, and the extendable output function AsconXof. Moreover, we complement the specification by providing a detailed overview of existing cryptanalysis and implementation results.
Introduction
Authenticated encryption schemes protect authenticity and confidentiality of data, two security properties that are crucially needed in our information infrastructure. While the traditional focus of authenticated encryption was in securing the connection between two communicating devices, more and more devices now operate in environments where an attacker may have physical access to the device. Hence, efficient protection against sidechannel attacks is crucial and should preferably be implementable efficiently on resourceconstrained devices. At the same time, ciphers should also lend themselves to fast software implementations on higherend CPUs.
In this paper, we present the cipher suite Ascon, which provides authenticated encryption with associated data (AEAD) and hashing functionality. The suite consists of the authenticated ciphers Ascon128 and Ascon128a, which have been selected as primary choice for lightweight authenticated encryption in the final portfolio of the CAESAR competition [87], the hash function AsconHash, and the extendable output function AsconXof. All schemes provide 128bit security and internally use the same 320bit permutation (with different round numbers) so that a single lightweight primitive is sufficient to implement both AEAD based on the duplex construction [17] and extendableoutput hashing using the sponge construction [14].
The Ascon suite and especially the underlying 320bit permutation have been designed with these challenges of our modern information infrastructure in mind. Ascon is considered highly secure and robust in practice with a very low area footprint in hardware while providing good performance in software and hardware implementations. To provide these properties, the main components of Ascon are inspired from standardized and wellanalyzed primitives. The substitution layer uses an affine equivalent of the Sbox used in the \(\chi \) mapping of Keccak [19, 27] designed to add diffusion. The permutation layer uses linear functions similar to the \(\Sigma \) functions used in SHA2 [71, 72]. The resulting permutation is defined on 64bit words using only bitwise Boolean functions (and, not, xor) and rotations within words. Hence, the permutation lends itself well to fast bitsliced implementations on 64bit platforms, while bit interleaving [13] allows for fast bitsliced implementations on 32, 16, and 8bit platforms. Thus, Ascon is an excellent choice in scenarios where lightweight devices carry out cryptographic operations. Due to the good performance in software, Ascon is a perfect fit in scenarios where lightweight devices communicate with highend servers. Benchmarks show that Ascon is particularly efficient for short messages [1, 45].
Ciphers have to withstand realworld threats. Therefore, Ascon ’s permutation and authenticated encryption mode have been designed to provide robustness against certain implementation mistakes and attacks and to facilitate efficient protected implementations. For example, even if an attacker somehow manages to recover an internal state during data processing (e.g., due to sidechannel attacks), this does not directly lead to the recovery of the secret key or to constructing forgeries without significant additional computations. Besides increasing the robustness of any implementation, this also allows more efficient protection against sidechannel attacks such as differential power analysis (DPA) attacks with leveled implementations [4, 7]: In masked implementations, it can be sufficient that the initialization and finalization provides high robustness against sidechannel analysis, whereas the bulk data can be processed at higher speed with a lower protection level. Thanks to Ascon ’s lowdegree Sbox, masked implementations induce only a relatively small overhead in hardware and software [75], so it is feasible to include protection on constrained devices.
Ascon128 and Ascon128a have been selected as the “primary choice” for lightweight authenticated encryption in the final portfolio of the CAESAR competition. Of the initial 57 submissions, six were selected for this portfolio in three usecases. During this competition, Ascon and its permutation have undergone a thorough public evaluation. This has resulted in numerous publications giving insight in the security of Ascon, and many more that discuss Ascon more generally. All existing analysis shows a comfortable security margin, with no indication of weaknesses regarding Ascon128 and Ascon128a.
History Ascon was first published as a candidate in Round 1 [32] of the CAESAR competition [87]. This original design (version v1) specified the permutation as well as the mode for authenticated encryption with two recommended family members: The primary recommendation Ascon128 as well as a variant Ascon96 with 96bit key. For the subsequent versions v1.1 for Round 2 [33] and v1.2 for Round 3 [35], minor functional tweaks were applied, including a reordering of the round constants and the modification of the secondary recommendation to the current Ascon128a.
At the time of writing, Ascon is competing in Round 2 [36] of the NIST Lightweight Cryptography (LWC) project [74]. The submission to NIST includes not only the authenticated cipher family, but also introduces modes of operation for hashing: AsconHash (with fixed output size) and AsconXof (with variable output size), as well as a third parameterization for authenticated encryption: Ascon80pq.
The present paper describes Ascon v1.2 as selected in the CAESAR competition including its additions for NIST LWC competition.
Outline We specify the Ascon cipher suite with its modes for authenticated encryption and hashing as well as the core permutation in Sect. 2. We summarize the security claim for the Ascon family in Sect. 3 and give an overview of Ascon ’s main features in Sect. 4. In Sect. 5, we provide details on the design rationale for the modes and the permutation. In Sect. 6, we analyze the security of the Ascon cipher suite and provide an overview of thirdparty cryptanalysis results. We summarize and discuss implementation security and efficient implementations in Sect. 7. Finally, we conclude in Sect. 8.
Specification of Ascon
This section provides a complete and selfcontained specification of the Ascon cipher suite, starting with an overview of the algorithms in Sect. 2.1, the individual recommended parameter sets in Sect. 2.2, and the notation in Sect. 2.3. Afterward, the authenticated encryption modes are specified in Sect. 2.4, the hashing mode in Sect. 2.5, and the underlying permutation in Sect. 2.6.
Algorithms in the Ascon Cipher Suite
The Ascon cipher suite consists of a family of authenticated encryption designs Ascon together with the hash function AsconHash that builds upon the extendable output function AsconXof.
Authenticated encryption For the authenticated encryption designs Ascon, the family members are parameterized by the key length \(k \le 160\) bits, the rate (data block size) r and internal round numbers a and b. Each design specifies an authenticated encryption algorithm \(\mathcal {E}_{k,r,a,b} \) and a decryption algorithm \(\mathcal {D}_{k,r,a,b} \). The authenticated encryption procedure \(\mathcal {E}_{k,r,a,b} \) takes as inputs a secret key K with k bits, a nonce (public message number) N with 128 bits, associated data A of arbitrary length and a plaintext P of arbitrary length. It produces an output consisting of the authenticated ciphertext C of exactly the same length as the plaintext P plus an authentication tag T of size 128 bits, which authenticates both the associated data and the encrypted message:
The decryption and verification procedure \(\mathcal {D}_{k,r,a,b} \) takes as input the key K, nonce N, associated data A, ciphertext C and tag T, and outputs either the plaintext P if the verification of the tag is correct or an error \(\bot \) if the verification of the tag fails:
Hashing The extendable output function is parameterized by the rate (data block size) r, a round number a, and an output length limit h (\(h=0\) for unlimited output). The extendable output function \(\mathcal {X}_{h,r,a} \) maps the input message M of arbitrary length to a hash output H of arbitrary specified length \(\ell \le h\):
Both AsconHash and AsconXof use this algorithm: AsconHash with \(h=\ell =256\), AsconXof with \(h=0\) for unlimited output. The parameter \(\ell \) solely influences the bit length of H. So, calls to \(\mathcal {X}_{h,r,a} (M,\ell ') = H'\) and \(\mathcal {X}_{h,r,a} (M,\ell '') = H''\), having the same parameters and inputs except \(\ell ' < \ell ''\) result in \(H'\) and \(H''\) having the same value for the first \(\ell '\) bits.
Recommended Parameter Sets
Authenticated Encryption Table 1 lists our recommended instances for authenticated encryption and specifies their parameters, including the key size k, the fixed nonce and tags sizes, the rate r, and the number of rounds a for the initialization and finalization permutation \(p^a\) and b for the intermediate permutation \(p^b\) processing the associated data and plaintext. The list is sorted by priority: the primary recommendation is Ascon128 and the secondary recommendation is Ascon128a. Both schemes are identical to the CAESAR candidates [35] selected as primary choices for lightweight usecases in the final CAESAR portfolio [87].
Hashing Table 2 lists our recommended instance for hashing and specifies its parameters, including the size of the hash output h, the rate r, as well as the number of rounds a for the permutation \(p^a\). The list is sorted by priority: the primary and only recommendation is AsconHash.
Further constructions based on Ascon ’s permutation. Besides these main recommendations listed above, it is also possible to use Ascon ’s permutation for other purposes and in different parameter configurations.
We define an extendable output function AsconXof which uses the algorithm \(\mathcal {X}_{0,64,12} \) with a rate of 64 bits and 12 rounds for \(p^a\) to produce a hash output of arbitrary length (see Table 3).
Furthermore, we define a new authenticated encryption scheme Ascon80pq which uses the algorithms \(\mathcal {E},\mathcal {D}_{160,64,12,6} \) with an increased key size of 160 bits, a nonce and tag size of 128 bits, a rate of 64 bits, 12 rounds for \(p^a\) and 6 rounds for \(p^b\) (see Table 4).
State and Notation
All members of the Ascon cipher suite operate on a state of 320 bits which they update with permutations \(p^a\) (a rounds) and \(p^b\) (b rounds). The 320bit state S is divided into an outer part \(S_r\) of r bits and an inner part \(S_c\) of c bits, where the rate r and capacity \(c=320r\) depend on the Ascon variant.
For the description and application of the round transformations (Sect. 2.6), the 320bit state S is split into five 64bit registers words \(x_i\), as illustrated in Fig. 3a:
Whenever S needs to be interpreted as a bytearray (or bitstring), it starts with the most significant byte (or bit) of \(x_0\) as byte 0 and ends with the least significant byte (or bit) of \(x_4\) as byte 39.
Table 5 lists the notation and symbols used in this document.
Authenticated Encryption
The mode of operation of Ascon for authenticated encryption is based on duplex modes like MonkeyDuplex [20], but uses a stronger keyed initialization and keyed finalization function. The encryption and decryption operations are illustrated in Fig. 1a, b and specified in Algorithm 1.
Initialization The 320bit initial state of Ascon is formed by the secret key K of k bits and nonce N of 128 bits, as well as an IV specifying the algorithm (including the key size k, the rate r, the initialization and finalization round number a, and the intermediate round number b, each written as an 8bit integer):
In the initialization, a rounds of the round transformation p are applied to the initial state, followed by an xor of the secret key K:
Processing Associated Data Ascon processes the associated data A in blocks of r bits. It appends a single 1 and the smallest number of 0s to A to obtain a multiple of r bits and split it into s blocks of r bits, \(A_1\Vert \ldots \Vert A_s\). In case A is empty, no padding is applied and \(s = 0\):
Each block \(A_i\) with \(i = 1, \ldots , s\) is xored to the first r bits \(S_r\) of the state S, followed by an application of the bround permutation \(p^b\) to S:
After processing \(A_s\) (also if \(s=0\)), a 1bit domain separation constant is xored to S:
Processing Plaintext/Ciphertext Ascon processes the plaintext P in blocks of r bits. The padding process appends a single 1 and the smallest number of 0s to the plaintext P such that the length of the padded plaintext is a multiple of r bits. The resulting padded plaintext is split into t blocks of r bits, \(P_1\Vert \ldots \Vert P_t\):
Encryption In each iteration, one padded plaintext block \(P_i\) with \(i=1,\ldots ,t\) is xored to the first r bits \(S_r\) of the internal state S, followed by the extraction of one ciphertext block \(C_i\). For each block except the last one, the whole internal state S is transformed by the permutation \(p^b\) using b rounds:
The last ciphertext block \(C_t\) is then truncated to the length of the unpadded last plaintext blockfragment so that its length is between 0 and \(r1\) bits, and the total length of the ciphertext C is exactly the same as for the original plaintext P:
Decryption In each iteration except the last one, the plaintext block \(P_i\) is computed by xoring the ciphertext block \(C_i\) with the first r bits \(S_r\) of the internal state. Then, the first r bits of the internal state, \(S_r\), are replaced by \(C_i\). Finally, for each ciphertext block except the last one, the internal state is transformed by the bround permutation \(p^b\):
For the last, truncated ciphertext block \(\tilde{C}_t\) with \(0 \le \ell < r\) bits, the procedure differs:
Finalization In the finalization, the secret key K is xored to the internal state and the state is transformed by the permutation \(p^a\) using a rounds. The tag T consists of the last 128 bits of the state xored with the last 128 bits of the key K:
The encryption algorithm returns the tag T together with the ciphertext \(C_1 {\Vert }\ldots {\Vert }\tilde{C}_t\). The decryption algorithm returns the plaintext \(P_1 {\Vert }\ldots {\Vert }\tilde{P}_t\) only if the calculated tag value matches the received tag value.
Hashing
The mode of operation for hashing is the sponge construction [14]. Both the hash function AsconHash with fixed output size and the extendable output function AsconXof with variable output size internally use the same hashing algorithm \(\mathcal {X}_{h,r,a} \) (see Table 2), which is illustrated in Fig. 2 and specified in Algorithm 2.
Initialization The 320bit initial state of AsconXof and AsconHash is defined by a constant IV that specifies the algorithm parameters in a similar format as for Ascon (including \(k=0\), the rate r, and round numbers a and \(b=0\), each written as an 8bit integer), followed by the maximal output length of h bits as a 32bit integer (with \(h=\ell =256\) for AsconHash and \(h=0\) for unlimited output in AsconXof) and a 256bit zero value. The around permutation \(p^a\) is applied to initialize the state S:
The initial 320bit state S can be precomputed for each instance and we get for AsconHash (left) and AsconXof (right):
Absorbing Message AsconXof and AsconHash process the message M in blocks of r bits. The padding process is the same as for the plaintext of Ascon: it appends a single 1 and the smallest number of 0s to M such that the length of the padded message is a multiple of r bits. The resulting padded message is split into s blocks of r bits, \(M_1\Vert ...\Vert M_s\):
The message blocks \(M_i\) with \(i = 1, \ldots , s\) are processed as follows. Each block \(M_i\) is xored to the first r bits \(S_r\) of the state S, followed by an application of the around permutation \(p^a\) to S:
Squeezing The hash output is extracted from the state in rbit blocks \(H_i\) until the requested output length \(\ell \le h\) is completed after \(t = \left\lceil \ell /r \right\rceil \) blocks. After each extraction, the internal state S is transformed by the around permutation \(p^a\):
The last output block \(H_t\) is truncated to \(\ell \bmod r\) bits (unless r divides \(\ell \)) and \(H = H_1 {\Vert }\ldots {\Vert }\tilde{H}_t\) returned:
Permutation
The main components of the schemes Ascon, AsconXof, and AsconHash are the two 320bit permutations \(p^a\) and \(p^b\). The permutations iteratively apply an SPNbased round transformation p that in turn consists of three steps \(p_C\), \(p_S\), \(p_L\):
\(p^a\) and \(p^b\) differ only in the number of rounds. The number of rounds a and the number of rounds b are tunable security parameters.
For the description and application of the round transformations, the 320bit state S is split into five 64bit registers words \(x_i\), \(S = x_0 {\Vert }x_1 {\Vert }x_2 {\Vert }x_3 {\Vert }x_4\) (see Fig. 3).
Addition of Constants The constant addition step \(p_C\) adds a round constant \(c_r\) to register word \(x_2\) of the state S in round i (see Fig. 3a). Both indices r and i start from zero and we use \(r=i\) for \(p^a\) and \(r=i+ab\) for \(p^b\) (see Table 6):
Substitution Layer The substitution layer \(p_S\) updates the state S with 64 parallel applications of the 5bit Sbox \(\mathcal {S}(x)\) defined in Fig. 4a to each bitslice of the five registers \(x_0\ldots x_4\) (Fig. 3b). It is typically implemented in this bitsliced form with operations performed on the entire 64bit words, as in the example code in Fig. 5. The lookup table of \(\mathcal {S}\) is given in Table 7, where \(x_0\) is the MSB and \(x_4\) the LSB.
Linear Diffusion Layer The linear diffusion layer \(p_L\) provides diffusion within each 64bit register word \(x_i\) (Fig. 3c). It applies a linear function \(\Sigma _i(x_i)\) defined in Fig. 4b to each word \(x_i\):
Security Claims
Authenticated Encryption
All Ascon family members provide 128bit security in the notion of noncebased authenticated encryption with associated data (AEAD), that is, they protect the confidentiality of the plaintext (except its length) and the integrity of ciphertext including the associated data (under adaptive forgery attempts). The number of processed plaintext and associated data blocks protected by the encryption algorithm is limited to a total of \(2^{64}\) blocks per key, which corresponds to \(2^{67}\) bytes (for Ascon128, Ascon80pq) or \(2^{68}\) bytes (for Ascon128a). We consider this as more than sufficient for lightweight applications in practice. In order to fulfill the security claims stated in Table 8, implementations must take care that the nonce (public message number) is never repeated for two encryptions under the same key, and that decrypted plaintexts are only released after successful verification of the final tag. The difference between the family members is in their robustness against other adversaries beyond the classical security claim and is discussed in the following. In particular, Ascon128a offers a higher throughput at the cost of reduced robustness.
Ascon has been designed for robust security in case of certain implementation errors that violate these requirements, such as repeated nonces. For instance, the security claims of Table 8 can even be fulfilled if nonces are reused a few times by accident as long as the combination of nonce and associated data stays unique. Furthermore, even a full recovery of a single secret state during the processing of the associated data, plaintext, or ciphertext (e.g., with implementation attacks) does not imply practical global attacks such as key recovery or forgeries without significant additional computations. In this case, forgeries can be obtained with complexity \(2^{c/2}\) by constructing collisions on the inner part, so the robustness of Ascon128a (\(c=192\)) is lower than that of Ascon128 (\(c=256\)). The same holds for key recovery attacks. We do not expect that key recovery attacks for Ascon128a and Ascon128 can be found with complexity significantly below \(\min (2^k,2^{c/2})\) (\(2^{96}\) and \(2^{128}\), respectively) even if a few internal states can be recovered.
Except for the singleuse requirement, there are no constraints on the choice of the nonce (public message number); in particular, it is possible to use a simple counter. It is beneficial that a system or protocol implementing the algorithm monitors and, if necessary, limits the number of tag verification failures per key. After reaching this limit, the decryption algorithm rejects all tags. Such a limit is not required for the security claims above, but may be reasonable in practice to increase the robustness against some classes of implementation attacks.
As for most encryption algorithms, the ciphertext length leaks the plaintext length since the two lengths are equal (excluding the tag length). If the plaintext length is confidential, users must compensate this by padding their plaintexts.
We emphasize that we do not require ideal properties for the permutations \(p^a, p^b\). Nonrandom properties of the permutations \(p^a, p^b\) are known and do not afflict the claimed security properties of the entire encryption algorithm. For a detailed security analysis of Ascon, we refer to Sect. 6.
Hashing
Both AsconHash and AsconXof provide 128bit security against collision attacks and (second) preimage attacks, as stated in Table 9. Note that the security of AsconXof is reduced if the output size \(\ell \) is less than 256 bits. Like other spongebased hash functions, both AsconHash and AsconXof also resist length extension attacks and secondpreimage attacks for long messages.
Like for authenticated encryption, we emphasize that we do not require ideal properties for the permutations. Nonrandom properties of the permutations are known and do not afflict the claimed security properties of AsconHash and AsconXof.
A Note on PostQuantum Security
Since Ascon is targeting lightweight applications, we do not claim resistance against all possible quantum attacks. However, Ascon provides enough robustness and agility to provide basic resistance against certain classes of attacks once the availability of appropriate quantum computer resources become evident.
Therefore, the Ascon suite provides an additional AEAD scheme Ascon80pq. The only difference between Ascon80pq and Ascon128 is the increased key length of 160 bits. This increased key length provides additional protection against Grover’s algorithm for exhaustive key search [57]. The resulting security against Grover’s key search is about 80 bits. Since all other tunable security parameters (the number of rounds of the permutations) are not changed, the security claim for Ascon80pq against classical attacks stays the same as for Ascon128, which is 128 bits (see Table 8).
Furthermore, AsconHash and AsconXof use the sponge construction with a capacity of \(c=256\) bits and an output size of \(\ell \) bits (with \(\ell =256\) for AsconHash). The postquantum security of the sponge construction has been analyzed in [24]. The resulting estimated bound is \(\min (c/3,\ \ell /3)\). However, note that their proof applies to sponge functions with noninvertible functions instead of a permutation as in Ascon. In [22], the complexity of finding collisions using a quantum computer is assumed to be \(2^{\ell /3}\). Although the complexity of the best quantum attack on the sponge construction using a random permutation is unknown, no quantum attack with a complexity below \(\min (c/3,\ \ell /3)\) is known yet.
Features
The Ascon suite supports authenticated encryption and hashing with the same lightweight permutation. Ascon128 and Ascon128a have been selected as the “primary choice” for lightweight authenticated encryption in the final portfolio of the CAESAR competition. Ascon achieves high security and robustness in practice with a very low area footprint in hardware while providing good performance in both software and hardware implementations, particularly for short messages. We believe that ciphers which operate efficiently and securely on very resourceconstrained devices, on modern highend systems, and also in the area between these two extremes will be of rising importance in the future. A typical example for such dual environments is the Internet of Things (IoT), where a large number of very constrained devices need to communicate efficiently with highperformance backend servers. In the following, we summarize the most important properties of Ascon and justify that the cipher suite is a perfect fit for such applications.
Properties of Ascon

Authenticated Encryption and Hashing Ascon offers authenticated encryption and hashing with the same underlying permutation. Sharing a single primitive for all schemes not only reduces the area requirements for hardware implementations that want to provide both, but also allows to restrict the code base that has to be maintained. This reduces the workload necessary for efficient and secure implementations.

High Cryptanalytic Security Ascon128 and Ascon128a have been selected as the “primary choice” for lightweight authenticated encryption in the final portfolio of the CAESAR competition after five years of evaluation. During this competition, Ascon and its permutation have undergone a thorough public analysis. So far, this has resulted in more than 15 publications giving insight in the security of Ascon (see Sect. 6.4). All existing analysis shows a comfortable security margin, with no indication of weaknesses regarding Ascon128 and Ascon128a. A detailed discussion about the security of Ascon can be found in Sect. 6.

Simplicity Ascon is natively defined on 64bit words using only the bitwise Boolean functions and, xor, not, and rot (bitwise rotation). This significantly reduces the effort of implementing the algorithm on new target platforms.

Lightweight and Flexible in Hardware Current implementation results show that Ascon provides excellent implementation characteristics in terms of size and speed. Balanced roundbased CAESAR API implementations of Ascon128 and Ascon128a achieve a throughput of 4.9–7.3 Gbps using less than 10 kGE. Due to the small state size and the elegant structure of Ascon ’s round function, it is additionally possible to provide hardware implementations that are optimized toward either a smaller area or higher speed. More details about hardware implementations are provided in Sect. 7.

Efficient in Software Ascon is designed to facilitate bitsliced software implementations. Its internal 64bit operations are also wellsuited for processors with smaller word sizes, and can take advantage of pipelining and parallelization features of highend processors. In particular, the substitution and linear layers have been specifically designed to support high instruction parallelism. In addition, the small state of Ascon allows to hold the whole state within the CPU’s registers for a wide range of platforms, thus reducing reloads from the cache to a minimum. Further discussions about the performance in software can be found in Sect. 7.

Balanced CrossPlatform Design Ascon follows a balanced design approach, instead of optimizing for only one particular platform or usecase at the cost of efficiency on other platforms. In particular, Ascon has been designed to provide lightweight implementation characteristics in both hardware and software while still offering competitive performance on both. Hence, Ascon is highly suited for scenarios where many lightweight devices communicate with a backend server, a typical usecase in the Internet of Things (IoT).

Easy Integration of SideChannel Countermeasures Ascon can be implemented efficiently for platforms and applications where sidechannel resistance is important. The very efficient bitsliced implementation of the Sboxes prevents cachetiming attacks, since no lookup tables are required. Furthermore, the low algebraic degree of the Sbox facilitates both first and higherorder protection using masking or sharingbased sidechannel countermeasures. More information about the integration of countermeasures against implementation attacks can be found in Sect. 7.

Robust Security in Practice Ascon ’s spongebased mode of operation for noncebased authenticated encryption features a strengthened keyed initialization and finalization. This improves the cipher’s robustness in case of misuse attacks, for example against a noncereuse attacker. A potential recovery of the secret state during data processing due to misuse attacks thus does not directly lead to a keyrecovery or universal forgery.

Online and SinglePass All Ascon algorithms are online and can process the data blocks before the complete input or its length are known. For both Ascon encryption and decryption, just one pass over the data is required.

InverseFree Ascon does not need to implement any inverse operations since the permutations \(p^a\) and \(p^b\) are only evaluated in one direction for both encryption and decryption, which significantly reduces the area overhead.

High Key Agility Ascon does not use a key schedule or expand the key by any other means, so there are no hidden setup costs when the key is changed.
Features for Lightweight Applications

Small hardware area Ascon ’s small state and simple round function are wellsuited for small implementations, without compromising on the full security of 128 bits. Existing lightweight implementations of Ascon ’s authenticated encryption functionality are as small as 2.6 kGE [59]. The roundbased implementations are smaller than 10 kGE and still offer a throughput of 4.9–7.3 Gbps, which is already sufficient to encrypt a Gigabit Ethernet connection. More details about (protected) hardware implementations are provided in Sect. 7.

Reuse of core component Implementing the Ascon permutation once is enough to get authenticated encryption as well as decryption with a very small overhead, since decryption does not require the inverse of the permutation (that is, Ascon is inversefree). Together with AsconHash and AsconXof, it also provides hashing functionality using the same permutation.

Efficiency in hardware Ascon is not only small and fast, but can also be efficiently implemented on a wide variety of platforms [49]. It allows many tradeoffs between throughput, latency, gate count, power consumption, etc. [59]. Comparison of implementation results in [49] show that throughput per area of both Ascon variants is very good compared to many other CAESAR candidates. Further discussion about the performance in hardware can be found in Sect. 7.

Bitinterleaved implementations Ascon ’s permutation is naturally defined on 64bit words, with rotation operations performed on them and hence, lends itself to natural bitsliced implementations on 64bit processors. However, on architectures with a smaller wordsize, it is possible to implement Ascon using bit interleaving as introduced for Keccak [13]. In short, bit interleaving involves sorting the single bits in n registers of 64/n bits (with \(n=2,4,8\)), such that a single rotation on one 64bit word can be implemented using n rotations on each of the n (64/n)bit words. Hence, when neglecting the effort to interleave the bits, the number of operations per round on smaller architectures only increases roughly to \(n \cdot \ell \), where \(\ell \) are the number of operations needed with 64bit registers. Thus, Ascon allows not only for fast bitsliced implementations on 64bit processors, but also allows for fast bitsliced implementations on smaller architectures that do not require any datadependent lookup tables. Further insights about the performance in software on various platforms are given in Sect. 7.

Natural sidechannel protection This is one of the primary design goals of Ascon. For protection against sidechannel attacks, it is important that the Sbox is easy to protect. Ascon ’s Sbox has a low algebraic degree of 2 and a low number of Boolean multiplications, which is wellsuited for threshold implementations [75] and similar protection approaches. More information about the integration of countermeasures against implementation attacks can be found in Sect. 7.4.

Limited damage in misuse settings Ascon uses noncebased authenticated encryption. As with any noncebased authenticated encryption scheme, repeating nonces is a misuse setting, and implies a loss of semantic security. But compared to other spongebased constructions, Ascon provides better robustness in case of a potential state recovery, since both initialization and finalization are keyed additionally. A recovery of the secret state during data processing does not directly lead to a keyrecovery or universal forgery. Furthermore, Ascon ’s mode is compatible with alternative decryption interfaces for secure implementations in memoryconstrained settings [2].

Low overhead for short messages Ascon is among the fastest CAESAR candidates for short messages according to current software benchmarking results[1, 45], since its initialization and finalization overhead is much smaller compared to most blockcipherbased constructions, stream ciphers, or largestate sponge functions. For instance, if the associated data is empty, no additional permutation calls are necessary. Ascon ’s small rate of 8 or 16 bytes is ideally suited for short messages that are typical for lightweight applications.
Features for HighPerformance Applications

Efficiency on modern CPUs The bitsliced design of Ascon using simple instructions makes it easy to implement efficiently on a wide range of platforms. The native wordsize of Ascon is 64 bits, which makes it especially efficient on highend CPUs. Up to five instructions can be carried out in parallel in nearly every step of the permutation which makes Ascon fast in software on 64bit as well as 32bit CPUs. Further insights about the performance in software on various platforms are given in Sect. 7.

Efficiency on dedicated hardware The linear and nonlinear layer in Ascon are designed to use a small number of simple bitwise Boolean functions. Hence, it is easy to build dedicated hardware or reuse SIMD instructions for Ascon.

Natural sidechannel protection Ascon is a bitsliced design with a small state size, which means that straightforward software implementations require no datadependent table lookups or other cache accesses. On many platforms, all data can be kept in registers during computations. This is for instance important in cloud applications to prevent crossVM attacks and other cachebased attacks.
Design Rationale
The main goal of the Ascon suite is a very low memory footprint in hardware and software, while still being fast, robust, and secure with a wellanalyzed and generous security margin. The design rationale behind Ascon is to provide the best tradeoff between security, size and speed in both software and hardware, with a focus on size.
The Ascon suite is based on the sponge design methodology [14]. The permutation of Ascon uses an iterated substitutionpermutationnetwork (SPN), which provides good cryptographic properties and fast diffusion at a low cost. To provide these properties, the main components of Ascon are inspired from standardized and wellanalyzed primitives. The substitution layer uses an affine equivalent of the Sbox used in the \(\chi \) mapping of Keccak [19, 27] designed to add diffusion. The permutation layer uses linear functions similar to the \(\Sigma \) functions used in SHA2. The resulting design has itself been thoroughly analyzed during the CAESAR competition, and the published results show a comfortable security margin. Details on the design principles for each component are given in the following sections.
Design of the Modes
Choice of the Mode for Authenticated Encryption The design principles of Ascon ’s authenticated encryption mode follow the sponge methodology [14]. More precisely, they are similar to SpongeWrap [17] and MonkeyDuplex [20]. The spongebased design has several advantages compared to other available construction methods like some blockcipher or hashbased modes and other dedicated designs:

The sponge construction is wellstudied and has been analyzed and proven secure for different applications in a large number of publications. Moreover, the sponge construction is used in the SHA3 winner Keccak.

Flexible to adapt for other functionality (hash, MAC, cipher).

Elegant and simple design, clear state size, no key schedule.

Plaintext and ciphertext blocks can both be computed online, without waiting for the complete message or even the message length.

Little implementation overhead for decryption, which uses the same permutations as encryption.

Weak round transformations can be used to process additional plaintext blocks, improving the performance for long messages.
Compared to other spongebased authenticated encryption designs, Ascon uses a stronger keyed initialization and keyed finalization phase. As a result, even in case an attacker somehow manages to recover the internal state during data processing (e.g., due to sidechannel attacks), this does not directly lead to the recovery of the secret key or forgeries without significant additional computations. To allow this additional robustness, Ascon has to set the possibility of full state absorption aside. However, we value robustness for lightweight usecases more than a potential increase in performance.
The addition of \(0^{319}{\Vert }1\) after the last processed associated data block and the first plaintext block acts as a domain separation to prevent attacks that change the role of plaintext and associated data blocks.
If no associated data and only an incomplete plaintext block is present, the two initialization and finalization calls to \(p^a\) are sufficient and no additional intermediate round transformation \(p^b\) is needed. To prevent that key additions between the two applications of \(p^a\) cancel each other out in this case, they are added to different parts of the inner part \(S_c\) of the state.
Choice of the Mode for Hashing and Extendable Output Function As Ascon128 and Ascon128a are already wellestablished as the primary recommendations for lightweight usecases in the final portfolio of the CAESAR competition, we extend the functionality that can be provided by using the same wellanalyzed permutation. It is a natural decision to also base the hashing and extendable output functionality on sponge functions [14]. For hashing, sponge functions provide similar benefits as for authenticated encryption:

The sponge construction is wellstudied and has been analyzed and proven secure for different applications in a large number of publications. Moreover, the sponge construction is used in the SHA3 winner Keccak.

The core component (permutation) can be reused if Ascon for authenticated encryption is already implemented, reducing the implementation overhead.

The elegant and simple design has an obvious state size.

The construction is flexible to adapt for other functionalities (authenticated encryption, MAC, cipher).

Message blocks can be processed online, without waiting for the complete message or even the message length initially be present.
Choice of the Family Members The Ascon suite is built around the wellanalyzed authenticated encryption schemes Ascon128 and Ascon128a. The newly added schemes Ascon80pq, AsconHash, and AsconXof are designed to provide the same security level as Ascon128 and Ascon128a, which is 128 bits of security against attacks in the classical setting (e.g., no quantum computers are available), as detailed in Sect. 3.
The rationale behind this is that 128 bits of security against classical attacks is generally considered to provide enough security for lightweight applications for the next decades. Furthermore, choosing and providing instances that give more security against classical attacks would require more resources without providing any benefit in the foreseeable future, which contradicts the use of lightweight ciphers in the first place. In the following, we still justify our decision in providing three different instances Ascon128, Ascon128a, and Ascon80pq for authenticated encryption with the same security level.
Ascon128 and Ascon128a provide the same level of security in a blackbox scenario if the nonce is used correctly, but there is a tradeoff regarding performance and robustness. Ascon128a doubles the rate compared to Ascon128, at the cost of slightly more rounds in \(p^b\). This decreases the capacity, which also reduces the robustness of the scheme. For example, if an attacker manages to recover a single internal state during the processing of associated data or plaintext/ciphertext, the decreased capacity of Ascon128a leads to a slight benefit in finding collisions to compute forgeries (complexity \(2^{96}\) vs. \(2^{128}\)). Note that a single state recovery still does not directly lead to an efficient key recovery attack on the scheme.
AsconHash and AsconXof reuse the 12round variant of the Ascon permutation from the initialization and finalisation of Ascon128 and Ascon128a. Pairing this wellscrutinized building block with the extensively analyzed and researched sponge construction [14, 15] provides a wellsecured and efficient hash function. We have also defined an extendable output function AsconXof in addition to the fixedsize hash function AsconHash, since the sponge construction naturally allows this functionality and it may be more useful in practice.
A message authentication code (MAC) can be constructed from AsconHash in a straightforward way using the KMAC construction [73]. However, using the sponge construction, a full state absorption is also possible [43], which can improve the efficiency of an Asconbased MAC significantly.
Choice of the Initial Values The main purpose of the initial values is to provide a separation of the different instances. For all schemes of the Ascon suite, the IV is added to the first word and encodes parameters of the scheme such as the key length, rate, number of rounds, or hash output length. The IV provides a separation between the different primitives. In the case of AsconHash and AsconXof, the first call on the permutation including the IV is done without any data and hence, an equivalent initial state can be precomputed, stored and used instead.
Design of the Permutation
Ascon ’s permutation consists of three layers: the round constant addition \(p_C\), the substitution layer \(p_S\), and the linear layer \(p_L\). The substitution layer provides nonlinearity and additionally doubles as a diffusion layer along the vertical axis, between words. The linear layer then provides diffusion along the horizontal axis, within words. In the following, we detail the rationale for these individual layers.
Choice of the Round Constants The round constants have been chosen large enough to avoid slide, rotational, selfsimilarity or similar attacks. Their values were chosen in a simple, obvious way (increasing and decreasing counter for the two halves of the affected byte), which makes them easy to compute using a simple counter and inversion operation. Their low entropy is an indicator that the constants are not used to implement backdoors. The pattern can also easily be extended for up to 16 rounds if a higher security margin is desired.
The position for inserting the round constants (in word \(x_2\)) was chosen so as to allow pipelining with the next or previous few operations (message injection in the first round or the following instructions of the bitsliced Sbox implementation).
Choice of the Substitution and Vertical Diffusion Layer The substitution layer contains the only nonlinear part of the round transformation. It mixes a sequence of 5 bits, each at the same bit position of the five state words, using 5bit Sboxes. The Sbox was designed according to the following criteria:

Invertible and no fixpoints,

Efficient bitsliced implementation with few, well pipelinable instructions,

Each output bit depends on at least 4 input bits,

Algebraic degree 2 to facilitate threshold implementations and masking,

Maximum differential probability and linear bias 1/4,

Differential and linear branch number 3,

Avoid trivially iterable differential properties in the data injection positions.
The \(\chi \) mapping of Keccak fulfills several of these properties and is already wellanalyzed. In addition, the \(\chi \) mapping is highly parallelizable and has a compact description with relatively few instructions. This makes \(\chi \) fast in both software and hardware. The drawback of \(\chi \) in this context are its differential and linear branch numbers (both 2), a fixpoint at value zero, and that each output bit only depends on 3 input bits (only two of them nonlinearly).
For a better interaction with the linear layer of Ascon and a better tradeoff between performance and security, we require a branch number of 3. This and the other additional requirements can be achieved without destroying other properties by adding lightweight affine transformations to the input and output of \(\chi \). Adding this affine transformation to the substitution layer (mixes columns) instead of the linear layer (mixes rows) results in a simpler design which also facilitates the analysis of Ascon.
The costs of these affine transformations are quickly amortized since a branch number of 3 (together with an according linear layer) essentially doubles the number of active Sboxes from round to round (in sparse trails). There are only a handful of options for a lightweight transformation (few xor operations) that achieve both required branch numbers. We experimentally selected the candidate that provided the best diffusion in combination with the selected linear layer.
The bitsliced design of the Sbox has several benefits: it is highly efficient to implement parallel invocations on 64bit processors (and other architectures), and no lookup tables are necessary. This effectively precludes typical cachetiming attacks for software implementations.
The algebraic degree of 2 theoretically makes the Sbox more prone to analysis with algebraic attacks. However, we did not find any practical attacks. We consider it more important to allow efficient implementation of sidechannel countermeasures, such as threshold implementation [75] and masking [25, 54], which are facilitated by the low degree.
The differential and linear probabilities of the Sbox are not ideal, but using one of the available 5bit AB/APN functions like in Fides [8] was not an option due to their much more costly bitsliced implementation. Considering the relatively lightweight linear layer, repeating more rounds of the cheaper, reasonably good Sbox is more effective than fewer rounds of a perfect, but very expensive Sbox.
Choice of the Horizontal Linear Diffusion Layer The linear diffusion layer mixes the bits within each 64bit state word. For resistance against linear and differential cryptanalysis, we required a branch number of at least 3. Additionally, the interaction between the linear layers for separate words should provide very good diffusion, so different linear functions are necessary for the 5 different words. These requirements should be achieved at a minimal cost. Although simple rotations are almost for free in hardware and relatively cheap in software, the slow diffusion requires a very large number of rounds. Moreover, the best performance can be achieved by balancing the costs of the substitution and linear layer.
On the other hand, mixing layers as used in AESbased designs provide a high branch number, but are too expensive to provide an acceptable speed at a small size. The mixing layer of Keccak is best used with a large number of large words. Other possible candidates are the linear layers of Luffa [44], Hamsi [65], or other SPNbased designs. However, these candidates were either too slow or provide a less optimal diffusion.
The linear diffusion layer and rotation values in Ascon have been chosen similar to the \(\Sigma \) functions in SHA2 [71, 72]. These functions offer a branch number of 4. Additionally, if we choose one rotation constant of each \(\Sigma \) function to be zero, the performance can be improved while the branch number stays the same. On the other hand, the cryptographic strength can be improved by using different rotation constants for each 64bit word without sacrifice on the performance. In this case, the branch number of the substitution and linear layer amplify each other which increases the minimum number of active Sboxes. We have chosen the rotation constants to achieve a good diffusion after 3 rounds of Ascon.
Security Analysis
The Ascon authenticated cipher with its permutations \(p^a, p^b\) was first published as a submission to the CAESAR competition in 2014. Since then, the cryptographic research community has published numerous analyses of Ascon ’s design. The results have confirmed Ascon ’s security with a generous security margin. We provide a summary of the best results in Sect. 6.1. For a list of publications and comments, we refer to Sect. 6.4. In Sect. 6.2, we discuss the security of the modes of operation for authenticated encryption and hashing. In Sect. 6.3, we provide details on the cryptanalytic properties of the Ascon permutation and their relevance for attacks.
Overview of Best Known Attacks
Table 10 summarizes the best published attacks on the Ascon permutation as well as on the Ascon authenticated encryption, AsconHash, and AsconXof. As stated in the original design document, Ascon ’s permutations are not considered to be ideal 320bit permutations. However, when used in the recommended modes of operation, Ascon retains a generous security margin. The currently best cryptanalytic attacks on the Ascon authenticated encryption (excluding misuse scenarios) can recover the secret key with a time complexity of about \(2^{104}\) only if the initialization is reduced to 7 of 12 rounds, which corresponds to a security margin of 5 rounds or 42%.
Analysis of the Modes
Hashing and Extendable Output Function The mode of operation in AsconHash and AsconXof uses the sponge construction proposed by Bertoni et al. [14] and profits from the extensive literature on sponge functions, particularly the results on its indifferentiability up to about \(2^{c/2}\) calls to the permutation or its inverse, where c is the capacity in bits [15].
Authenticated Encryption The mode of operation in Ascon is based on the duplex construction [17], or more specifically, a variant of the AEAD mode MonkeyDuplex with its reduced number of rounds in the data processing phases [20]. In contrast to MonkeyDuplex, however, Ascon ’s mode uses a doublekeyed initialization and doublekeyed finalization in order to improve the robustness of the scheme.
AEAD modes using the duplex construction have also enjoyed considerable attention from the research community, and several security proofs with different bounds have been provided. The first proofs indicate that the duplex modes can provide security beyond the birthday bound on the capacity c, as long as the online data complexity remains wellbelow this birthday bound \(2^{c/2}\) [18, 62]. Andreeva et al. [3] show that the time complexity is at least \(\min \{2^k, 2^c/\mu \}\), where \(\mu \) is the multiplicity [16], which is small for noncebased schemes.
Daemen et al. [43] provide stronger bounds based on distinguishing Ascon ’s mode from an Ideal Extendable Input Function (IXIF) and consider a multiuser setting as well as both respecting and misuse adversaries. Their results show that (without considering robustness and the specifics of the permutation) the data limit or key size could be further increased.
The main difference from other duplexbased modes of operation is the doublekeyed initialization and finalization. As a result, even if an attacker manages to recover the internal state in some way (e.g., with implementation attacks such as sidechannels or with misuse attacks such as massive nonce reuse or release of unverified plaintext), this attack cannot easily be extended to key recovery or forgeries without significant additional computations. Possible attacks after such a state recovery include forgeries by finding internal collisions (\(2^{c/2}\) time).
Analysis of the Permutation
Differential and Linear Properties Ascon ’s permutation design is based on two lightweight operations with nonideal individual differential and linear properties, but with good combined properties. The best known characteristics with probability \(> 2^{128}\) cover 4 rounds of the permutation.
DDT and LAT Table 11a lists the differential distribution table (DDT) of the Ascon Sbox. The maximum differential probability of the Sbox is \(2^{2}\) and its differential branch number is 3. Table 11b lists the linear approximation table (LAT). The maximum linear bias of the Sbox is \(2^{2}\) and its linear branch number is 3.
The differential and linear branch number of the linear \(\Sigma _i\) functions is 4.
Characteristics and Active SBoxes The minimum number of active Sboxes of 3 rounds is 15 (for differential characteristics) and 13 (for linear characteristics).
For results on more than 3 rounds, we used heuristic search tools to find good differential and linear characteristics for more rounds to get close to the real bound. The results are listed in Table 12. The best differential and linear characteristics for 4 rounds are given in Table 13a, b, respectively. We could not find any differential and linear characteristics for 5 or more rounds with less than 64 active Sboxes. The best differential and linear characteristics, we could find for 5 rounds already have 78 and 67 active Sboxes, respectively. However, note that due to the larger search space for 5 rounds, we restricted our search to differential and linear trails that are sparse in the middle (rounds 1–3).
Characteristics with Constraints Besides the differential propagation in Ascon, an attacker is in particular interested in collisionproducing differentials, i.e., differentials with only differences in the outer part \(S_r\) of the state at the input and output of \(p^b\), since such differentials might be used for a forgery attack on the authenticated encryption scheme. However, considering the good differential properties of \(p^b\) and the results of the previous sections, it is very unlikely that such differentials with a good probability exist. The best collisionproducing differential trails we could find for \(p^b\) in Ascon128 (Table 14a) and Ascon128a (Table 14b) using a heuristic search algorithm have 117 and 192 active Sboxes, respectively.
For forgery attacks on Ascon ’s finalization, the input difference must be in the outer part, but there are no restrictions on the output difference. A corresponding characteristic for 4 out of 12 rounds is provided in Table 14c [34].
Impossible Differentials and ZeroCorrelation Approximations Using an automated search tool, we were able to find impossible differentials [64] for up to 5 rounds (Table 15a) and zerocorrelation linear hulls [23] for up to 5 rounds (Table 15b) of the permutation. It is possible that impossible differentials for more rounds exist. However, we have not found any practical attacks on Ascon using this property of the permutation.
Other published properties include a differentiallinear attack on up to 5 rounds of Ascon ’s initialization with practical complexity [11, 34] and truncated differential distinguishers based on undisturbed bits for up to 5 rounds with \(2^{109}\) data [89].
Algebraic Properties Ascon ’s algebraic degree of 2 for each round is useful for efficient secure implementations, but requires a sufficient number of rounds to prevent algebraic attacks. The best known algebraic attacks cover 7 out of 12 rounds of Ascon ’s initialization.
Algebraic Normal Form (ANF) Let \(x_{0,i}, \ldots , x_{4,i}\) denote the bits in column i, \(0 \le i < 64\), where \(x_{0,0}\) is the least significant (rightmost) bit of the first register word (outer part) of the state. Let \(y_{0,i}, \ldots , y_{4,i}\) denote the same bit position after application of either the Sbox layer \(p_S\) or the linear layer \(p_L\). The ANF of the Sbox layer \(p_S\) is given by:
The ANF of the linear layer \(p_L\) is as follows, with index computations mod 64:
Algebraic Degree The algebraic degree of the round function p is 2, so the degree after R rounds is upperbounded by \(2^R\). A tighter bound based on the general bounds by Canteaut [9, Theorem 1 with \(\ell =192\) for both \(\mathcal {S}\) and \(\mathcal {S}^{1}\)] and Boura et al. [10, Theorem 2 with \(\gamma =3\) for both \(\mathcal {S}\) and \(\mathcal {S}^{1}\)] is listed in Table 16.
Diffusion Table 17 provides an overview of the diffusion properties of up to 3 rounds of Ascon ’s permutation. After 3 rounds, almost all input bits appear in the ANF of each output bit (Table 17a). Finally, we list the maximum monomial degree for each input bit \(x_{w,0}\) in the ANF after 1 round (Table 17c) and after 2 rounds (Table 17d).
Linearization and Initial Structures Distinguishers based on the degree can be combined with different initial structures that linearize the first few rounds in order to create a vector space or linear intermediate ANF with respect to the selected input variables. Besides generic structures (e.g., 0, 1, or 5 cube variables at each Sbox input), several structures using the specific properties of Ascon ’s Sbox have been proposed [34, 67]. For example, input bits \(x_{2,i}\) are multiplied with neither \(x_{0,i}\) nor \(x_{4,i}\) in the first round.
By imposing bit conditions on certain input bits (corresponding to the key in Ascon), it is possible to find sufficiently large cubes such that no cube variables multiply after 1 round and one specific cube variable does not multiply with any others after 2 rounds [67]. An alternative approach suggested by Li et al. [67] does allow quadratic monomials after 1 round, but ensures that they are not multiplied with any other monomials after 2 rounds.
ZeroSum and Cube Attacks The low degree of the Sbox permits insideout zerosum distinguishers on the permutations \(p^a\) and \(p^b\), so they can not be considered as perfect random permutations. The full 12round permutation can be distinguished with \(2^{130}\) data [34] (4 inverse rounds, free middle round, and 7 forward rounds, see Table 16), or 11 rounds with complexity \(2^{85}\) below the security bound (\(4 + 1 + 6\) rounds, with the data complexity a multiple of the Sbox size 5 for the free inner round). However, we are not aware of attacks able to exploit these properties for attacks on the authenticated cipher or hash function.
For keyrecovery attacks in a noncerespecting setting, cube variables can be positioned in the nonce and cubelike attacks can exploit that the cube sum after the roundreduced initialization only depends on selected key bits [34]. Using conditional initial structures of dimension 65 that ensure degree 2 after 2 rounds and thus degree at most 64 after 7 rounds, Li et al. [67] propose conditional cube attacks on 7 of 12 rounds of Ascon ’s initialization.
In a similar spirit to initial structures, it is also possible to linearize a few rounds of Ascon ’s permutation in order to find preimages for heavily roundreduced versions of AsconXof as shown in [37]. Apart from that, an upper bound on the degree of the roundreduced Ascon permutation can be used to marginally speedup a bruteforce search for preimages as suggested by Bernstein [21]. For instance, it is possible to find a preimage for a version of AsconXof where the number of rounds is reduced to 6 out of 12 and the output is truncated to 64 bits with a complexity of \(2^{63.3}\) [37].
Other Properties Besides linear, differential, and algebraic properties, other relevant cryptographic properties exist. We discuss some of them next.
Integral Distinguishers and Division Property Based on the division property, Todo [91] proposes integral distinguishers for the Ascon permutation, where up to 7 rounds can be evaluated using less than \(2^{128}\) data (Table 18b).
Göloğlu et al. [58] list the division properties of Ascon ’s Sbox \(\mathcal {S}\) and conclude that these values are optimal with respect to the degree (Table 18a).
Subspace Trails Leander et al. [69] analyze the existence of subspace trails. For Ascon ’s permutation, they show that the longest subspace trails using 1linear structures cover 3 rounds (dimension 298) or 1 inverse round (dimension 125).
SAT Solvers Dwivedi et al. [42] use SAT solvers for a state recovery attack on 2 (out of 8) rounds of the data processing phase of Ascon128a.
List of Published Analysis
As the primary recommendation for lightweight authenticated encryption in the final portfolio of the CAESAR competition [87], Ascon has received a lot of attention and several results regarding its security have been published. All the results published so far support the security of Ascon and its underlying permutation. In other words, no security vulnerabilities have been shown so far and the best attacks target the initialization of Ascon reduced to 7 (out of 12) rounds, concluding that Ascon has a security margin of 5 rounds (\(42\%\) of the 12 rounds).
The following list contains both results evaluating the permutation and evaluation of the security of Ascon ’s authenticated encryption, either using variants of Ascon ’s permutation, or idealized versions of it.

Detailed analysis of Ascon ’s differentiallinear properties [11].

Improved 4round differentiallinear analysis and subspace trails [90].

Integral distinguishers for the roundreduced inverse Ascon [94].

Subspace trails for a small number of rounds for Ascon ’s permutation [69].

Evaluation of the security of Ascon in misuse settings [92].

Cubelike keyrecovery attack on 7 (out of 12) rounds of the initialization of Ascon in \(2^{103.9}\) time [67].

Cubelike attacks in a noncemisuse setting on roundreduced Ascon [70].

SATbased state recovery on 2 (out of 8) rounds of the data processing of Ascon128a [42].

Evaluating the properties of Ascon ’s authenticated encyption mode regarding reforgeability [48].

Truncated, impossible, and improbable differential distinguishers for 4 and 5 rounds of Ascon ’s permutation. Differential distinguishers based on undisturbed bits for to 5 rounds reduced variants of Ascon with \(2^{109}\) data [89].

Security of Ascon ’s Sbox with respect to the division property [58].

Several linear characteristic for Ascon ’s permutation [31].

Ascon ’s authenticated encryption mode supports secure implementations on limitedmemory devices [2].

Evaluation of Ascon ’s permutation using the division property [91].

Suggestions to absorb authenticated data more efficiently [86].

Evaluation of the resistance of Ascon ’s permutation against algebraic, differential, linear, and differentiallinear attacks. Cubelike and differentiallinear key recovery attacks on roundreduced variants of Ascon. Differentialbased forgery attacks on roundreduced Ascon [34].

Security proof for Ascon ’s authenticated encryption mode even for higher rates [62].

Security analysis and bounds for the fullstate keyed duplex with application to Ascon128 and Ascon128a [43].

Discussing security and leakageresilience of Ascon’s mode of operation [55].
Implementation
Since Ascon is based on the sponge and duplex constructions, it just relies on the evaluation of cryptographic permutations in forward direction to allow hashing and authenticated encryption. In particular, there is no need to implement the inverse of the permutation, or other often used components in authenticated encryption schemes like a key schedule, masks, Galois field multiplications, etc. This together with the small state size of 320 bits minimizes the code size and register pressure in software and the area requirements in hardware. Still, the state size of 320 bits is large enough to provide both hashing and authenticated encryption with 128 bits of security.
Software Implementations A preliminary overview of the software performance of Ascon128 and Ascon128a is given in Table 19a, b. Detailed software performance results and comparisons for a large number of platforms are given in eBACS, the ECRYPT Benchmarking of Cryptographic Systems [45]. Additional software benchmarking results for micro controllers (including size and runtime) of lightweight authenticated encryption schemes submitted to NIST are maintained at [76]. The software performance of AsconHash and AsconXof is largely the same as for Ascon128 with doubled cycles per byte.
Hardware Implementations Detailed hardware performance results and comparisons for a large number of implementations are given in the Athena project [5]. A preliminary overview of the hardware performance of Ascon128 and Ascon128a for different use cases is given in Table 20a, b. Note that the CAESAR API implies a certain overhead, in particular for lightweight designs like Ascon. However, this cost can be significantly reduced by using a dedicated lightweight interface as shown in [59].
Efficiency for Short Messages
The simplicity of the design and the small state play also a crucial role in the efficiency of Ascon ’s authenticated encryption for small messages. For instance, if no associated data is present, Ascon128 can encrypt plaintexts strictly smaller than 8 bytes and Ascon128a can encrypt plaintexts strictly smaller than 16 bytes with just two calls to the permutation \(p^a\). Preliminary software performance results for several short messages and platforms are also shown in Table 19a, b.
Ankele and Ankele [1] give a detailed performance overview of the second round CAESAR candidates for short messages. In many scenarious (e.g., SSH with 5 bytes of associated data and 1 byte of plaintext), Ascon128a is able to perform very well, even when compared to AESbased designs which use native AES instructions on Intel Skylake processors [1, Figure 6].
Flexibility of the Permutation
The permutation of Ascon is naturally defined on 64bit words using only bitwise Boolean functions (and, not, xor) and rotations within these 64bit words. As a consequence, Ascon does not require any datadependent table lookups. Hence, it lends itself to bitsliced implementations in software as well as simple and clean hardware implementations.
Instruction Parallelism The Sbox and the linear layer provide some flexibility regarding the number of instructions that can be carried out in parallel and additional temporary registers that are needed to store intermediate computations in software implementations. A bitsliced implementation of the Sbox that focuses on instruction parallelism is shown in Fig. 5. Considering that the linear layer is defined separately on each of the 5 64bit words, up to 5 instructions can be carried out in parallel in nearly every phase of the permutation. This implementation aspect of Ascon allows for short critical paths in hardware and makes use of the outoforder execution capabilities of highend processors.
Bit Interleaving However, Ascon can also be implemented on systems that do not have a natural 64bit datapath, like 8, 16, and 32bit processors. This can be done by employing a technique called bit interleaving as described in the Keccak implementation overview [13]. By using this technique, the single bits of one of Ascon ’s 64bit words are stored interleaved in two 32bit, four 16bit, or eight 8bit registers. This technique allows to translate rotations within the 64bit words to rotations (and relabeling) of the smaller registers. Since the other operations of Ascon are bitwise Boolean functions, they are unaffected by the changed representations.
That bit interleaving is a very viable strategy can be seen in the work of Bangma [6], where the performance of Ascon128 is compared with implementations of the CAESAR finalists ACORN, AEGIS128L, DeoxysII128, and MORUS1280128 on an ARM CortexA8. Here, Ascon128 is the fastest cipher for short plaintexts of 64 bytes [6, Table 5.1].
Reducing Register Pressure To reduce register pressure on resource constrained devices, the Sbox of Ascon can also be implemented using just two temporary registers as shown in Fig. 6. This low register implementation was inspired by [26, 41] and later extended to protect the masked Ascon Sbox against SIFA in [30]. In particular, masked implementations benefit from this low register usage since the number of registers increase linearly with the masking order. Additionally, the resulting implementation of the Sbox is uniform (a requirement for threshold implementations [75]) even without the need for additional online random input data [30].
Further Reading on Efficiency
Benchmarking Efforts Several teams are working on benchmarking efforts where updates are expected throughout the NIST lightweight cryptography project. Similarly, the CAESAR competition has inspired several such efforts. Benchmarking initiatives with online resources include the following:

Athena: Hardware evaluation and CAESAR HW API [5, 61, 88, 93] https://cryptography.gmu.edu/athena/index.php?id=LWC

eBACS: ECRYPT Benchmarking of Cryptographic Systems [45] http://bench.cr.yp.to

LaS\(^3\): NIST LWC software performance benchmarks on microcontrollers [81] https://lwc.las3.de

Rhys Weatherly: Software benchmarking for 32bit embedded architectures https://rweather.github.io/lightweightcrypto/index.html

Ralph&Robin Ankele: Software benchmarking of \(2^{\mathrm{nd}}\) round CAESAR candidates [1] https://github.com/TheBananaMan/caesar_benchmarks_secondround

BRUTUS: Testing CAESAR authenticated encryption candidates for weaknesses [82] https://github.com/mjosaarinen/brutus
Hardware implementations are reported by [40, 46, 47, 63, 80, 84, 88, 93].
Software implementations are reported by [6, 38, 39, 66, 85].
Implementation Security and Robustness
Ascon ’s permutation uses Sboxes of degree 2 and thus lends itself to efficient countermeasures against sidechannel attacks by masking with a low overhead. The lowregister implementation of the Ascon Sbox given in Fig. 6 can be extended to any masking order as shown in [30]. Using this approach, only two additional temporary registers are needed for each share and no additional randomness is needed to get a uniform implementation of the Ascon Sbox. As a result, masked software implementations of Ascon result in a performance penalty with low overhead.
Additionally, leveled implementations of Ascon are possible to improve the robustness and/or security of the design [4, 7]. Examples are sidechannel protected implementations with different strength of the key XORs, \(p^a\) and/or \(p^b\). Also, the plaintext leakages can be reduced by limiting the number of decryption failures.
Many protected hardware implementations of Ascon have been published already. Gross et al. [59] provide threshold implementations of Ascon128 as small as 7.97 kGE. Additionally, many other stateoftheart masking approaches have been applied on Ascon, like UMA [51] and DOM [53], even for high protection order (see Table 21). Links to various implementations of Ascon, including DOM and UMA implementations, can be found on the Ascon website^{Footnote 1}.
Next, we give a list of papers that either evaluate the sidechannel and fault resistance of Ascon or elaborate protection mechanisms against sidechannel and fault attacks [4, 7, 12, 28,29,30, 50, 51, 55, 60, 68, 77,78,79, 83].
Conclusion
Ascon128 and Ascon128a have been shown to be robust authenticated encryption schemes with a comfortable security margin that can be implemented efficiently on a wide range of platforms including hardware and software. In addition, their design allows for the addition of countermesures against implementation attacks, most notably sidechannel attacks, at a rather low overhead.
Based on the wellanalyzed permutation underlying Ascon128 and Ascon128a, we have specified AsconHash and AsconXof to enhance the functionality of the Ascon cipher suite. Thus, implementing Ascon ’s permutation allows to realize authenticated encryption and hashing without the need of additional cryptographic primitives. The whole package has been submitted to the NIST lightweight cryptography standardization process.
Notes
References
 1.
R. Ankele, R. Ankele, Software benchmarking of the 2nd round CAESAR candidates (IACR, 2016). https://ia.cr/2016/740
 2.
M. Agrawal, D. Chang, S. Sanadhya, spAELM: sponge based authenticated encryption scheme for memory constrained devices, in ACISP 2015. LNCS, vol. 9144 (Springer, 2015), pp. 451–468. https://doi.org/10.1007/978331919962726
 3.
E. Andreeva, J. Daemen, B. Mennink, G. Van Assche, Security of keyed sponge constructions using a modular proof approach, in FSE 2015. LNCS, vol. 9054 (Springer, 2015), pp. 364–384. https://doi.org/10.1007/978366248116518
 4.
A. Adomnicai, J.J.A. Fournier, L. Masson, Masking the lightweight authenticated ciphers ACORN and ascon in software (IACR, 2018). https://ia.cr/2018/708
 5.
Athena project, Automated tool for hardware evaluation—CAESAR hardware API (2016). https://cryptography.gmu.edu/athena/index.php?id=CAESAR_source_codes
 6.
N. Bangma, Ascon: an attempt in NEON on the CortexA8. Bachelor’s Thesis (2018). https://www.cs.ru.nl/bachelorscripties/2018/Noel_Bangma___4433939___Ascon_An_attempt_in_NEON_on_the_CortexA8.pdf
 7.
D. Bellizia, O. Bronchain, G. Cassiers, V. Grosso, C. Guo, C. Momin, O. Pereira, T. Peters, F.X. Standaert, Modelevel vs. implementationlevel physical security in symmetric cryptography—a practical guide through the leakageresistance jungle, in CRYPTO 2020. LNCS, vol. 12170 (Springer, 2020), pp. 369–400. https://doi.org/10.1007/978303056784213
 8.
B. Bilgin, A. Bogdanov, M. Knezevic, F. Mendel, Q. Wang, Fides: lightweight authenticated cipher with sidechannel resistance for constrained hardware, in CHES 2013. LNCS, vol. 8086 (Springer, 2013), pp. 142–158. https://doi.org/10.1007/97836424034919. IACR https://ia.cr/2015/424
 9.
C. Boura, A. Canteaut, A zerosum property for the Keccak\(f\) permutation with 18 Rounds, in ISIT 2010 (IEEE, 2010), pp. 2488–2492. https://doi.org/10.1109/ISIT.2010.5513442
 10.
C. Boura, A. Canteaut, C. De Cannière, Higherorder differential properties of Keccak and Luffa, in FSE 2011. LNCS, vol. 6733 (Springer, 2011), pp. 252–269. https://doi.org/10.1007/978364213858415. IACR https://ia.cr/2010/589
 11.
A. BarOn, O. Dunkelman, N. Keller, A. Weizman, DLCT: a new tool for differentiallinear cryptanalysis, in EUROCRYPT 2019. LNCS, vol. 11476 (Springer, 2019), pp. 313–342. https://doi.org/10.1007/978303017653211. IACR https://ia.cr/2019/256
 12.
S. Belaïd, P.É. Dagand, D. Mercadier, M. Rivain, R. Wintersdorff, Tornado: automatic generation of probingsecure masked bitsliced implementations, in EUROCRYPT 2020. LNCS, vol. 12107 (Springer, 2020), pp. 311–341. https://doi.org/10.1007/978303045727311
 13.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, R. Van Keer, Keccak implementation overview version 3.2 (2012). https://keccak.team
 14.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, Sponge functions, in Ecrypt Hash Workshop 2007 (2007). https://keccak.team/files/SpongeFunctions.pdf
 15.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, On the Indifferentiability of the Sponge Construction, in EUROCRYPT 2008. LNCS, vol. 4965 (Springer, 2008), pp. 181–197. https://doi.org/10.1007/978354078967311. https://keccak.team/files/SpongeIndifferentiability.pdf
 16.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, Spongebased pseudorandom number generators, in CHES 2010. LNCS, vol. 6225 (Springer, 2010), pp. 33–47. https://doi.org/10.1007/97836421503193. https://keccak.team/files/SpongePRNG.pdf
 17.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, Duplexing the sponge: singlepass authenticated encryption and other applications, in SAC 2011. LNCS, vol. 7118 (Springer, 2011), pp. 320–337. https://doi.org/10.1007/978364228496019. IACR https://ia.cr/2011/499
 18.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, On the security of the keyed sponge construction, in SKEW 2011 (2011). https://keccak.team/files/SpongeKeyed.pdf
 19.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, The Keccak reference. Submission to NIST (Round 3) (2011). https://keccak.team
 20.
G. Bertoni, J. Daemen, M. Peeters, G. Van Assche, Permutationbased encryption, authentication and authenticated encryption, in DIAC 2012, July 2012 (2012)
 21.
D. J. Bernstein, Second preimages for 6 (7 (8??)) rounds of Keccak? Posted on the NIST mailing list (2010). https://ehash.iaik.tugraz.at/uploads/6/65/NISTmailinglist_BernsteinDaemen.txt
 22.
G. Brassard, P. Høyer, A. Tapp, Quantum cryptanalysis of hash and clawfree functions, in LATIN ’98. LNCS, vol. 1380 (Springer, 1998), pp. 163–169. https://doi.org/10.1007/BFb0054319
 23.
A. Bogdanov, V. Rijmen, Linear hulls with correlation zero and linear cryptanalysis of block ciphers. Des. Codes Cryptogr. 70(3), 369–383 (2014). https://doi.org/10.1007/s106230129697z
 24.
J. Czajkowski, L.G. Bruinderink, A. Hülsing, C. Schaffner, D. Unruh, Postquantum security of the sponge construction, in PQCrypto 2018. LNCS, vol. 10786 (Springer, 2018), pp. 185–204. https://doi.org/10.1007/97833197906339
 25.
S. Chari, C. S. Jutla, J. R. Rao, P. Rohatgi, Towards sound approaches to counteract poweranalysis attacks, in CRYPTO ’99. LNCS, vol. 1666 (Springer, 1999), pp. 398–412. https://doi.org/10.1007/3540484051
 26.
J. Daemen, Personal communication about implementing the 3bit c layer. Dec. 2018 (2018)
 27.
J. Daemen, Cipher and hash function design. Strategies based on linear and differential cryptanalysis. PhD thesis (Katholieke Universiteit Leuven, 1995). https://www.esat.kuleuven.be/cosic/publications/thesis6.pdf
 28.
L. De Meyer, Looking at the NIST lightweight candidates from a masking pointofview. IACR Cryptology ePrint Archive, Report 2020/699 (2020). IACR https://ia.cr/2020/699
 29.
W. Diehl, A. Abdulgadir, F. Farahmand, J.P. Kaps, K. Gaj, Comparison of cost of protection against differential power analysis of selected authenticated ciphers, in HOST 2018 (IEEE Computer Society, 2018), pp. 147–152. https://doi.org/10.1109/HST.2018.8383904
 30.
J. Daemen, C. Dobraunig, M. Eichlseder, H. Gross, F. Mendel, R. Primas, Protecting against Statistical Ineffective Fault Attacks”. In: IACR Transactions on Cryptographic Hardware and Embedded Systems 2020.3 (2020), pp. 508–543. https://doi.org/10.13154/tches.v2020.i3.508543. IACR https://ia.cr/2019/536
 31.
C. Dobraunig, M. Eichlseder, F. Mendel, Heuristic tool for linear cryptanalysis with applications to CAESAR candidates, in ASIACRYPT 2015. LNCS, vol. 9453 (Springer, 2015), pp. 490–509. https://doi.org/10.1007/978366248800320. IACR https://ia.cr/2015/1200
 32.
C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Ascon v1. Submission to the CAESAR competition (2014). https://ascon.iaik.tugraz.at
 33.
C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Ascon v1.1. Submission to Round 2 of the CAESAR competition (2015). https://ascon.iaik.tugraz.at
 34.
C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Cryptanalysis of Ascon, in CTRSA 2015. LNCS, vol. 9048 (Springer, 2015), pp. 371–387. https://doi.org/10.1007/978331916715220. IACR https://ia.cr/2015/030
 35.
C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Ascon v1.2. Submission to Round 3 of the CAESAR competition (2016). https://ascon.iaik.tugraz.at
 36.
C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Ascon v1.2. Submission to NIST (2019). https://ascon.iaik.tugraz.at
 37.
C. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer, Preliminary analysis of AsconXof and AsconHash. Technical Report (2019). https://ascon.iaik.tugraz.at
 38.
L.C. dos Santos, Software implementation of authenticated encryptionalgorithms on ARM processors. Master’s Thesis (2018). http://repositorio.unicamp.br/jspui/bitstream/REPOSIP/332624/1/Santos_LuanCardosoDos_M.pdf
 39.
L.C. dos Santos, J. Großschädl, A. Biryukov, FELICSAEAD: benchmarking of lightweight authenticated encryption algorithms, in CARDIS 2019. LNCS, vol. 11833 (Springer, 2019), pp. 216–233. https://doi.org/10.1007/978303042068013
 40.
W. Diehl, K. Gaj, RTL implementations and FPGA benchmarking of selected CAESAR Round Two authenticated ciphers. Microprocess. Microsyst. 52, 202–218 (2017). https://doi.org/10.1016/j.micpro.2017.06.003
 41.
J. Daemen, S. Hoffert, G. Van Assche, R. Van Keer, The design of Xoodoo and Xoofff. IACR Trans. Symmetric Cryptol. 2018(4), 1–38 (2018). https://doi.org/10.13154/tosc.v2018.i4. IACR https://ia.cr/2018/767
 42.
A.D. Dwivedi, M. Kloucek, P. Morawiecki, I. Nikolic, J. Pieprzyk, S. Wójtowicz, SATbased cryptanalysis of authenticated ciphers from the CAESAR competition, in SECRYPT ICETE 2017 (SciTePress, 2017), pp. 237–246. https://doi.org/10.5220/0006387302370246. IACR https://ia.cr/2016/1053
 43.
J. Daemen, B. Mennink, G. Van Assche, Fullstate keyed duplex with builtin multiuser support. In: ASIACRYPT 2017. LNCS, vol. 10625 (Springer, 2017), pp. 606–637. https://doi.org/10.1007/978331970697921. IACR https://ia.cr/2017/498
 44.
C. De Cannière, H. Sato, D. Watanabe, Hash function luffa: specification. Submission to NIST (Round 2) (2009). https://www.hitachi.com/rd/yrl/crypto/luffa/
 45.
eBACS: ECRYPT benchmarking of cryptographic systems. https://bench.cr.yp.to (visited on 02/14/2019)
 46.
F. Farahmand, W. Diehl, A. Abdulgadir, J.P. Kaps, K. Gaj, Improved lightweight implementations of CAESAR authenticated ciphers, in FCCM 2018 (IEEE Computer Society, 2018), pp. 29–36. https://doi.org/10.1109/FCCM.2018.00014
 47.
M. Fivez, Energy Efficient Hardware Implementations of CAESAR Submissions. Master’s Thesis (2016). https://www.esat.kuleuven.be/cosic/publications/thesis279.pdf
 48.
C. Forler, E. List, S. Lucks, J. Wenzel, Reforgeability of authenticated encryption schemes, in ACISP 2017. LNCS, vol. 10343 (Springer, 2017), pp. 19–37. https://doi.org/10.1007/97833195987032. IACR https://ia.cr/2017/332
 49.
K. Gaj, ATHENa Team, ATHENa: automated tool for hardware evaluation (2016). https://cryptography.gmu.edu/athena/
 50.
H. Gross, R. Iusupov, R. Bloem, Generic lowlatency masking in hardware. IACR Trans. Cryptogr. Hardw. Embed. Syst. 2018(2), 1–21 (2018). https://doi.org/10.13154/tches.v2018.i2.121. IACR https://ia.cr/2017/1223
 51.
H. Gross, S. Mangard, Reconciling d+1 masking in hardware and software, in CHES 2017. LNCS, vol. 10529 (Springer, 2017), pp. 115–136. https://doi.org/10.1007/97833196678746. IACR https://ia.cr/2017/103
 52.
H. Gross, S. Mangard, A unified masking approach. J. Cryptogr. Eng. 8(2), 109–124 (2018). https://doi.org/10.1007/s133890180184y
 53.
H. Groß, S. Mangard, T. Korak, Domainoriented masking: compact masked hardware implementations with arbitrary protection order, in TIS@CCS 2016 (ACM, 2016), p. 3. https://doi.org/10.1145/2996366.2996426. IACR https://ia.cr/2016/486
 54.
L. Goubin, J. Patarin, DES and differential power analysis (the “duplication” method), in CHES ’99. LNCS, vol. 1717 (Springer, 1999), pp. 158–172. https://doi.org/10.1007/3540480595
 55.
C. Guo, O. Pereira, T. Peters, F.X. Standaert, Towards lowenergy leakageresistant authenticated encryption from the duplex sponge construction. IACR Trans. Symmetric Cryptol. 2020(1), 6–42 (2020). https://doi.org/10.13154/tosc.v2020.i1. IACR https://ia.cr/2019/193
 56.
H. Gross, Reference hardware implementations of Ascon128 and Ascon128a using the CAESAR Hardware API v1.0. (2016). https://github.com/IAIK/ascon_hardware/tree/master/caesar_hardware_api_v_1_0_3/ASCON_ASCON
 57.
L. K. Grover, A fast quantum mechanical algorithm for database search, in STOC ’96 (ACM, 1996), pp. 212–219. https://doi.org/10.1145/237814.237866
 58.
F. Göloglu, V. Rijmen, Q. Wang, On the division property of Sboxes. IACR Cryptology ePrint Archive, Report 2016/188 (2016). IACR https://ia.cr/2016/188
 59.
H. Gross, E. Wenger, C. Dobraunig, C. Ehrenhöfer, Suit up!—madetomeasure hardware implementations of Ascon, in DSD 2015 (IEEE Computer Society, 2015), pp. 645–652. https://doi.org/10.1109/DSD.2015.14. IACR https://ia.cr/2015/034
 60.
H. Gross, E. Wenger, C. Dobraunig, C. Ehrenhöfer, Ascon hardware implementations and sidechannel evaluation. Microprocess. Microsyst. 52, 470–479 (2017). https://doi.org/10.1016/j.micpro.2016.10.006
 61.
E. Homsirikamol, W. Diehl, A. Ferozpuri, F. Farahmand, P. Yalla, J.P. Kaps, K. Gaj, CAESAR hardware API. IACR Cryptology ePrint Archive, Report 2016/626 (2016). IACR https://ia.cr/2016/626
 62.
P. Jovanovic, A. Luykx, B. Mennink, Beyond \(2^c/2\) security in spongebased authenticated encryption modes, in ASIACRYPT 2014. LNCS, vol. 8873 (Springer, 2014), pp. 85–104. https://doi.org/10.1007/97836624561185. IACR https://ia.cr/2014/373
 63.
J.P. Kaps, W. Diehl, M. Tempelmeier, F. Farahmand, E. Homsirikamol, K. Gaj, A comprehensive framework for fair and efficient benchmarking of hardware implementations of lightweight cryptography. IACR Cryptology ePrint Archive, Report 2019/1273. 2019. IACR https://ia.cr/2019/1273
 64.
L. Knudsen, DEAL—a 128bit block cipher (1998)
 65.
Ö. Küçük, The hash function Hamsi. Submission to NIST (Round 2) (2009). https://www.esat.kuleuven.be/cosic/publications/article1203.pdf
 66.
R. Kumar Pal, Implementation and evaluation of authenticated encryption algorithms on Java Card Platform (master’s thesis). Master’s Thesis (2017). https://is.muni.cz/th/448415/fi_m/MSThesis_IS.pdf
 67.
Z. Li, X. Dong, X. Wang, Conditional cube attack on roundreduced ASCON. IACR Trans. Symmetric Cryptol. 2017(1), 175–202 (2017). https://doi.org/10.13154/tosc.v2017.i1.175202. IACR: https://ia.cr/2017/160, https://github.com/lizhengcn/Ascon_test
 68.
L. Lerman, O. Markowitch, N. Veshchikov, Comparing Sboxes of ciphers from the perspective of sidechannel attacks, in AsianHOST 2016 (IEEE Computer Society, 2016), pp. 1–6. https://doi.org/10.1109/AsianHOST.2016.7835556. IACR https://ia.cr/2016/993
 69.
G. Leander, C. Tezcan, F. Wiemer, Searching for subspace trails and truncated differentials. IACR Trans. Symmetric Cryptol. 2018(1), 74–100 (2018). https://doi.org/10.13154/tosc.v2018.i1.74100
 70.
Y. Li, G. Zhang, W. Wang, M. Wang, Cryptanalysis of roundreduced ASCON. Sci. China Inf. Sci. 60(3), 38102 (2017). https://doi.org/10.1007/s1143201602833
 71.
National Institute of Standards and Technology, FIPS PUB 1802: secure hash standard. Federal Information Processing Standards Publication 1802, U.S. Department of Commerce (2002)
 72.
National Institute of Standards and Technology, FIPS PUB 1804: Secure hash standard. Federal Information Processing Standards Publication 1804, U.S. Department of Commerce. 2015. https://doi.org/10.6028/NIST.FIPS.1804
 73.
National Institute of Standards and Technology, NIST SP 800185: SHA3 derived functions: cSHAKE, KMAC, TupleHash, ParallelHash. NIST Special Publication 800185, U.S. Department of Commerce (2016). https://doi.org/10.6028/NIST.SP.800185
 74.
National Institute of Standards and Technology. Submission requirements and evaluation criteria for the lightweight cryptography standardization process (2018). https://csrc.nist.gov/CSRC/media/Projects/LightweightCryptography/documents/finallwcsubmissionrequirementsaugust2018.pdf
 75.
S. Nikova, V. Rijmen, M. Schläffer, Secure hardware implementation of nonlinear functions in the presence of glitches. J. Cryptol. 24(2), 292–321 (2011). https://doi.org/10.1007/s0014501090857
 76.
NIST LWC Software Performance Benchmarks on Microcontrollers. https://lwc.las3.de/ (visited on 06/24/2020)
 77.
K. Ramezanpour, P. Ampadu, W. Diehl, A statistical fault analysis methodology for the Ascon authenticated cipher, in HOST 2019 (IEEE, 2019), pp. 41–50. https://doi.org/10.1109/HST.2019.8741029
 78.
K. Ramezanpour, P. Ampadu, W. Diehl, FIMA: fault intensity map analysis, in COSADE 2019. LNCS, vol. 11421 (Springer, 2019), pp. 63–79. https://doi.org/10.1007/97830301635015
 79.
K. Ramezanpour, P. Ampadu, W. Diehl, SCARL: sidechannel analysis with reinforcement learning on the Ascon authenticated cipher. CoRR. arXiv:2006.03995
 80.
B. Rezvani, W. Diehl, Hardware implementations of NIST lightweight cryptographic candidates: a first look. IACR Cryptology ePrint Archive, Report 2019/824 (2019). IACR https://ia.cr/2019/824
 81.
S. Renner, E. Pozzobon, J. Mottok, Benchmarking software implementations of 1st round candidates of the NIST LWC project on MCUs, in NIST Lightweight Cryptography Workshop (2019). https://csrc.nist.gov/Presentations/2019/benchmarkingsoftwareimplementationsof1stround
 82.
M.J.O. Saarinen, The BRUTUS automatic cryptanalytic framework—Testing CAESAR authenticated encryption candidates forweaknesses. J. Cryptogr. Eng. 6(1), 75–82 (2016). https://doi.org/10.1007/s1338901501141
 83.
N. Samwel, J. Daemen, DPAon hardware implementations of Ascon and Keyak, in CF’17 (ACM, 2017), pp. 415–424. https://doi.org/10.1145/3075564.3079067
 84.
N. Samir, A.S. Hussein, M. Khaled, A.N. ElZeiny, M. Osama, H. Yassin, A. Abdelbaky, O. Mahmoud, A. Shawky, H. Mostafa, ASIC and FPGA comparative study for IoT lightweight hardware security algorithms. J. Circuits Syst. Comput. 28(12), 1930009:1–1930009:25 (2019). https://doi.org/10.1142/S0218126619300095
 85.
K. Stoffelen, Optimizing sbox implementations for several criteria using SAT solvers, in FSE 2016. LNCS, vol. 9783 (Springer, 2016), pp. 140–160. https://doi.org/10.1007/97836625299358. IACR https://ia.cr/2016/198
 86.
Y. Sasaki, K. Yasuda, How to incorporate associated data in spongebased authenticated encryption, in CTRSA 2015. LNCS, vol. 9048 (Springer, 2015), pp. 353–370. https://doi.org/10.1007/978331916715219
 87.
The CAESAR committee, CAESAR: competition for authenticated encryption: security, applicability, and robustness (2014). https://competitions.cr.yp.to/caesarsubmissions.html
 88.
M. Tempelmeier, F. De Santis, G. Sigl, J.P. Kaps, The CAESARAPI in the real world—towards a fair evaluation of hardware CAESAR candidates, in HOST 2018 (IEEE Computer Society, 2018), pp. 73–80. https://doi.org/10.1109/HST.2018.8383893
 89.
C. Tezcan, Truncated, impossible, and improbable differential analysis of Ascon, in ICISSP 2016 (SciTePress, 2016), pp. 325–332. https://doi.org/10.5220/0005689903250332. IACR https://ia.cr/2016/490
 90.
C. Tezcan, Distinguishers for reduced round Ascon, DryGASCON, and Shamash permutations, in NIST Lightweight Cryptography Workshop (2019). https://csrc.nist.gov/Presentations/2019/distinguishersforreducedroundascondrygascona
 91.
Y. Todo, Structural evaluation by generalized integral property, in EUROCRYPT 2015. LNCS, vol. 9056 (Springer, 2015), pp. 287–314. https://doi.org/10.1007/978366246800512. IACR https://ia.cr/2015/090
 92.
S. Vaudenay, D. Vizár, Can Caesar beat Galois?—Robustness of CAESAR candidates against nonce reusing and high data complexity attacks, in ACNS 2018. LNCS, vol. 10892 (Springer, 2018), pp. 476–494. https://doi.org/10.1007/978331993387025. IACR https://ia.cr/2017/1147
 93.
P. Yalla, J.P. Kaps, Evaluation of the CAESAR hardware API for lightweight implementations, in ReConFig 2017 (IEEE, 2017), pp. 1–6. https://doi.org/10.1109/RECONFIG.2017.8279790 (p. 33)
 94.
H. Yan, X. Lai, L. Wang, Y. Yu, Y. Xing, New zerosum distinguishers on full 24round Keccakf using the division property, in IET Information Security 13.5 (2019), pp. 469–478. https://doi.org/10.1049/ietifs.2018.5263
 95.
R. Zong, X. Dong, X. Wang, Collision attacks on roundreduced GimliHash/AsconXof/AsconHash. IACR Cryptology ePrint Archive, Report 2019/1115 (IACR, 2019), p. 21. https://ia.cr/2019/1115
Acknowledgements
The authors would like to thank all researchers contributing to the design, analysis and implementation of Ascon. In particular, we want to thank Hannes Gross for all his support and various implementations of Ascon. Part of this work has been supported by the Austrian Science Fund (FWF): P26494N15 and J 4277N38, by the European Union’s Horizon 2020 research and innovation programme (H2020 ICT 644052: HECTOR) and the European Research Council (ERC 681402: SOPHIA), and by the Austrian Government (FFG/SFG COMET 836628: SeCoS and FITIT 835919: SePAG).
Funding
Open access funding provided by Graz University of Technology.
Author information
Affiliations
Corresponding author
Additional information
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Communicated by Tetsu Iwata.
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
About this article
Cite this article
Dobraunig, C., Eichlseder, M., Mendel, F. et al. Ascon v1.2: Lightweight Authenticated Encryption and Hashing. J Cryptol 34, 33 (2021). https://doi.org/10.1007/s00145021093989
Received:
Revised:
Accepted:
Published:
Keywords
 CAESAR competition
 Authenticated encryption
 Hash function
 Extendable output function
 Lightweight cryptography
 Permutationbased cryptography
 Ascon