Key takeaways
- Ascon's design lineage predates NIST's involvement.
- Key generation (R1): keys and any nonce-masking key must be generated per SP 800-133 using an approved random bit generator with at least 128-bit security strength, and must not be reused for other purposes.
- Per Section 6, implementations can be tested for conformance under NIST's Cryptographic Module Validation Program, with example test vectors available through the Cryptographic Algorithm Validation Program (CAVP).
- Use nonce masking if your device can't guarantee unique nonces — it costs an extra 128-bit key but removes the multi-key security degradation that plain Ascon-AEAD128 has when nonce uniqueness can't be fully trusted.
NIST SP 800-232, "Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable Output Functions," is a NIST Special Publication finalized in August 2025 that specifies four cryptographic algorithms built on the Ascon family, purpose-built for devices too resource-constrained to run conventional AES-GCM or SHA-3 efficiently. Authored by Meltem Sönmez Turan, Kerry A. McKay, Jinkeon Kang and John Kelsey of NIST's Computer Security Division with Donghoon Chang of Strativia, and approved by NIST's Editorial Review Board on 9 July 2025, it is the outcome of a NIST standardization effort that started in 2015 and selected the Ascon family in February 2023. Like other NIST SP 800-series guidance, it is a U.S. government work not subject to copyright and may be used voluntarily by any organization.
The problem this solves: AES and SHA-3 aren't always a good fit
Per the standard's own Introduction, NIST started its Lightweight Cryptography Standardization Process in 2015 "to develop cryptographic standards that are suitable for constrained environments in which conventional cryptographic standards (e.g., AES-GCM, SHA-2 and SHA-3 hash function families) may be resource-intensive." The Abstract frames Ascon as designed to "offer a viable alternative when the Advanced Encryption Standard (AES) may not perform optimally" for devices such as "Internet of Things (IoT) devices, embedded systems, and low-power sensors." In its August 2025 announcement of the finalized standard, NIST named fitness trackers, smart appliances and medical implants as beneficiaries, stating the standard "provides a defense from cyberattacks for even the smallest of networked electronic devices," and quoted NIST computer scientist Kerry McKay, who co-led the project: "We encourage the use of this new lightweight cryptography standard wherever resource constraints have hindered the adoption of cryptography." SP 800-232 does not deprecate AES or SHA-3 — both remain the right default for systems that can afford them; it targets the specific gap where a device's power, memory or silicon budget makes that infeasible.
From a 2014 cipher competition entry to a NIST standard
Ascon's design lineage predates NIST's involvement. Designed by Christoph Dobraunig, Maria Eichlseder, Florian Mendel and Martin Schläffer, it was first submitted to the CAESAR competition (an independent academic effort to find authenticated-encryption schemes with advantages over AES-GCM) in 2014, and its Ascon-128/Ascon-128a variants were selected as the first choice for the lightweight authenticated-encryption use case when CAESAR's final portfolio was announced in February 2019. Separately, NIST's own Lightweight Cryptography Standardization Process ran a multi-round public evaluation starting in 2015, announced the selection of the Ascon family in February 2023, released a draft of SP 800-232 for public comment in November 2024, and published the final standard in August 2025.
SP 800-232 lists seven technical differences from the original Ascon v1.2 CAESAR submission, including:
| Change | What it means |
|---|---|
| AEAD variant chosen | Ascon-AEAD128 is based on the submission's ASCON-128a (not ASCON-128 or the 80-bit-key ASCON-80pq) |
| Round constants extended | Permutations now defined for up to 16 rounds (the submission defined only 6, 8 and 12) "to accommodate potential functionality extensions in the future" |
| Endianness switched | Big-endian in the submission, little-endian in the standard, "to improve performance on little-endian microcontrollers" |
| New implementation options | Tag truncation and nonce-masking were added, neither of which existed in the original submission |
The four algorithms
All four share the same underlying building block — the 320-bit, five-word Ascon permutation (used as Ascon-p[8], 8 rounds, or Ascon-p[12], 12 rounds) — which the standard notes lets one compact implementation support every function below rather than needing separate primitives for encryption and hashing.
| Algorithm | What it does | Key facts |
|---|---|---|
| Ascon-AEAD128 | Authenticated encryption with associated data (AEAD) | 128-bit key, 128-bit nonce, 128-bit tag; 128-bit rate / 192-bit capacity; 128-bit security strength in the single-key, nonce-respecting setting |
| Ascon-Hash256 | Fixed-length cryptographic hash | 256-bit digest; 64-bit rate / 256-bit capacity; 128-bit security strength against collision, preimage and second-preimage attacks |
| Ascon-XOF128 | Extendable-output function (XOF) — caller picks the output length | Security strength up to 128 bits, scaling with requested output length; shorter outputs are a prefix of longer ones for the same input |
| Ascon-CXOF128 | Customized XOF with a caller-supplied domain-separation string | Customization string up to 2048 bits (256 bytes); avoids the prefix relationship Ascon-XOF128 has across output lengths |
Ascon-AEAD128 is "online" and single-pass — per the standard, the i-th ciphertext block depends only on the key, nonce, associated data and the first i plaintext blocks — and all four algorithms are "inverse-free," meaning an implementation only ever needs the permutation in its forward direction, never its inverse, which is itself a meaningful code-size saving on constrained hardware.
Key-handling rules implementers can't skip (R1-R7)
Section 4.3 lists seven mandatory requirements ("shall") for Ascon-AEAD128 that matter as much as the algorithm choice itself:
Key generation (R1):keys and any nonce-masking key must be generated per SP 800-133 using an approved random bit generator with at least 128-bit security strength, and must not be reused for other purposes. Key secrecy (R2):the key — and, if nonce masking is used, the masked nonce — must be kept secret. Unique nonces (R3):nonces must never repeat under a given key. Minimum truncated-tag length (R4):a truncated tag must be at least 32 bits, and a length below 64 bits requires a documented risk analysis first; tag length must stay fixed for the life of the key. Decryption-failure limit (R5):for a tag of length λ between 64 and 128 bits, decryption failures under a fixed key must not exceed 2^(λ-32); for λ between 32 and 64 bits, failures should be limited to 1 unless a risk analysis justifies relaxing that, up to the same bound. Data limit (R6):total data processed under a single key (including the nonce) must not exceed 2^54 bytes. Key update (R7):the key must be rotated once the 2^54-byte data limit is reached, and should be rotated if the decryption-failure limit is reached.
Nonce reuse is the classic AEAD failure mode, and the standard is explicit that Ascon-AEAD128 degrades rather than catastrophically failing under accidental nonce reuse (Section 4.4.3) — but it still recommends the nonce-masking implementation option (an extra 128-bit key XORed into the nonce) specifically for applications where unique-nonce generation can't be guaranteed, since it preserves full 128-bit security in the multi-key setting where plain Ascon-AEAD128 would otherwise lose security proportional to the number of keys in use.
Conformance and what it isn't approved for
Per Section 6, implementations can be tested for conformance under NIST's Cryptographic Module Validation Program, with example test vectors available through the Cryptographic Algorithm Validation Program (CAVP). Two explicit limits worth flagging for implementers: Ascon-Hash256's use inside HMAC is not approved by this standard, and the same applies to Ascon-XOF128 and Ascon-CXOF128 — despite being approved as XOFs, they are not approved as general-purpose hash functions, even where their output characteristics might overlap.
A workable starting point
Reach for SP 800-232 only where AES-GCM/SHA-3 genuinely don't fit— a device with a general-purpose MCU and normal power budget gets no benefit from switching; this standard targets the specific case of RFID tags, passive sensors, medical implants and similarly constrained silicon. Treat R1-R7 as part of the specification, not optional hardening— nonce uniqueness (R3) and the data/key-rotation limits (R6-R7) are what the 128-bit security claims in Section 4.4 actually depend on; skipping them silently narrows the real security margin. Use nonce masking if your device can't guarantee unique nonces— it costs an extra 128-bit key but removes the multi-key security degradation that plain Ascon-AEAD128 has when nonce uniqueness can't be fully trusted. Don't put Ascon-Hash256, Ascon-XOF128 or Ascon-CXOF128 inside HMAC— the standard does not approve that combination; use an approved MAC construction instead if message authentication without full AEAD is the goal. Budget for conformance testing, not just correct math— CAVP test vectors exist specifically so an embedded implementation can be validated against the standard's exact byte-level specification (endianness, padding, initial values) before it ships.
SoftWSP's device and firmware security assessments review cryptographic implementation choices — including whether a constrained device's crypto stack matches a standard like SP 800-232 correctly rather than just scanning for known-CVE libraries: see Device & Firmware Security.
This guide summarizes NIST SP 800-232's own published text (Abstract, Introduction, Sections 1, 4 and 6) and NIST's public announcement of the finalized standard; it is not a substitute for the full standard or for cryptographic implementation review.
Sources
- NIST SP 800-232: Ascon-Based Lightweight Cryptography Standards for Constrained Devices — Authenticated Encryption, Hash, and Extendable Output Functions (Turan, McKay, Chang, Kang, Kelsey; August 2025; full text, Abstract, Introduction, Sections 1-6, Appendices A-B)
- NIST: SP 800-232 publication landing page (CSRC) — metadata, document history, related content
- NIST: "Lightweight Cryptography" standard to protect small devices finalized (August 2025 announcement — rationale, target devices, Kerry McKay quote, future roadmap)
- NIST Internal Report (IR) 8454: Status Report on the Final Round of the NIST Lightweight Cryptography Standardization Process (2023) — selection of the Ascon family
Frequently asked questions
What is NIST SP 800-232, and who wrote it?
NIST Special Publication 800-232, "Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable Output Functions," is a final NIST standard authored by Meltem Sönmez Turan, Kerry A. McKay, Jinkeon Kang and John Kelsey of NIST's Computer Security Division, with Donghoon Chang of Strativia, approved by the NIST Editorial Review Board on 9 July 2025 and published in August 2025 (DOI 10.6028/NIST.SP.800-232). Per its own Authority section, like other NIST SP 800-series guidance it "may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States" (attribution is appreciated, not required). The standard specifies four algorithms built on the Ascon family: Ascon-AEAD128 (authenticated encryption), Ascon-Hash256 (a fixed-length hash function), and two extendable-output functions, Ascon-XOF128 and Ascon-CXOF128.
Why does NIST need a separate "lightweight" cryptography standard when AES-GCM and SHA-3 already exist?
Per the standard's own Introduction, NIST initiated its Lightweight Cryptography Standardization Process in 2015 "to develop cryptographic standards that are suitable for constrained environments in which conventional cryptographic standards (e.g., AES-GCM, SHA-2 and SHA-3 hash function families) may be resource-intensive." The Abstract states the Ascon family was selected to "offer a viable alternative when the Advanced Encryption Standard (AES) may not perform optimally," for environments such as "Internet of Things (IoT) devices, embedded systems, and low-power sensors." In NIST's own August 2025 announcement of the finalized standard, the agency said it provides "a defense from cyberattacks for even the smallest of networked electronic devices," naming fitness trackers, RFID tags and medical implants as examples, and quoted NIST computer scientist Kerry McKay, who co-led the project: "We encourage the use of this new lightweight cryptography standard wherever resource constraints have hindered the adoption of cryptography." SP 800-232 does not replace or deprecate AES or SHA-3 for general-purpose use — it targets the specific case where those algorithms' resource footprint is the blocker.
How was the Ascon family selected, and what changed between the original design and this NIST standard?
Per SP 800-232's Introduction, Ascon (designed by Christoph Dobraunig, Maria Eichlseder, Florian Mendel and Martin Schläffer) was first submitted to the CAESAR competition in 2014, and its Ascon-128/Ascon-128a variants were selected as the first choice for the lightweight authenticated-encryption use case in CAESAR's final portfolio, announced February 2019. Separately, NIST ran its own multi-round Lightweight Cryptography Standardization Process starting in 2015, and in February 2023 announced the selection of the Ascon family for that effort; a draft of SP 800-232 was released for public comment in November 2024 before the final publication in August 2025. The standard itself lists seven technical differences from the original Ascon v1.2 submission, including: the standard's Ascon-AEAD128 is based on the submission's ASCON-128a variant specifically (not ASCON-128 or the 80-bit-key ASCON-80pq); round constants were extended to support up to 16 rounds (the submission defined only 6-, 8- and 12-round permutations) "to accommodate potential functionality extensions in the future"; the byte order was switched from big-endian to little-endian "to improve performance on little-endian microcontrollers"; and new truncation and nonce-masking implementation options were added that did not exist in the original submission.
What are the four algorithms, and what security strength does each provide?
Per Section 1: (1) Ascon-AEAD128 is a nonce-based authenticated-encryption-with-associated-data (AEAD) scheme using a 128-bit key and 128-bit nonce, offering 128-bit security strength for confidentiality and integrity in the single-key, nonce-respecting setting (Section 4.4.1), built on a 320-bit internal state with a 128-bit rate and 192-bit capacity. (2) Ascon-Hash256 is a hash function producing a fixed 256-bit digest with 128-bit security strength against collision, preimage and second-preimage attacks (Table 9), built on a 64-bit rate and 256-bit capacity. (3) Ascon-XOF128 is an extendable-output function (XOF) whose output length is chosen by the caller, with security strength up to 128 bits depending on the requested output length (per Table 9, collision resistance is min(output-length/2, 128) bits). (4) Ascon-CXOF128 is a customized XOF that adds a caller-supplied customization string (up to 2048 bits) for domain separation, so that two calls with the same message but different customization strings produce unrelated outputs. All four share the same 320-bit, five-word Ascon permutation family (Ascon-p[8] and Ascon-p[12], referring to 8 and 12 rounds) as their only underlying primitive, which the standard notes lets a single compact implementation support all four functions.
In this cluster
