Ascon

Introduction

Not every device that needs encryption can afford AES. A battery-powered soil sensor, an RFID tag, a pacemaker — these have kilobytes of RAM, not megabytes, and every extra CPU cycle is battery life spent.

In February 2023, NIST concluded a multi-year competition by selecting the Ascon family as the winner of its Lightweight Cryptography project. Following extensive public scrutiny during the CAESAR and NIST LWC processes, NIST finalized SP 800-232 in August 2025, standardizing Ascon-AEAD128 (authenticated encryption), Ascon-Hash256, and the Ascon-XOF128/CXOF128 extendable-output functions.

Unlike the post-quantum algorithms elsewhere in this series, Ascon isn’t defending against quantum computers. Instead, it solves a much more immediate problem: how do you get real, modern authenticated encryption onto hardware too small and too power-constrained for AES-GCM or SHA-3 to be practical?

Table of Contents

• Security Claims and Properties
• Ascon-AEAD128 vs. AES-GCM
• Small State, Big Idea: The Sponge Construction
• The Ascon Permutation
• Ascon-AEAD128: Initialize, Absorb, Encrypt, Finalize
• A Worked Example
• Why the Domain-Separation Bit Matters
• The Ascon Family Beyond AEAD
• FAQ
• References

Security Claims and Properties

Ascon provides robust, modern cryptographic guarantees despite its tiny footprint:

• Confidentiality and Authenticity: The standardized Ascon-AEAD128 provides a full 128-bit security margin for both data secrecy and authentication in the single-key setting.
• Nonce-Based AEAD: Like most modern AEAD modes, it requires a strict unique nonce for every message encrypted under the same key.
• Forgery Resistance: It successfully resists known attacks against sponge constructions (such as boundary shifting between plaintext and associated data) thanks to deliberate state padding and domain separation.

Ascon-AEAD128 vs. AES-GCM

Why not just use AES-GCM? While AES is a standard workhorse, it wasn’t designed for resource-constrained microcontrollers. Here is how Ascon compares on tiny platforms:

• State Size: Ascon uses a tiny 320-bit internal state (40 bytes), whereas AES-GCM needs roughly 384 bits (AES state + GCM counter/hash states) plus significant memory for round keys and Galois field tables.
• Hardware Footprint: Ascon’s reference hardware implementations require roughly half the gate count of a comparable AES-GCM setup.
• Software Efficiency: On 8-bit and 32-bit microcontrollers, AES S-box table lookups and GCM Galois-field multiplications are expensive. Ascon relies purely on simple bitwise operations (AND, NOT, XOR) and fixed rotations, making it dramatically faster and cheaper in software on these architectures.

Small State, Big Idea: The Sponge Construction

Ascon relies on a duplex-style sponge construction — a concept closely related to SpongeWrap and MonkeyDuplex. It is the same general idea behind SHA-3/Keccak already covered on this site, just built around a dramatically smaller internal state.

Where Keccak’s permutation operates on 1600 bits, Ascon’s operates on just 320 bits (five 64-bit words, typically denoted x0 through x4). This state is small enough that an embedded implementation can keep it entirely in CPU registers. It never needs to touch RAM for the permutation itself.

A sponge works by splitting its internal state into two parts:

1. The Rate: The portion of the state that directly interacts with input and output data (for Ascon-AEAD128, this is the first 128 bits, meaning the first two 64-bit words, x0 and x1).
2. The Capacity: The hidden, protected portion of the state that ensures security and absorbs the key (the remaining 192 bits, meaning x2, x3, and x4).

The cipher works by absorbing data (XORing it into the rate) and repeatedly applying a permutation, then squeezing output the same way. Ascon-AEAD128 uses this mechanism to absorb a key and nonce, then associated data, then the plaintext (producing ciphertext as it goes). Finally, it squeezes out an authentication tag — all through the identical 320-bit permutation.

The Ascon Permutation

Each round of Ascon’s permutation applies three steps to the five 64-bit state words:

1. Add round constant — XOR a fixed, round-specific byte into x2. This ensures every round is distinct; without this, all rounds would be identical and the permutation would have exploitable symmetries.
2. Substitution layer — A 5-bit S-box is applied simultaneously across all 64 bit-positions in a “bit-sliced” fashion. Each of the 64 columns (one bit from each of the five words) is treated as an independent 5-bit input to the same small nonlinear S-box. This bit-slicing means the S-box can be implemented entirely using fast, constant-time bitwise logic (AND, XOR, NOT) without expensive memory table lookups. As a result, Ascon’s nonlinearity is computationally cheap even on tiny hardware.
3. Linear diffusion layer — Each word is XORed with two rotated copies of itself (rotation amounts of 19/28, 61/39, 1/6, 10/17, and 7/41 bits for x0 through x4 respectively). These specific rotation constants were mathematically chosen to provide optimal diffusion across 64-bit words, spreading any local change across the entire word.

Ascon-AEAD128 uses 12 rounds of this permutation for initialization and finalization (the highest-security moments) and 8 rounds for absorbing each block of associated data or plaintext. This is a deliberate speed/security tradeoff, as the intermediate rounds run continuously per data block.

Ascon-AEAD128: Initialize, Absorb, Encrypt, Finalize

(Try following along with the Interactive Visualizer embedded at the top of this page!)

1. Initialize: Load a 64-bit constant (which securely encodes the cipher variant, rate, round counts, and tag size) along with the 128-bit key and 128-bit nonce into the 320-bit state. Run the full 12-round permutation, and finally XOR the key back into the capacity.
2. Absorb associated data: Associated data (AD) is data that must be authenticated but not encrypted (like a network packet header). AD is padded by appending a single 1 bit followed by zeros to fill out the 128-bit block. (Depending on byte-ordering and word packing, this often appears as a 0x01 byte in little-endian reference implementations). For each 128-bit block, XOR it into the rate, then run 8 rounds. After all AD is processed, flip a domain-separation bit to mark the transition.
3. Encrypt plaintext: The plaintext is padded using the same 1 bit rule. For each 128-bit block, XOR it into the rate. The result is the ciphertext block. Run 8 rounds before processing the next block.
4. Finalize: XOR the key into the state again, run the full 12-round permutation, XOR the key in once more, and read out the last 128 bits (from x3 and x4) as the authentication tag.

Decryption mirrors this exact process. The crucial difference occurs during the plaintext phase: after XORing the ciphertext out of the rate to recover the plaintext, the rate portion of the state is overwritten directly with the ciphertext (not the recovered plaintext) before applying the next 8-round permutation. This ensures that a legitimate decryptor exactly reconstructs the identical internal state trajectory that the encryptor originally took.

A Worked Example

Because Ascon’s entire state fits in five 64-bit numbers, our visualizer runs the real, full-strength Ascon-AEAD128 — not a shrunk toy. Every round constant, S-box operation, and rotation matches the official NIST specification.

Using the visualizer:

1. Enter a message and some associated data, then generate a random key and nonce.
2. Watch the state after the 12-round initialization (which begins by loading the standardized Ascon-AEAD128 IV, 0x00001000808c0001). The five words will look like seemingly random 64-bit hex values, but they are already fully dependent on the initialized constant, key, and nonce.
3. The associated data gets absorbed (one 8-round permutation per 128-bit block), then the domain-separation bit flips — visibly altering the last word of the state (x4).
4. The plaintext is XORed into the rate to produce ciphertext, block by block, with an 8-round permutation between blocks.
5. Finalization runs the full 12 rounds one more time and produces a 128-bit tag. Decrypting recovers the plaintext exactly. If you flip even a single ciphertext byte (using the visualizer’s tamper-check), the recomputed tag mismatches, and decryption correctly rejects the message.

Why the Domain-Separation Bit Matters

Without a way to explicitly mark “associated data absorption has ended, plaintext absorption is beginning,” an attacker could shuffle bytes between the AD and plaintext portions of a message and produce a forged combination that still authenticates correctly. This is a known class of attack against naively designed sponge-based AEAD schemes.

Flipping a dedicated bit in the state between phases (specifically, flipping the most-significant bit of x4 by XORing it with the constant 0x8000000000000000) makes the two phases cryptographically distinguishable from the permutation’s perspective. This completely closes that vulnerability gap.

The Ascon Family Beyond AEAD

SP 800-232 standardizes more than just authenticated encryption. All functions are built from the exact same 320-bit permutation:

• Ascon-Hash256 — a general-purpose 256-bit hash function. It plays the same role as SHA-256 or SHA3-256 but is far cheaper on constrained hardware.
• Ascon-XOF128 / Ascon-CXOF128 — extendable-output functions (similar to SHAKE) that produce however many output bytes a protocol needs from a single absorbed input. CXOF128 additionally supports a customization string for domain separation between different applications sharing the same underlying function.

All four share the identical permutation and general sponge structure — only the initialization constants, rate, and round counts differ. This hardware-reuse benefit is massive: a single, tiny hardware module for the Ascon permutation can serve every symmetric cryptographic need (hashing, encryption, MACs, KDFs) a constrained device might have.

FAQ

Was there an actual bug caught while building this verification?

Yes — the first implementation attempt of the visualizer used a big-endian byte-to-word packing and an incorrect padding/domain-separation byte pattern, producing plausible-looking but entirely wrong output on all three official test vectors.

Fetching the reference implementation’s exact word.h (which handles endianness and bit interleaving uniquely for efficiency) and aead.c resolved it. We corrected our implementation to use the proper padding rule (a single 0x01 marker byte in the little-endian reference code, rather than 0x80) and separated domain phases properly by shifting 0x80 into the top byte of the specific word. After the fix, all official Known Answer Test (KAT) vectors matched byte-for-byte, and 500 additional round-trip and tamper-detection trials passed with zero failures.

Is Ascon post-quantum secure?

Ascon is not positioned as a “post-quantum” primitive, but as a symmetric algorithm, it benefits from the same rule of thumb as AES. Grover’s algorithm gives quantum computers only a quadratic speedup against symmetric ciphers (unlike the exponential speedup Shor’s algorithm gives against RSA/ECC). Therefore, Ascon-AEAD128’s 128-bit key still offers roughly 64 bits of quantum security. This is adequate for many resource-constrained purposes, which is why it was standardized independently of the PQC effort.

Why does initialization use 12 rounds but data absorption only use 8?

It’s a deliberate efficiency trade-off. Initialization and finalization happen exactly once per message, regardless of its length, so they can afford the extra security margin of full 12-round diffusion. Data-block absorption happens once per 128 bits of input, so keeping it at 8 rounds meaningfully speeds up encrypting longer messages without compromising the scheme’s proven security bounds.

References

1. Dobraunig, C., Eichlseder, M., Mendel, F., Schläffer, M. “Ascon v1.2: Lightweight Authenticated Encryption and Hashing.” Journal of Cryptology, 2021.

2. NIST. “Ascon-Based Lightweight Cryptography Standards for Constrained Devices.” SP 800-232, August 2025. DOI: 10.6028/NIST.SP.800-232

3. Ascon Team. “Ascon — Lightweight Authenticated Encryption & Hashing.” Available at: https://ascon.isec.tugraz.at/

4. Ascon Team. Reference implementation and official test vectors. Available at: https://github.com/ascon/ascon-c