On August 13, 2025, the National Institute of Standards and Technology quietly closed out a 50-year run. NIST Special Publication 800-232 made Ascon, not a descendant of AES, the first lightweight cryptography standard built for the billions of small devices that can’t afford a full AES-GCM implementation. For engineers who’ve spent a career assuming AES is the only serious choice for authenticated encryption, that’s a bigger deal than the headline suggests.
This comparison breaks down AES-256-GCM against Ascon-AEAD128, the authenticated encryption function at the center of SP 800-232, across security margins, memory footprint, hardware dependence, and real deployment paths. Neither cipher replaces the other outright. The decision comes down to what runs the code: a server rack with AES-NI silicon, or a coin-cell sensor that has to stretch a few kilobytes of flash across a decade of battery life.
Why This Comparison Matters Now
AES-GCM has been the default authenticated encryption mode since NIST standardized it in SP 800-38D back in 2007. It’s fast on anything with AES-NI, battle-tested across two decades of TLS traffic, and it’s not going anywhere. What changed in 2025 is that NIST finally shipped an alternative purpose-built for devices where AES-GCM’s two-part design, an AES block cipher plus GHASH authentication, costs too much in code size and RAM.
Ascon-AEAD128 is that alternative. NIST picked it in February 2023 after a multi-year public competition that started with 57 submissions, and the final standard landed in August 2025 as SP 800-232, titled “Ascon-Based Lightweight Cryptography Standards for Constrained Devices.” The target use cases are specific: RFID tags, medical implants, industrial sensors, and the kind of 8-bit or low-end 32-bit microcontrollers that power most of the Internet of Things but rarely get discussed in mainstream crypto comparisons.
The timing matters for a second reason. IoT device counts keep climbing into the tens of billions, and a growing share of those devices ship with no AES hardware acceleration at all. Every one of them still needs authenticated encryption for firmware updates, sensor telemetry, and device-to-cloud handshakes. Until now, the honest answer for a memory-starved microcontroller was “use AES-GCM anyway and eat the cost.” NIST just gave engineers a standardized alternative that was designed around that exact constraint from day one.
What Is AES-256-GCM?
AES-256-GCM pairs the Advanced Encryption Standard, a 128-bit block cipher operating with a 256-bit key, with Galois/Counter Mode, an authenticated encryption mode that adds integrity verification on top of confidentiality. NIST standardized GCM in SP 800-38D, and it’s now the default cipher suite in TLS 1.3 (as TLS_AES_256_GCM_SHA384), IPsec, most VPN stacks, and the majority of cloud storage encryption.
The design splits work into two jobs. AES encrypts data in counter mode, turning the block cipher into a stream cipher. GHASH, a polynomial authentication function running in GF(2^128), computes the authentication tag over the ciphertext and any associated data. On a modern x86-64 or ARMv8 CPU with AES-NI and carry-less multiplication (CLMUL/PMULL) instructions, both halves run in hardware and the combined throughput is excellent. Take away that hardware, and GHASH’s finite-field multiplication becomes one of the more expensive parts of the whole operation on an 8-bit or low-end 32-bit core.
AES-256-GCM’s security rests on 256-bit key strength and a strict requirement: never reuse a nonce with the same key. Nonce reuse under GCM doesn’t just weaken the cipher, it can expose the authentication key entirely, which is why implementations like Go’s crypto/cipher and OpenSSL’s EVP interface enforce 96-bit random or counter-based nonces by default.
What Is Ascon-AEAD128?
Ascon-AEAD128 is the authenticated encryption function inside NIST SP 800-232, finalized in August 2025. It was designed in 2014 at the Institute for Applied Information Processing and Communications (IAIK) at Graz University of Technology by Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer, and NIST selected it as the lightweight cryptography competition winner in February 2023 after evaluating it against finalists including Sparkle, Xoodyak, TinyJAMBU, and GIFT-COFB.
Instead of combining a block cipher with a separate authentication function, Ascon runs everything through a single permutation over a 320-bit internal state, split into a 128-bit rate (where data is absorbed and emitted) and a 192-bit capacity (which provides the security margin). That sponge-like structure is the same conceptual family as SHA-3, and it means one compact building block can serve encryption, authentication, hashing, and extendable-output functions without needing four separate code paths. The SP 800-232 family actually ships four algorithms: Ascon-AEAD128 for authenticated encryption, Ascon-Hash256 for fixed-length hashing, Ascon-XOF128 for variable-length output, and Ascon-CXOF128, a customizable XOF for domain separation.
Ascon-AEAD128 uses a 128-bit key and produces a 128-bit authentication tag, giving it a 128-bit security strength in the single-key setting, the same practical security class as AES-128-GCM rather than AES-256. That’s a meaningful tradeoff: Ascon isn’t trying to match AES-256’s larger key size, it’s trying to deliver AES-128-equivalent security at a fraction of the code size and memory footprint.
How Ascon Won: Inside NIST’s Lightweight Cryptography Competition
Ascon didn’t appear out of nowhere in 2025. It’s the product of a competition NIST ran for four years, structured the same way the agency ran the AES competition in the late 1990s and the SHA-3 and post-quantum competitions since. NIST opened the call for submissions in 2018 and received 57 candidate algorithms by the February 2019 deadline. Fifty-six were accepted as first-round candidates in April 2019, and after four months of public cryptanalysis, NIST narrowed the field to 32 round-two candidates, announced on August 30, 2019.
Round two ran for roughly a year and a half, with cryptographers worldwide hammering on the surviving designs for weaknesses and benchmarking them on real hardware. In March 2021, NIST cut the field to ten finalists: Ascon, Elephant, GIFT-COFB, Grain-128AEAD, ISAP, PHOTON-Beetle, Romulus, Sparkle, TinyJAMBU, and Xoodyak. That final round, which combined deeper security analysis with extensive performance evaluation across embedded platforms, ran almost two more years before NIST announced its decision.
On February 7, 2023, NIST mathematicians Kerry McKay and Meltem Sönmez Turan announced Ascon as the winner. The agency’s public explanation, later detailed in NIST IR 8454, credited Ascon’s combination of strong security margins with consistently competitive performance across the full range of tested hardware, from 8-bit microcontrollers to 64-bit server processors, as the deciding factor over close competitors like Xoodyak and Sparkle. It then took another two and a half years of drafting, public comment, and revision before the design became a final, citable federal standard as SP 800-232 in August 2025.
| Milestone | Date |
|---|---|
| Call for submissions opens | 2018 |
| 57 candidate algorithms submitted | February 2019 |
| 56 accepted as Round 1 candidates | April 2019 |
| 32 candidates advance to Round 2 | August 30, 2019 |
| 10 finalists announced (Ascon among them) | March 2021 |
| NIST selects Ascon as the winning family | February 7, 2023 |
| SP 800-232 published as a final standard | August 13, 2025 |
That seven-year arc matters for anyone deciding whether to trust Ascon in production. Unlike a cipher a single vendor rolled out last quarter, Ascon has been through the same adversarial public review process that produced AES, SHA-3, and the ML-KEM/ML-DSA post-quantum standards: years of open cryptanalysis from independent researchers, competing submission teams actively looking for flaws in rival designs, and a federal agency that had every incentive to pick the most defensible option rather than the fastest one to market.
Full Specifications Comparison
The table below lays out the core technical parameters for both ciphers, sourced from NIST SP 800-38D, NIST SP 800-232, and the TLS 1.3 specification (RFC 8446).
| Specification | AES-256-GCM | Ascon-AEAD128 |
|---|---|---|
| Standard | NIST SP 800-38D (2007) | NIST SP 800-232 (August 2025) |
| Design type | Block cipher (AES) + GHASH authentication | Single 320-bit permutation (sponge construction) |
| Key size | 256 bits | 128 bits |
| Security strength | 256-bit (classical) | 128-bit (single-key setting) |
| Internal state | 128-bit block, processed in counter mode | 320-bit state (128-bit rate / 192-bit capacity) |
| Authentication tag | 128 bits (typical) | 128 bits |
| Nonce size | 96 bits (recommended) | 128 bits |
| Hardware acceleration | AES-NI, ARMv8 Crypto Extensions, PMULL/CLMUL | None standardized yet; software-first design |
| Companion functions | Separate standards (SHA-2/SHA-3 for hashing) | Ascon-Hash256, Ascon-XOF128, Ascon-CXOF128 (same family) |
| Primary target hardware | Servers, laptops, phones with crypto acceleration | 8-bit/low-end 32-bit MCUs, RFID, sensors, implants |
| Designers | Joan Daemen, Vincent Rijmen (Rijndael, 1998) | Dobraunig, Eichlseder, Mendel, Schläffer (IAIK/TU Graz, 2014) |
| TLS 1.3 cipher suite | TLS_AES_256_GCM_SHA384 | Not yet a standardized TLS 1.3 suite |
| Licensing | Royalty-free NIST standard | Royalty-free NIST standard, reference code public domain |
Benchmark Data From Three Sources
Performance claims in this space get muddled fast because “faster” depends entirely on whether the target chip has AES hardware acceleration. Three independent evaluation efforts give a consistent picture even without one universal cycles-per-byte table.
NIST’s own finalist evaluation (NIST IR 8454, “Status Report on the Finalists of the NIST Lightweight Cryptography Standardization Process”) is explicit on the split: on platforms where AES-NI instructions are available, AES-GCM outperforms all the lightweight finalists, Ascon included. On 8-bit AVR, 32-bit ARM Cortex-M3, and other microcontroller platforms without that hardware, Ascon was one of the consistent top performers across both the first and second rounds of benchmarking.
The Ascon team’s own status update, submitted to NIST during the finalist round, cites third-party benchmarks showing Ascon running faster than AES-GCM across a wide range of platforms from 8-bit to 64-bit. The team credits this to Ascon’s single round-function design, which avoids the separate block-cipher-plus-polynomial-hash structure that AES-GCM needs for authentication.
NIST IR 8369, the second-round status report, ran software benchmarks across 8-bit AVR, 32-bit ARM Cortex-M3 and M7, and other embedded targets, measuring ROM, RAM, and execution speed. Ascon placed among the small group of finalists, alongside GIFT-COFB, TinyJAMBU, and Xoodyak, that consistently ranked as top performers on both code size and speed metrics on those constrained platforms.
The consistent takeaway across all three sources: AES-GCM wins decisively wherever AES-NI or ARMv8 Crypto Extensions exist in silicon. Ascon wins on bare-metal microcontrollers that have no such hardware, which describes a large share of deployed IoT sensors, RFID tags, and battery-powered devices. Neither source provides a single universal cycles-per-byte figure that holds across every chip family, and vendors evaluating a migration should run NIST’s open benchmarking framework (part of the SUPERCOP/FELICS toolchain referenced in NIST’s lightweight cryptography project) on their actual target hardware rather than relying on a single published number.
// Illustrative only -- always benchmark on your actual target hardware.
// AES-256-GCM encryption with Go's standard library (hardware-accelerated path)
block, err := aes.NewCipher(key256) // 32-byte key
if err != nil { return err }
gcm, err := cipher.NewGCM(block)
if err != nil { return err }
nonce := make([]byte, gcm.NonceSize()) // 12 bytes
ciphertext := gcm.Seal(nil, nonce, plaintext, associatedData)Security Model: What Each Cipher Actually Protects Against
Both ciphers are authenticated encryption with associated data (AEAD) constructions, meaning they protect confidentiality and integrity in a single pass. The differences that matter show up in the failure modes.
AES-256-GCM’s biggest operational risk is nonce reuse. Because GCM derives its authentication key from the cipher and nonce, reusing a 96-bit nonce under the same key doesn’t just leak plaintext XOR patterns the way a stream cipher would, it can let an attacker recover the GHASH authentication key outright and forge valid ciphertexts. This is a well-documented, implementation-level risk rather than a flaw in the algorithm itself, and it’s why libraries like libsodium and BoringSSL push developers toward random or strictly incrementing counter nonces with enforced uniqueness checks.
Ascon-AEAD128 uses a 128-bit nonce, giving considerably more room before birthday-bound collision risk becomes a practical concern, and the permutation-based design avoids the specific polynomial-key-recovery failure mode that GCM’s GHASH construction has. Ascon is still nonce-based, though, so it doesn’t eliminate the general discipline of unique nonces per key. It just removes one particular catastrophic failure class.
On raw security strength, AES-256-GCM’s 256-bit key gives it a larger classical security margin than Ascon-AEAD128’s 128-bit key. For most threat models that’s academic, 128-bit security is considered computationally infeasible to brute-force with any foreseeable technology, but it matters for applications with explicit 256-bit security requirements, such as certain government and defense procurement standards that mandate AES-256 specifically.
On the post-quantum question, neither cipher is a post-quantum algorithm in the way ML-KEM or ML-DSA are. Both are symmetric constructions, so their quantum exposure runs through Grover’s algorithm, which theoretically halves the effective key-search security (AES-256 drops to roughly 128-bit quantum security, Ascon-AEAD128’s 128-bit key would drop to roughly 64-bit quantum security). That’s one more reason organizations building for a post-quantum horizon tend to pair AES-256 with longer-term symmetric security margins, while Ascon’s lighter footprint is aimed at devices where the realistic threat model is resource-constrained physical attackers and firmware-level adversaries, not nation-state quantum computing budgets.
Side-Channel Resistance and Physical Security
Cycles-per-byte and RAM footprint tell half the story for constrained devices. The other half is physical security: a smart card, RFID tag, or implant sitting in an attacker’s hand is exposed to power analysis and fault-injection attacks that a cloud server never has to worry about. NIST’s evaluation criteria for the lightweight cryptography competition explicitly weighed how well each finalist supported masked, side-channel-resistant implementations, not just raw speed, because the target devices are the ones most likely to end up physically in an adversary’s possession.
AES has a deep, mature body of research on masked and threshold implementations going back over two decades, which is a real advantage: when a new side-channel attack technique surfaces, there’s a large existing toolkit of countermeasures to draw from. Ascon’s permutation-based design was built with protected implementations in mind from the start, and its submission team specifically targeted efficient masking as a design goal, since a cipher that’s cheap to implement in plain software but expensive to mask defeats the purpose for a device that genuinely needs both small code size and resistance to power analysis. NIST’s finalist evaluation weighed exactly this tradeoff, and it’s one of the technical reasons Ascon edged out designs that were faster in an unprotected setting but harder to mask efficiently.
Neither cipher is a silver bullet here. Any symmetric primitive, AES or Ascon, needs implementation-specific countermeasures against power analysis and fault injection. The algorithm choice determines how expensive those countermeasures are to add, not whether they’re needed at all. For a device that never leaves a locked data center, this entire category of risk is close to irrelevant. For an RFID tag riding in someone’s wallet or a sensor bolted to public infrastructure, it’s often the deciding factor.
Library and Tooling Ecosystem
AES-256-GCM’s tooling advantage is hard to overstate. It ships in OpenSSL, BoringSSL, LibreSSL, mbed TLS, libsodium, and every major language’s standard or near-standard crypto library, with hardware-accelerated code paths that have been profiled, fuzzed, and patched for over a decade. Debugging a nonce-reuse bug or a malformed associated-data field has a mountain of Stack Overflow threads, conference talks, and vendor documentation behind it.
Ascon’s ecosystem is where its one-year head start as a final standard shows. The Ascon team’s own reference implementations, published alongside the NIST submission and now aligned with SP 800-232’s final parameters, are the most authoritative starting point, and NIST’s own test vectors are the baseline any implementation has to pass. As of the standard’s first year, mainstream general-purpose libraries like OpenSSL and BoringSSL had not yet merged production Ascon support, and embedded-focused libraries were in earlier stages of adding it. That’s a normal lag for a standard that’s barely cleared its first birthday. AES itself took a few years after its 2001 standardization before it was the default choice everywhere. Teams evaluating Ascon today should expect to work closer to the reference implementation and official test vectors than they would with a cipher that’s had two decades of library polish.
Memory Footprint and Hardware Dependence
This is where the two ciphers diverge most clearly in purpose. AES-256-GCM was never designed with an 8-bit microcontroller in mind. It was designed to replace DES on general-purpose computing hardware in the late 1990s, long before IoT was a product category. Running AES-GCM without hardware acceleration means implementing both the AES round function (S-box substitution, ShiftRows, MixColumns) and GHASH’s GF(2^128) multiplication in software, which costs meaningfully more flash and RAM than a design built from one permutation.
Ascon-AEAD128 was built from the ground up for constrained devices. NIST’s evaluation explicitly benchmarked finalists against the target of outperforming AES-GCM and SHA-2 specifically on 8-bit AVR, 32-bit Cortex-M3/M7, Tensilica Xtensa, and RISC-V platforms, and Ascon was one of the handful of designs (alongside Xoodyak, TinyJAMBU, GIFT-COFB, and Sparkle) that consistently delivered smaller code size and lower RAM use on those exact targets. A smaller flash and RAM footprint has a real downstream effect for hardware engineers: it widens the pool of microcontrollers that can run authenticated encryption at all without upgrading to a larger, more expensive part.
The practical rule both NIST and the Ascon team land on is the same: on a chip with AES-NI or ARMv8 Crypto Extensions, AES-GCM wins on throughput every time. On a chip without that hardware, which includes most sub-$2 microcontrollers used in sensors and RFID tags, Ascon’s software-only design has the advantage.
Beyond Encryption: Ascon-Hash256 and the Rest of the Family
AES-256-GCM only solves the encryption-and-authentication half of a device’s cryptographic needs. Firmware signing, sensor data integrity checks, and secure boot all also need a hash function, which on constrained hardware usually means a separate SHA-256 or SHA-3 implementation sitting alongside AES in flash. That’s a second code path, a second set of test vectors, and a second attack surface to maintain.
SP 800-232 sidesteps that by building all four of its algorithms from the same 320-bit permutation. Ascon-Hash256 produces a 256-bit digest from that same core operation, Ascon-XOF128 generates an arbitrary-length output for applications like key derivation, and Ascon-CXOF128 adds a customization string input so two applications using the same construction can be cryptographically domain-separated without needing an entirely separate primitive. For a microcontroller that needs both authenticated encryption and a hash function, that shared design can mean implementing and verifying one permutation instead of two unrelated algorithms, which is a direct, compounding reduction in code size, test surface, and audit scope on top of whatever gains Ascon-AEAD128 alone delivers over AES-GCM.
That shared-primitive design is also why Ascon’s selection matters beyond the AES-GCM comparison specifically. A project evaluating SHA-256 against SHA-3 for an embedded hashing need, or looking at HMAC alternatives for a constrained device, now has a third option in Ascon-Hash256 and Ascon-XOF128 that wasn’t standardized a year ago, built on a primitive that’s already been through the same NIST competition and cryptanalysis process as the AEAD function.
Adoption and Total Cost Comparison
Neither cipher carries a license fee. Both are royalty-free NIST standards, and Ascon’s reference implementation is released into the public domain. The real cost difference shows up in engineering and hardware spend, not licensing.
| Cost factor | AES-256-GCM | Ascon-AEAD128 |
|---|---|---|
| Algorithm licensing | Free, royalty-free NIST standard | Free, royalty-free NIST standard, public domain reference code |
| Library availability | OpenSSL, BoringSSL, LibreSSL, libsodium, mbed TLS (all free, open source) | Reference implementations available; broad commercial library support still rolling out post-standardization |
| Hardware acceleration need | Best ROI with AES-NI/ARMv8 chips (already common in servers, phones, most modern laptops) | No dedicated hardware required; runs efficiently in software on cheaper, smaller microcontrollers |
| Engineering migration cost | Low if already using TLS 1.3 or a modern crypto library | Moderate: new API surface, fewer battle-tested production libraries as of late 2025 |
| Audit and compliance maturity | Two decades of FIPS validation, Common Criteria, and third-party audits | Standardized August 2025; FIPS validation and auditor familiarity still building |
| Best-fit deployment | Cloud, TLS, VPN, server-to-server, anywhere with AES-NI | IoT sensors, RFID, medical implants, battery-powered edge devices |
The compliance line matters more than it looks. AES-256-GCM has FIPS 140-3 validated modules across essentially every major cloud provider and HSM vendor. Ascon-AEAD128 only became a final NIST standard in August 2025, so FIPS validation pipelines, auditor familiarity, and penetration-testing tooling are still catching up. Teams in regulated industries should expect AES-256-GCM to remain the safer compliance choice for at least the next audit cycle or two, even on projects where Ascon would be the better technical fit.
Real-World Deployment Examples
Five scenarios illustrate where each cipher is already winning or positioned to win:
TLS 1.3 web traffic. AES-256-GCM, as the TLS_AES_256_GCM_SHA384 cipher suite, remains a default or near-default choice for HTTPS traffic on servers with AES-NI, which covers essentially all modern cloud infrastructure and CDN edge nodes.
Smart home sensors. A battery-powered temperature or motion sensor running an 8-bit AVR or entry-level Cortex-M0 core, with no AES hardware and a tight flash budget, is exactly the profile NIST had in mind when it scoped the lightweight cryptography competition that produced Ascon.
Medical implants. NIST’s own announcement for SP 800-232 specifically names medical implants as a target use case, where power budget and chip size leave no room for a full AES-GCM software stack plus a separate hash function.
RFID and supply-chain tags. Passive RFID tags harvest power from the reader’s radio signal and have microwatt-level energy budgets. This is the use case most directly cited in NIST’s lightweight cryptography project scope, and it’s one where AES-GCM’s software footprint has historically been considered impractical.
Cloud storage and database encryption at rest. Large-scale storage encryption, where throughput is dominated by AES-NI-capable server CPUs, continues to favor AES-256-GCM, since there’s no hardware-acceleration gap to close and no code-size constraint to solve for.
Industrial sensor networks. Factory floor sensors monitoring vibration, temperature, or pressure often run on 32-bit microcontrollers chosen for cost and power draw rather than cryptographic acceleration, which places them squarely in the category NIST evaluated Ascon against when it benchmarked Cortex-M3 and Cortex-M7 platforms during the competition’s second round.
Firmware-over-the-air updates for legacy embedded fleets. Devices already deployed with 8-bit AVR or entry-level ARM cores that need authenticated firmware updates face the same AES-GCM software-cost problem NIST’s lightweight cryptography project was built to solve, making this one of the clearer near-term candidates for an Ascon evaluation once vendor tooling matures.
Use-Case Recommendations
Six scenarios, mapped to the cipher that fits the constraint rather than the hype cycle:
- Cloud servers, TLS termination, VPN gateways: Stick with AES-256-GCM. AES-NI is standard on virtually every cloud instance type since the mid-2010s, and the FIPS-validated library ecosystem is mature.
- Battery-powered IoT sensors without AES hardware: Evaluate Ascon-AEAD128. The smaller code and RAM footprint can be the difference between fitting on a cheaper microcontroller or needing a pricier part.
- Medical implants and RFID tags: Ascon-AEAD128 is the use case NIST designed it for; the power and silicon budget make AES-GCM’s two-component design a harder fit.
- Regulated industries requiring FIPS-validated crypto today: AES-256-GCM, until Ascon implementations complete FIPS 140-3 validation cycles.
- New embedded product lines starting design in 2026 or later: Prototype with Ascon-AEAD128 alongside AES-GCM and benchmark both on the actual target silicon before committing, since library maturity is improving month over month post-standardization.
- Mixed fleets with both server and constrained-device components: Run AES-256-GCM on the server side and evaluate Ascon-AEAD128 for the edge devices reporting into it; the two are not mutually exclusive within one system architecture.
Migration Guide: Moving From AES-GCM to Ascon
For teams on constrained hardware who want to evaluate Ascon-AEAD128 as a replacement for software AES-GCM, the practical path looks like this.
- Confirm the constraint is real. Profile your current AES-GCM implementation’s actual flash, RAM, and cycle cost on the target chip before assuming you need a change. If the device already has AES-NI or an ARMv8 crypto extension, there’s no migration case to make, and the engineering time is better spent elsewhere.
- Pull the reference implementation. NIST’s SP 800-232 publication and the Ascon team’s reference code are the canonical starting points. Treat third-party ports as unverified until you’ve checked them against test vectors. Several embedded toolchain vendors have begun shipping early ports, but given the standard’s age, confirm each one traces back to the final SP 800-232 parameters rather than an earlier draft or competition-era specification.
- Validate against official test vectors. SP 800-232 publishes known-answer tests for Ascon-AEAD128, Ascon-Hash256, Ascon-XOF128, and Ascon-CXOF128. Run every one before trusting a build, and keep the test harness in your CI pipeline permanently rather than treating it as a one-time check.
- Re-architect nonce handling. Ascon-AEAD128 uses a 128-bit nonce rather than GCM’s 96-bit nonce. Audit any code that assumes a specific nonce length, particularly serialization formats, wire protocols, and any hardcoded buffer sizes carried over from an AES-GCM implementation.
- Benchmark on actual silicon, not a reference board. Cycle counts from NIST’s evaluation platforms (AVR, Cortex-M3/M7) are a starting point, not a guarantee for your specific MCU, compiler, and optimization flags. Compiler version and optimization level alone can shift embedded crypto benchmarks by a meaningful margin, so re-run the comparison on your actual build chain.
- Plan for a transition period, not a flash cut. Devices already in the field running AES-GCM firmware will need a staged rollout. Protocol versioning should allow both ciphers during the changeover so that a fleet with mixed firmware versions can still interoperate.
- Track FIPS validation status before shipping into regulated markets. If the end product needs FIPS 140-3 certification, confirm the specific Ascon implementation has completed that process, since as of this standard’s first year that process is still maturing across vendors, and shipping an uncertified implementation into a regulated market can stall a product launch.
Pros and Cons
AES-256-GCM advantages: two decades of cryptanalysis and real-world deployment, near-universal hardware acceleration on servers and phones, mature FIPS-validated library ecosystem, 256-bit security margin, and default status in TLS 1.3, IPsec, and most VPN stacks.
AES-256-GCM drawbacks: software-only implementations are comparatively expensive in code size and cycles on 8-bit and entry-level 32-bit microcontrollers, GHASH’s nonce-reuse failure mode is unforgiving, and the two-component design (block cipher plus separate authentication function) adds complexity that constrained devices can’t always absorb.
Ascon-AEAD128 advantages: purpose-built for 8-bit and low-end 32-bit microcontrollers, smaller code and RAM footprint than software AES-GCM on the platforms NIST benchmarked, one compact permutation covers encryption, hashing, and XOF needs, and it’s a brand-new NIST standard with no legacy baggage.
Ascon-AEAD128 drawbacks: 128-bit rather than 256-bit key strength, no dedicated hardware acceleration path standardized yet, a much smaller library and tooling ecosystem since the standard is barely a year old, and FIPS validation and compliance-auditor familiarity are still catching up.
The Verdict
AES-256-GCM remains the right default for anything that runs on server-class or modern mobile hardware, which is still the overwhelming majority of encrypted traffic on the internet today. Its AES-NI acceleration, mature FIPS validation, and two decades of production hardening aren’t things a one-year-old standard can match yet, regardless of how elegant Ascon’s design is.
Ascon-AEAD128 wins a narrower but fast-growing lane: the billions of 8-bit and entry-level 32-bit devices that have no AES hardware and a flash budget measured in kilobytes. NIST built the entire lightweight cryptography competition around that exact gap, evaluated Ascon against competitors like Sparkle and Xoodyak on precisely those constrained platforms, and picked it because it consistently delivered smaller code and lower RAM use where it mattered. For an engineer shipping a new RFID tag, implant, or battery sensor design in 2026, that’s now a standardized, NIST-blessed option that didn’t exist a year ago.
The practical rule to carry forward: check for AES-NI or ARMv8 Crypto Extensions first. If it’s there, AES-256-GCM is still the easy, well-supported answer. If it’s not, and the target is genuinely constrained silicon, SP 800-232 just gave you a NIST standard built specifically for that problem.
Frequently Asked Questions
Is Ascon-AEAD128 a replacement for AES-256?
No. It’s a NIST standard for a different use case, constrained devices without AES hardware acceleration, and it uses a 128-bit key rather than a 256-bit one. AES-256-GCM remains the better choice anywhere AES-NI hardware exists.
When did NIST finalize the Ascon standard?
NIST published SP 800-232 as a final standard on August 13, 2025, after selecting Ascon as the lightweight cryptography competition winner in February 2023.
Is Ascon post-quantum secure?
No more or less than AES. Both are symmetric ciphers whose quantum exposure comes from Grover’s algorithm, which theoretically halves effective key-search security. Neither is a post-quantum algorithm in the sense that ML-KEM or ML-DSA are. Those target the separate problem of public-key cryptography breaking under Shor’s algorithm.
Can I use Ascon-AEAD128 in TLS today?
Not as a standardized TLS 1.3 cipher suite yet. TLS 1.3 currently defines AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, and two AES-CCM suites under RFC 8446. Ascon adoption in TLS would require its own IETF standardization track.
Does Ascon need special hardware to run fast?
No, and that’s the point. Ascon-AEAD128 was explicitly designed to run efficiently in software, without dedicated acceleration, which is why it targets devices that can’t economically add AES-NI-equivalent silicon.
Who designed Ascon?
Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer, working at the Institute for Applied Information Processing and Communications (IAIK) at Graz University of Technology, first published the design in 2014.
What other algorithms are in the Ascon family besides AEAD?
SP 800-232 also standardizes Ascon-Hash256 (a 256-bit hash function), Ascon-XOF128 (an extendable-output function), and Ascon-CXOF128 (a customizable extendable-output function), all built from the same 320-bit permutation.
Should I switch my existing product from AES-GCM to Ascon right now?
Only if your device genuinely lacks AES hardware acceleration and is flash- or RAM-constrained enough that the difference matters, and only after benchmarking both ciphers on your actual target silicon. If your platform has AES-NI or ARMv8 Crypto Extensions, there’s no performance case for switching.
What were the other finalists NIST considered instead of Ascon?
Nine other designs reached the final round: Elephant, GIFT-COFB, Grain-128AEAD, ISAP, PHOTON-Beetle, Romulus, Sparkle, TinyJAMBU, and Xoodyak. NIST’s evaluation in IR 8454 found Ascon offered the strongest overall balance of security margin and performance across the full range of tested hardware.
Does Ascon-AEAD128 work the same way as ChaCha20-Poly1305?
No, even though both are software-friendly alternatives to AES-GCM. ChaCha20-Poly1305 combines a stream cipher with a separate polynomial authenticator and targets general-purpose CPUs without AES hardware, such as older mobile chips. Ascon-AEAD128 uses a single sponge-based permutation and was benchmarked specifically against 8-bit and low-end 32-bit microcontrollers, a smaller and more constrained hardware class than ChaCha20-Poly1305’s typical deployment targets.
