Hubbry Logo
Ascon (cipher)Ascon (cipher)Main
Open search
Ascon (cipher)
Community hub
Ascon (cipher)
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Ascon (cipher)
Ascon (cipher)
Ascon (cipher)
View on Wikipedia
from Wikipedia
Ascon
General
DesignersC. Dobraunig, M. Eichlseder, F. Mendel, M. Schläffer[1]
First published2014
Cipher detail
Key sizesup to 128, 128 bits are recommended
Block sizesup to 128 bits, 128 and 64 bits are recommended
Structuresponge construction
Rounds6–8 rounds per input word recommended

Ascon is a family of lightweight authenticated ciphers and hash functions that have been selected by the U.S. National Institute of Standards and Technology (NIST) for cryptography on resource-constrained devices in 2025, specified in NIST SP 800-232.[2][3][4]

History

[edit]

Ascon was developed in 2014 by a team of researchers from Graz University of Technology, Infineon Technologies, Lamarr Security Research, and Radboud University.[5] The cipher family was chosen as a finalist of the CAESAR Competition[5] in February 2019.

NIST announced its decision on February 7, 2023[5] with the following steps that lead to its standardization:[2]

  • Publication of NIST IR 8454[6] describing the process of evaluation and selection that was used;
  • Preparation of a new draft[7] for public comments[8];
  • Public workshop held on June 21–22, 2023.[1]

NIST finalized the standard on August 13, 2025, releasing it as "Ascon-Based Lightweight Cryptography Standards for Constrained Devices" (NIST Special Publication 800-232).[9]

Design

[edit]

The design is based on a sponge construction along the lines of SpongeWrap and MonkeyDuplex. This design makes it easy to reuse Ascon in multiple ways (as a cipher, hash, or a MAC).[10] As of February 2023, the Ascon suite contained seven ciphers,[5] including:[11]

  • Ascon-128 and Ascon-128a authenticated ciphers;
  • Ascon-Hash cryptographic hash;
  • Ascon-Xof extendable-output function;
  • Ascon-80pq cipher with an "increased" 160-bit key.

The main components have been borrowed from other designs:[10]

  • substitution layer utilizes a modified S-box from the χ function of Keccak;
  • permutation layer functions are similar to the of SHA-2.

Parameterization

[edit]

The ciphers are parameterizable by the key length k (up to 128 bits), "rate" (block size) r, and two numbers of rounds a, b. All algorithms support authenticated encryption with plaintext P and additional authenticated data A (that remains unencrypted). The encryption input also includes a public nonce N, the output - authentication tag T, size of the ciphertext C is the same as that of P. The decryption uses N, A, C, and T as inputs and produces either P or signals verification failure if the message has been altered. Nonce and tag have the same size as the key K (k bits).[12]

In the CAESAR submission, two sets of parameters were recommended:[12]

Suggested parameters, bits
Name k r a b
Ascon-128 128 64 12 6
Ascon-128a 128 128 12 8

Padding

[edit]

The data in both A and P is padded with a single bit with the value of 1 and a number of zeros to the nearest multiple of r bits. As an exception, if A is an empty string, there is no padding at all.[13]

State

[edit]

The state consists of 320 bits, so the capacity .[14] The state is initialized by an initialization vector IV (constant for each cipher type, e.g., hex 80400c0600000000 for Ascon-128) concatenated with K and N.[15]

Transformation

[edit]

The initial state is transformed by applying a times the transformation function p (). On encryption, each word of A || P is XORed into the state and the p is applied b times (). The ciphertext C is contained in the first r bits of the result of the XOR. Decryption is near-identical to encryption.[14] The final stage that produces the tag T consists of another application of ; the special values are XORed into the last c bits after the initialization, the end of A, and before the finalization.[13]

Transformation p consists of three layers:

Test vectors

[edit]

Hash values of an empty string (i.e., a zero-length input text) for both the XOF and non-XOF variants.[16] 

Ascon-Hash("")
0x 7346bc14f036e87ae03d0997913088f5f68411434b3cf8b54fa796a80d251f91
Ascon-HashA("")
0x aecd027026d0675f9de7a8ad8ccf512db64b1edcf0b20c388a0c7cc617aaa2c4
Ascon-Xof("", 32)
0x 5d4cbde6350ea4c174bd65b5b332f8408f99740b81aa02735eaefbcf0ba0339e
Ascon-XofA("", 32)
0x 7c10dffd6bb03be262d72fbe1b0f530013c6c4eadaabde278d6f29d579e3908d

Even a small change in the message will (with overwhelming probability) result in a different hash, due to the avalanche effect. 

Ascon-Hash("The quick brown fox jumps over the lazy dog")
0x 3375fb43372c49cbd48ac5bb6774e7cf5702f537b2cf854628edae1bd280059e
Ascon-Hash("The quick brown fox jumps over the lazy dog.")
0x c9744340ed476ac235dd979d12f5010a7523146ee90b57ccc4faeb864efcd048

See also

[edit]

References

[edit]

Sources

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Ascon (cipher)

View on Grokipedia
from Grokipedia
Ascon is a family of lightweight cryptographic primitives designed for authenticated encryption with associated data (AEAD), hashing, and extendable-output functions (XOF), optimized for resource-constrained environments such as Internet of Things (IoT) devices, RFID tags, and embedded systems. It employs a sponge-based construction using a 320-bit permutation to achieve 128-bit security levels, with variants like Ascon-128 and Ascon-128a for AEAD, Ascon-Hash for fixed-output hashing, and Ascon-XOF for variable-length outputs, all featuring low hardware footprints (as small as 2.6 kGE) and resistance to side-channel attacks through simple, efficient implementations. Developed by a team of cryptographers from Graz University of Technology, Infineon Technologies, Intel Labs, and Radboud University, Ascon was first submitted to the CAESAR competition in 2014 and selected as the primary recommendation for lightweight AEAD in 2019. It later advanced as a finalist in the NIST Lightweight Cryptography standardization process (2019–2023), culminating in its formal adoption as a NIST standard in Special Publication 800-232 in August 2025, providing robust protection for small-scale devices against common cryptographic threats like nonce misuse and key recovery attacks with complexities exceeding 2^{128} operations.

Overview

Description

Ascon is a family of authenticated encryption with associated data (AEAD) and hashing algorithms designed for resource-constrained environments, such as Internet of Things (IoT) devices, where low power consumption, small memory footprint, and hardware efficiency are critical. It addresses the need for secure communication and data integrity in embedded systems by providing compact implementations that resist side-channel attacks while maintaining high performance for short messages. The algorithms were proposed by Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer in 2014 as part of the CAESAR competition for authenticated encryption. At its core, Ascon employs a sponge-based construction operating in duplex mode for AEAD, enabling the processing of variable-length messages and associated data in a single pass without requiring inverse operations. Key features include support for flexible key, nonce, and tag sizes up to 128 bits, along with a lightweight permutation function optimized for both hardware and software implementations, achieving low gate equivalents (under 10 kGE in hardware). This design ensures efficiency in scenarios with limited computational resources, such as wireless sensor networks. The high-level architecture of Ascon utilizes a fixed 320-bit state represented as five 64-bit words, divided into a rate portion for input/output and a capacity portion for internal state protection. Depending on the variant, it provides 128 bits of security for confidentiality and integrity in the primary variants, with Ascon-80pq providing 80-bit classical security. In 2023, Ascon was selected by the National Institute of Standards and Technology (NIST) as the primary standard for lightweight cryptography, with finalization in 2025.

Variants and Parameters

The Ascon family encompasses several variants tailored for different security requirements and performance needs in lightweight cryptography, primarily operating on a 320-bit state divided into rate (r) and capacity (c) portions using a sponge construction. The primary authenticated encryption with associated data (AEAD) variants include Ascon-128, which uses a 128-bit key, 128-bit nonce, and 128-bit tag, with parameters r = 64 bits and c = 256 bits, employing 12 rounds for initialization and absorption (p) and 6 rounds for squeezing (p); Ascon-128a, designed for efficiency with a 128-bit key, 128-bit nonce, and 128-bit tag, featuring r = 128 bits and c = 192 bits, with 12 absorption rounds (p) and 8 squeezing rounds (p); and Ascon-80pq, a post-quantum resistant option with a 160-bit key, 128-bit nonce, and 128-bit tag, using r = 64 bits and c = 256 bits, also with p and p rounds to achieve 80-bit classical security while providing enhanced resistance to quantum attacks via the larger key size. For hashing and extendable output functions, Ascon-Hash produces a 256-bit output with r = 64 bits and c = 256 bits, using 12 rounds (p) throughout; Ascon-XOF supports arbitrary-length outputs with the same r and c values and p rounds; while Ascon-XOF-H (also known as the customized variant) allows for a customization string up to 2048 bits, maintaining identical parameters to enable domain-separated extendable outputs. These variants share the core 320-bit permutation but adjust r and c to balance throughput and security margins.
VariantKey Size (bits)r (bits)c (bits)Absorption RoundsSqueezing RoundsPrimary Use CaseSecurity Level (bits)
Ascon-12812864256126AEAD128
Ascon-128a128128192128Efficient AEAD128
Ascon-80pq16064256126Post-quantum AEAD80 (classical)
Ascon-HashN/A6425612N/AHashing (256-bit output)128 (collision)
Ascon-XOFN/A642561212Extendable outputUp to 128
Ascon-XOF-HN/A642561212Customized XOFUp to 128
Trade-offs among these variants center on the rate-capacity balance: a higher r (e.g., 128 bits in Ascon-128a) enhances processing speed by allowing larger data chunks per permutation but reduces c, potentially narrowing the security margin against certain attacks, whereas lower r with larger c (e.g., in Ascon-128 and Ascon-80pq) prioritizes robustness at the cost of throughput. The NIST standard SP 800-232 selects and standardizes Ascon-AEAD128 (based on Ascon-128a with r = 128 bits, c = 192 bits, 12 initialization/finalization rounds, and 8 absorption/squeezing rounds for 128-bit security) and equivalents for hashing (Ascon-Hash256) and XOFs (Ascon-XOF128 and Ascon-CXOF128), while excluding Ascon-80pq and Ascon-128 in favor of the selected AEAD for quantum resistance and efficiency. Security levels for Ascon variants are bounded by approximately min⁡(2k,2c/2,2r⋅σ/2)\min(2^k, 2^{c/2}, 2^{r \cdot \sigma / 2}), where kk is the key size in bits, cc is the capacity, rr is the rate, and σ\sigma is the number of processed blocks, ensuring provable limits on confidentiality, integrity, and collision resistance under standard sponge assumptions. This parameterization allows Ascon to adapt to constrained environments like IoT devices, where Ascon-128a offers efficiency gains and Ascon-80pq targets scenarios requiring quantum preparedness without full post-quantum migration.

History and Development

Origins and Initial Proposal

Ascon was developed in 2014 by a team of cryptographers at the Institute for Applied Information Processing and Communications (IAIK) of Graz University of Technology in Austria, consisting of Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer, with contributions from Infineon Technologies, Intel Labs, and Radboud University. The primary motivation for its creation stemmed from the growing demand for lightweight cryptographic primitives suitable for resource-constrained embedded systems, such as those in the Internet of Things (IoT), where traditional ciphers often impose excessive computational and memory overheads. These systems require algorithms that provide strong security while maintaining low power consumption and minimal hardware footprint, enabling efficient operation in environments with limited energy and processing capabilities. The initial proposal, titled "Ascon v1.0," was submitted to the CAESAR competition on March 15, 2014, as a family of authenticated encryption schemes designed to meet the competition's goals for secure and efficient authenticated encryption with associated data (AEAD). Key design goals emphasized balancing high security margins—aiming for at least 128 bits of security against generic attacks—with optimized performance in both software and hardware implementations. Specifically, the designers targeted low resource usage, such as small gate counts in hardware (e.g., around 2,500-3,000 GE for core operations) and fast execution times, while supporting straightforward countermeasures against side-channel attacks like power analysis. Ascon v1.0 was based on a sponge construction, which facilitated its lightweight properties and ease of analysis. Following initial feedback from the cryptographic community during the CAESAR competition's early rounds, the proposal evolved to version 1.2 by September 2016. This update incorporated refinements to enhance side-channel resistance, including adjustments to parameter sets (e.g., renaming and strengthening Ascon-96 to Ascon-128a for 128-bit key security) and modifications to the round constant schedule for better compatibility with standardized sponge modes, all while preserving the core design's efficiency and security bounds. These changes addressed community observations on implementation robustness, particularly in masked hardware settings, without altering the permutation function or overall performance profile. The v1.2 specification, submitted for CAESAR Round 3, solidified Ascon's focus on practical deployment in constrained devices.

Participation in Competitions

Ascon was initially submitted to the CAESAR (Competition for Authenticated Encryption: Security, Applicability, and Robustness) competition in March 2014 as part of Round 1, where it advanced through evaluations alongside 56 other candidates. The algorithm progressed to Round 2 in 2015 and Round 3 in 2016, undergoing extensive cryptanalysis that confirmed its security margins while identifying opportunities for minor tweaks. In 2019, Ascon was selected for inclusion in the CAESAR final portfolio as the first-choice recommendation for lightweight applications, such as those in Internet of Things devices, enhancing its credibility and prompting further implementations and studies. Building on this success, Ascon was submitted to the NIST Lightweight Cryptography (LWC) standardization project in early 2019, as one of 57 initial candidates received between November 2018 and March 2019. It advanced through Round 1 (announced August 2019) and Round 2 (announced February 2021), reaching the finalist round in March 2021 with 10 remaining algorithms. After rigorous evaluation, including performance benchmarks and security analyses across constrained hardware, NIST selected Ascon in February 2023 as the primary algorithm for standardization of lightweight authenticated encryption and hashing, citing its balance of security, efficiency, and versatility over the other submissions. The standard was finalized and published in NIST Special Publication 800-232 on August 13, 2025. The competitions drove iterative refinements to Ascon, with updates in versions v1.1 and v1.2 developed in response to cryptanalytic feedback from CAESAR rounds, such as adjustments to the round constant schedule to improve compatibility with sponge-based modes while maintaining diffusion properties. For instance, the number of rounds in the initialization and finalization phases was tuned to 12 for the primary variant, ensuring full diffusion after these rounds based on analysis of active S-boxes and linear trails. These enhancements, informed by community scrutiny, solidified Ascon's position without altering its core sponge construction.

Design Principles

Sponge Construction

The sponge construction is a cryptographic primitive that processes variable-length inputs and produces arbitrary-length outputs using a fixed-size internal state and a permutation function applied iteratively. It operates by dividing the state into a publicly accessible rate portion, which interacts with input and output data, and a protected capacity portion, which absorbs and diffuses information to ensure security properties like collision resistance and preimage resistance. The construction alternates between absorption phases, where input data is XORed into the rate and the state is permuted, and squeezing phases, where output is extracted from the rate after permutation, with the capacity safeguarding the internal state from direct observation. Ascon employs a duplex variant of the sponge construction, which enables efficient single-pass processing for authenticated encryption and hashing by alternating absorption of input data (such as messages or associated data) and squeezing of output (such as ciphertexts or tags) in a streaming manner. In this mode, the 320-bit state is maintained throughout, with the rate r determining the block size for input/output operations and the capacity c = 320 - r providing security against attacks by remaining secret and unmodified during absorption and squeezing. The duplex mode supports online operation, allowing data to be processed block-by-block without requiring the full input length in advance, while the permutation—detailed in the Permutation Function section—ensures diffusion across the entire state. The sponge operation in Ascon proceeds through distinct phases. Initialization sets the 320-bit state S to the concatenation of an initialization vector IV, the secret key K, and the nonce N (S = IV || K || N), applies the a-round permutation p_a to S, then updates S ← p_a(S) ⊕ (0^{320-k} || K), where k is the key size. During processing, associated data is absorbed block-by-block into the rate (padded if necessary), followed by permutation; for each full plaintext block, the ciphertext block C_i is computed as P_i ⊕ S_r, then P_i is absorbed by XORing it into S_r, followed by applying the b-round permutation p_b (noting functional equivalence to absorbing plaintext first due to XOR commutativity). Finalization involves absorbing padding if necessary, XORing the padded key into the state (capacity), applying the a-round permutation p_a, then computing the authentication tag as the least significant 128 bits of the resulting state XORed with the key. Conceptually, the state can be visualized as a diagram where the 320-bit internal state S is partitioned into the rate S_r (the first r bits, exposed for input/output) and the capacity S_c (the remaining c bits, kept secret). During absorption, input blocks of length up to r bits are XORed directly into S_r, and the full state S = S_r || S_c is then permuted to mix information; in squeezing, r bits are read from S_r as output, followed by permutation of S before the next operation. This division ensures that while the rate handles efficiency, the capacity enforces the sponge's provable security bounds, such as a capacity-based limit on the birthday attack complexity.

Permutation Function

The permutation function π in Ascon is the core primitive that processes the 320-bit state, which is organized as five 64-bit words denoted as x0,x1,x2,x3,x4x_0, x_1, x_2, x_3, x_4. It employs a substitution-permutation network (SPN) design, integrating a nonlinear substitution layer and a linear diffusion layer to achieve confusion and diffusion, respectively. The permutation executes a fixed number of rounds—12 in total for standard Ascon variants—to ensure cryptographic strength across the state. The NIST standard (SP 800-232, August 2025) adopts little-endian byte order and updates the round constants to support permutations of up to 16 rounds. Each round of the permutation begins with the addition of a round constant to break algebraic symmetries and prevent slide attacks. These constants are 8-bit values from the updated sequence defined in NIST SP 800-232, added via XOR to the least significant byte of the second word x2x_2 as 64-bit values with the constant in the least significant bits and zeros elsewhere; for example, the first round constant is 0x3C (as 0x000000000000003C). The substitution layer then applies a set of 5-bit S-boxes in parallel across 64 independent bit-slices, where each slice treats the five words as columns in a 5×64 bit matrix, ensuring nonlinear mixing within each 5-bit group without fixed points or linear biases exceeding 1/41/4. Following substitution, the linear diffusion layer mixes bits within each word independently by XORing the word with its right-rotated versions: x0x_0 rotated right by 19 and 28 bits, x1x_1 by 61 and 39 bits, x2x_2 by 1 and 6 bits, x3x_3 by 10 and 17 bits, and x4x_4 by 7 and 41 bits, each XORed with the original word. This intra-word diffusion complements the inter-word mixing provided by the substitution layer, achieving a branch number of 4 for the linear layer. The overall round structure—constant addition, substitution, then linear diffusion—is iterated 12 times, with the number of rounds tunable via parameters aa and bb in Ascon's sponge-based modes, though fixed at 12 for the primary permutation.

Cipher Specifications

State Representation

The Ascon cipher operates on a fixed 320-bit state, structured as a linear array of five 64-bit words denoted as S=s0∥s1∥s2∥s3∥s4S = s_0 \| s_1 \| s_2 \| s_3 \| s_4, where each sis_i is a 64-bit word loaded in little-endian byte order. This representation facilitates efficient word-level operations across hardware and software implementations. State initialization varies by mode but always begins by loading a 64-bit initialization vector (IV) into the first word, followed by mode-specific data, and padding the remainder with zeros to reach 320 bits. For authenticated encryption with associated data (AEAD) in Ascon-AEAD128, the state is set to S=IV∥K∥NS = \text{IV} \| K \| N, where IV is the 64-bit constant 0x00001000808c0001, KK is the 128-bit key (occupying words 1 and 2), and NN is the 128-bit nonce (occupying words 3 and 4), with no initial padding needed as the inputs fill the state exactly. An initialization permutation p{{grok:render&&&type=render_inline_citation&&&citation_id=12&&&citation_type=wikipedia}} is then applied to the state, after which the key is XORed into the last 128 bits: S←S⊕(0192∥K)S \leftarrow S \oplus (0^{192} \| K), effectively incorporating the key twice in the transformed state to enhance security. In hashing and extendable-output function (XOF) modes, such as Ascon-Hash256 and Ascon-XOF128, no key or nonce is used; the state is instead initialized as S=IV∥0256S = \text{IV} \| 0^{256}, where the IV is padded with 256 zero bits to fill the remaining four words, followed by the p{{grok:render&&&type=render_inline_citation&&&citation_id=12&&&citation_type=wikipedia}} permutation. Specific IV constants ensure domain separation across modes: 0x0000080100cc0002 for hashing, 0x0000080000cc0003 for XOF, and 0x0000080000cc0004 for the continuous variant CXOF, preventing cross-mode attacks by distinguishing operational contexts. All transformations in Ascon, including the core permutation, operate exclusively on these 64-bit words using bitwise XORs and right rotations (denoted ⋙\ggg), such as in linear layer computations like s0⊕(s0⋙19)⊕(s0⋙28)s_0 \oplus (s_0 \ggg 19) \oplus (s_0 \ggg 28), to maintain lightweight efficiency.

Padding and Rate

The Ascon cipher employs a padding scheme based on the sponge construction to process inputs in blocks aligned with the rate r, where the state is divided into a rate portion of r bits and a capacity portion of c = 320 - r bits. Inputs, including associated data (AD) and messages, are padded by appending a single '1' bit followed by the minimal number of '0' bits required to reach a length that is a multiple of r; this is known as the pad_r function. This rule ensures the multi-rate padding property, meaning that for non-empty inputs whose length is already a multiple of r, a full additional block consisting of '1' followed by r-1 '0's is appended and processed, preventing ambiguity between full blocks and input endings. For empty inputs, no padding block is added. The rate portion of the state is used for input absorption and output extraction in the duplex sponge mode. During absorption, each r-bit block of the padded input is XORed directly into the rate bits S_r of the current state, after which the full state is transformed by the permutation function; this process repeats for each block without ever modifying or revealing the capacity bits S_c. For output squeezing, r-bit blocks are extracted by XORing the rate bits S_r with a zero string (for ciphertext generation in AEAD) or the desired output stream, followed by a permutation on the state to prepare for the next block; the final output block is truncated to the required length if necessary. The capacity bits remain protected throughout, as they are neither directly XORed with inputs/outputs nor exposed, providing security against state recovery attempts with complexity at least 2^{c/2}. In AEAD mode, specific domain separation paddings are applied after processing the respective padded inputs to distinguish between phases. After absorbing the padded associated data, the state is XORed with a padding value of 0^{r-8} || 0x10 (indicating the end of AD) before proceeding to message processing. Similarly, after absorbing the padded message, the state is XORed with 0^{r-8} || 0x01 (indicating the end of the message) prior to tag generation. These byte-level domain separations, aligned to the end of the rate, ensure mode-specific integrity without altering the core padding rule. The integration builds on the state representation where only the rate is accessible for such operations, while full details of AEAD processing appear in the dedicated mode description.

Round Transformations

The round transformations in Ascon are applied as part of the permutation function within its sponge construction, sequencing multiple iterations of a substitution-permutation network (SPN) round to process the 320-bit state. The permutation variants pap_a and pbp_b differ in the number of rounds: pap_a uses 12 rounds for initialization and finalization phases, while pbp_b uses 6 or 8 rounds between absorption steps depending on the variant. For Ascon-128 and Ascon-80pq, the parameters are p=12p = 12 rounds for initialization and finalization, and q=6q = 6 rounds applied after each absorption of message or associated data blocks; for Ascon-128a, q=8q = 8. These counts ensure sufficient diffusion during state updates, with the full transformation involving the iterative application of round constants alongside the core round operations. Each round of the permutation consists of three sequential subtransformations: the addition of a round constant (pCp_C), a nonlinear substitution layer (pSp_S), and a linear diffusion layer (pLp_L). The round constant addition pCp_C XORs a variant-specific 8-bit constant crc_r (derived from rate-1 linear feedback shift register values) into the third 64-bit word x2x_2 of the state, where the constant index rr starts from 0 and increments per round, wrapping appropriately for pbp_b after the initial pap_a. This injects round-dependent values to prevent slide attacks and ensure uniqueness across iterations. The nonlinear layer pSp_S applies a compact 5-bit S-box, defined in algebraic normal form for output bits y0y_0 to y4y_4 in terms of input bits x0x_0 (MSB) to x4x_4 (LSB), where juxtaposition denotes AND and ⊕\oplus denotes XOR: y0=x4x1⊕x3⊕x2x1⊕x2⊕x1x0⊕x1⊕x0y_0 = x_4 x_1 \oplus x_3 \oplus x_2 x_1 \oplus x_2 \oplus x_1 x_0 \oplus x_1 \oplus x_0; y1=x4⊕x3x2⊕x3x1⊕x3⊕x2x1⊕x2⊕x1⊕x0y_1 = x_4 \oplus x_3 x_2 \oplus x_3 x_1 \oplus x_3 \oplus x_2 x_1 \oplus x_2 \oplus x_1 \oplus x_0; y2=x4x3⊕x4⊕x2⊕x1⊕1y_2 = x_4 x_3 \oplus x_4 \oplus x_2 \oplus x_1 \oplus 1; y3=x4x0⊕x4⊕x3x0⊕x3⊕x2⊕x1⊕x0y_3 = x_4 x_0 \oplus x_4 \oplus x_3 x_0 \oplus x_3 \oplus x_2 \oplus x_1 \oplus x_0; y4=x4x1⊕x4⊕x3⊕x1x0⊕x1y_4 = x_4 x_1 \oplus x_4 \oplus x_3 \oplus x_1 x_0 \oplus x_1, 64 times in parallel to each vertical bit slice formed by one bit from each of the five state words x0,…,x4x_0, \dots, x_4. This bit-sliced application provides inter-word nonlinearity and diffusion. The linear layer pLp_L follows, diffusing each 64-bit word independently via bitwise XORs of rotated versions to achieve full mixing within the word, with rotations tailored to optimize hardware efficiency. The transformation for each word xix_i (indices modulo 5) is given by: x0←x0⊕(x0⋙19)⊕(x0⋙28),x1←x1⊕(x1⋙61)⊕(x1⋙39),x2←x2⊕(x2⋙1)⊕(x2⋙6),x3←x3⊕(x3⋙10)⊕(x3⋙17),x4←x4⊕(x4⋙7)⊕(x4⋙41),\begin{align*} x_0 &\leftarrow x_0 \oplus (x_0 \ggg 19) \oplus (x_0 \ggg 28), \\ x_1 &\leftarrow x_1 \oplus (x_1 \ggg 61) \oplus (x_1 \ggg 39), \\ x_2 &\leftarrow x_2 \oplus (x_2 \ggg 1) \oplus (x_2 \ggg 6), \\ x_3 &\leftarrow x_3 \oplus (x_3 \ggg 10) \oplus (x_3 \ggg 17), \\ x_4 &\leftarrow x_4 \oplus (x_4 \ggg 7) \oplus (x_4 \ggg 41), \end{align*} where ⋙k\ggg k denotes rotation right by kk bits modulo 64. These bit shifts and XORs form a lightweight linear mask that complements the S-box diffusion, completing one full round p=pL∘pS∘pCp = p_L \circ p_S \circ p_C. The sequence of 12, 6, or 8 such rounds, combined with constant additions, operationalizes the permutation for secure state updates in Ascon's modes.

Modes of Operation

Authenticated Encryption with Associated Data (AEAD)

Ascon provides authenticated encryption with associated data (AEAD) through modes that ensure both confidentiality of the plaintext and integrity of the plaintext and associated data using a sponge-based construction. The primary standardized primitive, Ascon-AEAD128, uses a 128-bit key, a 128-bit nonce, and a default 128-bit tag (truncatable to shorter lengths down to 32 bits for specific applications). This mode operates on a 320-bit state divided into five 64-bit words, with a rate of 128 bits for processing data blocks. The description follows the parameters of Ascon-128a (rate=128 bits, b=8 rounds for absorption/processing), one of the variants under Ascon-AEAD128 in the NIST standard. The encryption process begins with initialization: the state is set to the concatenation of a fixed 64-bit initialization vector (0x00001000808c0001 for Ascon-128a), the 128-bit key, and the 128-bit nonce, followed by applying the Ascon permutation for 12 rounds and XORing the key into bits 192–319 of the state (equivalent to XORing 0^{192} || key). Associated data is then absorbed by padding it to form complete 128-bit blocks (appending a '1' bit followed by zeros if necessary), XORing each block into the first 128 bits (rate portion) of the state, applying the permutation for 8 rounds after each block, and finally XORing a domain separation string (a '1' bit in the 320th position) followed by 8 rounds. To encrypt the plaintext, it is parsed into 128-bit blocks; for each full block, the plaintext block is XORed into the rate portion (producing the ciphertext block as the updated rate), followed by 8 rounds of permutation. For the final (possibly partial) block, the partial plaintext is XORed into the first |P| bits of the rate (producing the partial ciphertext from those bits, which is output), then a padding of '1' bit followed by zeros is XORed into the rate starting from bit |P| to fill the 128 bits, followed by 8 rounds. Tag generation concludes the process: the rate (first 128 bits) is XORed with zeros, the key is XORed into bits 128–255 and zeros into bits 256–319, the permutation is applied for 12 rounds, and the tag is computed as bits 192–319 of the resulting state XORed with the key. Decryption mirrors encryption up to the associated data absorption, using the same initialization and processing steps. For the ciphertext blocks, each full block is XORed into the rate portion to recover the plaintext block, which is then fed back into the state (updated rate equals the ciphertext block), followed by 8 rounds; for the final partial block, the available bits are XORed into the rate to recover partial plaintext, then the state is padded with a '1' bit and zeros in the remaining rate bits before applying 8 rounds. The computed tag is generated identically to encryption and compared to the received tag; if they match, the plaintext is released, otherwise decryption rejects the message to prevent release of tampered data. The nonce must be unique for each key usage to maintain security.

Hashing and Extendable Output Functions

Ascon provides hashing capabilities through sponge-based modes that leverage its lightweight permutation for absorbing input messages and squeezing fixed or variable-length outputs. These modes operate without keys, focusing on properties like collision resistance suitable for constrained devices. The primary fixed-output hash function is Ascon-Hash256, which generates a 256-bit digest. In Ascon-Hash256, the state is initialized by setting the first 64 bits to the IV (0x0000080100cc0002) and the remaining 256 bits to zero. The input message is padded by appending a '1' bit followed by the minimal number of '0' bits to make the length a multiple of the rate r = 64 bits. Each padded 64-bit block is XORed into the rate portion of the state (the first 64 bits), followed by applying the Ascon permutation with 12 rounds. Squeezing then proceeds by extracting consecutive 64-bit blocks from the rate portion (applying the permutation with 12 rounds between extractions) until the 256-bit output is reached. The extendable-output function Ascon-XOF128 supports arbitrary-length outputs by extending the squeezing phase beyond fixed sizes. The state is initialized with IV 0x0000080000cc0003 in the first 64 bits and zeros elsewhere. Absorption follows the same padding and process as Ascon-Hash256. Squeezing then proceeds by repeatedly extracting 64-bit blocks from the rate after each permutation with 12 rounds, allowing output up to the security limit (e.g., up to 2^{128} bits). Ascon-CXOF128 serves as a customizable mode for variable-length hashing and extendable outputs. It uses an initialization vector of 0x0000080000cc0004 in the rate portion, with absorption first processing any customization string (padded similarly with '1' bit and zeros to multiple of 64 bits) before the main message. The squeezing phase mirrors Ascon-XOF128, enabling outputs of any length up to the security limit, making it suitable for applications needing flexible hash sizes without fixed truncation.

Security Considerations

Security Claims and Proofs

Ascon's authenticated encryption with associated data (AEAD) modes are designed to achieve indistinguishability under chosen-ciphertext attack (IND-CCA) security for confidentiality and integrity against nonce-respecting adversaries. The underlying duplex construction provides provable bounds on privacy and authenticity of up to 2c/22^{c/2} queries, where cc is the capacity (e.g., 21282^{128} for Ascon-128 with c=256c = 256), assuming the permutation behaves ideally and data complexity remains below this threshold. These bounds follow from generic security proofs for sponge-duplex AEAD schemes, which reduce security to the pseudorandomness of the inner permutation. As of the NIST standardization in August 2025, Ascon-AEAD128 provides 128-bit security in single-key, nonce-respecting settings. For the hashing mode, Ascon provides collision resistance up to 2d/22^{d/2} (e.g., 21282^{128} for a 256-bit digest dd) and second preimage resistance up to 2d2^{d}, in line with standard Merkle-Damgård or sponge hash security expectations. The extendable-output function (XOF) inherits similar guarantees, with preimage resistance up to min⁡(L,128)\min(L, 128) bits and collision resistance up to min⁡(L/2,128)\min(L/2, 128) bits (where LL is the output length), though practical security is limited by the output length for truncated outputs. These claims are supported by the sponge construction's indifferentiability from a random oracle, proven up to roughly 2c/22^{c/2} permutation calls under ideal permutation assumptions. The security proofs rely on the underlying 12-round permutation's resistance to cryptanalysis, particularly bounds on differential and linear trails. The permutation achieves full diffusion after 3 rounds and exhibits high numbers of active S-boxes in trails (e.g., at least 44 for 4-round differentials), ensuring differential probabilities below 2−1282^{-128} for the full 12 rounds. Linear trail weights are similarly bounded, with at least 43 active S-boxes over 4 rounds, supporting the permutation's pseudorandom behavior essential to the sponge proofs. Regarding post-quantum security, the Ascon-80pq variant (proposed in earlier specifications but not included in the final NIST standard) enhances resistance to Grover's algorithm by using a 160-bit key, achieving approximately 80-bit security against quantum key-search attacks while maintaining classical 128-bit bounds for other primitives. Recent evaluations as of 2025 confirm the standardized variants provide adequate classical security, with ongoing assessments of quantum Grover complexity. This design adjusts the capacity and key size to counter the quadratic speedup of quantum search on symmetric primitives.

Known Attacks and Resistance

Ascon has withstood extensive cryptanalysis since its proposal, with the most significant attacks targeting reduced-round versions of its permutation. Early differential cryptanalysis achieved key recovery on 5 out of 12 initialization rounds with a practical complexity of 2362^{36} data and time, but required at least 60 active S-boxes for the full 12 rounds, exceeding the claimed security bounds. Similarly, cube-like attacks enabled practical key recovery on 5 rounds at 2352^{35} complexity and theoretical recovery on 6 rounds at 2662^{66}, while linear attacks covered only up to 5 rounds with biases below 2−532^{-53} for the full scheme. More recent analyses on Ascon v1.2 confirm these bounds, with the best differential trails spanning 4 rounds and algebraic attacks covering 7 of 12 rounds at approximately 21042^{104} complexity; additional 2024-2025 algebraic attacks achieve preimage/collision on 2-5 reduced rounds of hashing/XOF at complexities as low as 2332^{33}, leaving a security margin of at least 42% against key recovery for full rounds. No practical cryptanalytic breaks exist for the full-round Ascon family, as the strongest such attacks demand over 21002^{100} time or data, well above 100-bit effort and supporting the 128-bit security claims. However, practical full-round key recovery is possible via physical fault injection attacks, such as subset fault analysis (SSFA) recovering the full 128-bit key with a small number of faults. The design incorporates specific features to enhance resistance against structural attacks. Round constants, added to the state in each permutation round, are chosen to prevent slide, rotational, and self-similarity attacks by ensuring distinct round functions without introducing exploitable patterns. The linear diffusion layer further promotes the avalanche effect, where a single-bit input change affects nearly all output bits after just 3 rounds, achieving a branch number of at least 3 and full diffusion properties. For side-channel resistance, Ascon's structure avoids highly data-dependent operations beyond its low-degree (degree 2) S-box, facilitating straightforward masking implementations up to higher orders without excessive overhead.

Implementations and Performance

Hardware Implementations

Hardware implementations of Ascon prioritize low area and energy efficiency, making it suitable for resource-constrained devices such as IoT sensors and RFID tags. For Ascon-128 in ASIC, a serialized architecture achieves an area of approximately 2,500 gate equivalents (GE), enabling deployment in highly limited environments while processing data at modest speeds. This low footprint contrasts with higher-throughput designs, which may exceed 7,000 GE but offer sub-cycle performance per byte. Common implementation strategies include serialized designs, which minimize area by processing one bit or a small width per cycle, resulting in around 3,750 GE including interfaces but requiring 384 cycles per byte. Serialized-round variants balance area and speed using a 64-bit datapath, occupying about 5,000 GE and achieving 44 cycles per byte. An example is the integration in OpenTitan, an open-source silicon root-of-trust project, where Ascon serves as a cryptographic accelerator with a serialized datapath supporting both Ascon-128 and Ascon-128a variants, targeting medium performance at roughly 1 cycle per round in unmasked form. Optimizations for security include threshold implementations to resist side-channel attacks like power analysis; a first-order threshold design for Ascon requires about 8,000 GE, only 3.1 times the area of an unprotected low-area baseline. On FPGAs, Ascon achieves throughputs exceeding 100 Mbps, with efficient designs on Spartan-7 devices reaching up to 3,440 Mbps using modest LUT resources. During NIST's Lightweight Cryptography standardization process, Ascon variants were evaluated against lightweight criteria, including areas under 10,000 GE and throughputs enabling less than 1 cycle per byte in optimized configurations, confirming their suitability for constrained hardware.

Software Implementations

Ascon software implementations emphasize portability and efficiency on general-purpose processors, with a focus on constrained environments like IoT devices. The reference implementation, developed by the cipher's designers, is written in pure C and requires no assembly code, enabling straightforward compilation across diverse platforms including x86-64, ARM, RISC-V, and AVR architectures. This design choice facilitates easy integration into embedded systems and higher-level applications without platform-specific dependencies. Optimizations in these implementations often utilize bit-sliced operations to process 64-bit words, which parallelizes the core permutation across multiple lanes for improved throughput. Bit interleaving techniques, applied to the 320-bit state, enhance performance by 10-20% on 32-bit platforms by enabling efficient use of word-level instructions and reducing branch overhead. Additional variants include architecture-specific tweaks, such as AVX2 and SSE intrinsics for x86 processors, and NEON for ARMv8, while maintaining a fallback to portable C code. Performance benchmarks highlight Ascon's suitability for software environments. On the ARM Cortex-M4 microcontroller, a common choice for IoT, the plain Ascon-128a authenticated encryption mode achieves approximately 42 cycles per byte for long messages using GCC optimizations. On modern desktop CPUs like the AMD EPYC 7742, optimized implementations reach 4.2 cycles per byte for Ascon-128 AEAD, enabling encryption of a 1 KB message in under 2 μs at typical clock speeds. These metrics position Ascon as efficient for higher-end IoT and general-purpose applications, outperforming many lightweight alternatives in software speed while keeping code sizes compact (e.g., around 1.3 KB for core AEAD functions). Beyond the reference code, third-party libraries have incorporated Ascon for broader adoption. The wolfSSL embedded SSL/TLS library includes a production-ready Ascon implementation, supporting its use in secure communications for resource-limited devices. Comprehensive test suites, such as Rhys Weatherley's ascon-suite, extend portability to additional architectures like m68k and Xtensa, with masked variants for side-channel resistance. These resources ensure Ascon's software footprint remains minimal and verifiable.

Standardization and Adoption

NIST Lightweight Cryptography Process

In 2018, the National Institute of Standards and Technology (NIST) initiated a call for nominations for lightweight cryptographic algorithms suitable for constrained environments, with submission requirements published on August 27 and a deadline of February 25, 2019. Ascon was submitted as one of 57 candidate algorithms, undergoing an initial review that led to the announcement of 56 first-round candidates, including Ascon, in April 2019. The NIST Lightweight Cryptography (LWC) standardization process proceeded through multiple evaluation phases focused on security analysis, performance metrics, and implementation characteristics across hardware and software platforms. Ascon advanced from Round 1 (April to August 2019) to Round 2 (August 2019 to March 2021) and then to the final round (March 2021 to February 2023), where it was one of 10 finalists subjected to extensive cryptanalysis and benchmarking by the cryptographic community. In February 2023, NIST announced the selection of the Ascon family as the primary candidate for standardization due to its balanced security margins and efficiency in resource-constrained settings. Following the selection, NIST released an initial public draft of Special Publication (SP) 800-232 on November 8, 2024, titled "Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable-Output Function." This draft specifies four variants of Ascon: Ascon-AEAD128 and Ascon-AEAD128a for authenticated encryption with associated data (AEAD), Ascon-Hash for hashing, and Ascon-XOF for extendable-output functions (XOF), providing flexibility for different use cases while maintaining 128-bit security levels. Public feedback on the draft was solicited through February 7, 2025, with comments addressing aspects such as specification clarity and verification needs. NIST incorporated relevant suggestions into the final standard, released on August 13, 2025, including refinements for improved readability and the addition of comprehensive test vectors to facilitate implementation and interoperability testing.

Current Status and Applications

On August 13, 2025, the National Institute of Standards and Technology (NIST) finalized Special Publication 800-232, establishing the Ascon family as the standard for lightweight authenticated encryption, hashing, and extendable output functions in constrained devices, thereby integrating it into federal guidelines for symmetric-key cryptography in resource-limited environments. This standardization emphasizes Ascon's suitability for applications where computational power, memory, and energy are limited, providing robust security without the overhead of heavier algorithms like AES. Following finalization, Ascon has seen integration into open-source hardware projects such as OpenTitan, where it serves as a dedicated cryptographic accelerator for authenticated encryption and decryption in silicon root-of-trust systems. In the automotive sector, Ascon is being explored for securing in-vehicle communications, particularly in electronic control units (ECUs), through protocols like LiREAP that leverage its authenticated encryption for Controller Area Network (CAN) messages to ensure confidentiality and integrity in resource-constrained environments. Ascon's lightweight design positions it as a candidate for embedded security applications due to its efficiency in constrained environments. Ascon is primarily applied to secure constrained Internet of Things (IoT) devices, including sensors and wearables, where it protects data in transit and at rest with minimal power consumption—for instance, encrypting physiological data on smartwatches or environmental readings from low-power nodes. It serves as an efficient alternative to AES in low-power scenarios, offering comparable 128-bit security with reduced gate equivalents and cycle counts, thus extending battery life in battery-operated systems like RFID tags and medical implants. Looking ahead, Ascon's resistance to quantum attacks via Grover's algorithm—retaining effective 64-bit security for its 128-bit keys—supports its role in post-quantum migrations for lightweight symmetric cryptography, with broader integration anticipated in protocols like TLS extensions by 2030 as quantum threats materialize.

References

  1. https://ascon.isec.tugraz.at/
  2. https://link.springer.com/article/10.1007/s00145-021-09398-9
  3. https://doi.org/10.6028/NIST.SP.800-232
  4. https://competitions.cr.yp.to/caesar.html
  5. https://csrc.nist.gov/CSRC/media/Projects/Lightweight-Cryptography/documents/round-1/spec-doc/ascon-spec.pdf
  6. https://competitions.cr.yp.to/round2/asconv11.pdf
  7. https://csrc.nist.gov/pubs/sp/800/232/final
  8. https://doi.org/10.1007/s00145-021-09398-9
  9. Mar 15, 2014 · The core permu- tations pa and pb operate on a sponge state S of size 320 bits, with a capacity of c = 2k bits and a rate of r = 320 − c bits.
  10. Aug 29, 2015 · [9] Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer. Crypt- analysis of ascon. In Kaisa Nyberg, editor, CT-RSA 2015, ...Missing: proposal | Show results with:proposal
  11. https://doi.org/10.1007/s00145-021-09398-9
  12. https://eprint.iacr.org/2015/030.pdf
  13. https://ascon.isec.tugraz.at/files/ascon.pdf
  14. https://competitions.cr.yp.to/round3/asconv12.pdf
  15. https://competitions.cr.yp.to/round1/asconv1.pdf
  16. https://competitions.cr.yp.to/caesar-submissions.html
  17. https://csrc.nist.gov/news/2023/lightweight-cryptography-nist-selects-ascon
  18. https://csrc.nist.gov/CSRC/media/Projects/lightweight-cryptography/documents/finalist-round/updated-spec-doc/ascon-spec-final.pdf
  19. http://sponge.noekeon.org/SpongeFunctions.pdf
  20. https://eprint.iacr.org/2011/499
  21. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-232.pdf
  22. https://csrc.nist.gov/CSRC/media/Projects/lightweight-cryptography/documents/round-2/spec-doc-rnd2/ascon-spec-round2.pdf
  23. https://keccak.team/files/SpongeIndifferentiability.pdf
  24. https://eprint.iacr.org/2025/411.pdf
  25. https://cybersecurity.springeropen.com/articles/10.1186/s42400-024-00340-7
  26. https://www.sciencedirect.com/science/article/abs/pii/S0026271421001219
  27. https://eprint.iacr.org/2015/034.pdf
  28. https://opentitan.org/book/hw/ip/ascon/index.html
  29. https://github.com/ascon/ascon-c
  30. https://csrc.nist.gov/csrc/media/Projects/lightweight-cryptography/documents/finalist-round/status-updates/ascon-update.pdf
  31. https://www.wolfssl.com/wolfssl-embraces-ascon-lightweight-cryptography/
  32. https://github.com/rweather/ascon-suite
  33. https://csrc.nist.gov/csrc/media/Projects/lightweight-cryptography/documents/final-lwc-submission-requirements-august2018.pdf
  34. https://csrc.nist.gov/projects/lightweight-cryptography
  35. https://csrc.nist.gov/news/2019/lightweight-cryptography-round-1-candidates
  36. https://csrc.nist.gov/pubs/sp/800/232/ipd
  37. https://csrc.nist.gov/pubs/sp/800/232/ipd/docs/sp800-232-ipd-public-comments-received.pdf
  38. https://www.nist.gov/news-events/news/2025/08/nist-finalizes-lightweight-cryptography-standard-protect-small-devices
  39. https://www.mdpi.com/2079-9292/13/22/4550
  40. https://jisem-journal.com/index.php/journal/article/download/11928/5550/20047
  41. https://eprint.iacr.org/2023/1914.pdf
  42. https://www.healthcareitnews.com/news/nist-releases-ascon-lightweight-cryptography-standard-small-devices
  43. https://norma.ncirl.ie/7139/1/mohammedsakhibnoorullah.pdf
  44. https://www.infineon.com/market-news/2023/infcss202302-064
  45. https://digitalcommons.usf.edu/cgi/viewcontent.cgi?article=1126&context=mca
  46. https://eprint.iacr.org/2025/260.pdf
  47. https://www.keyfactor.com/blog/getting-quantum-ready-why-2030-matters-for-post-quantum-cryptography/
Add your contribution
Related Hubs
User Avatar
No comments yet.