Detailed Assessment of Hardware Implementations, Attacks and Countermeasures for the Ascon Authenticated Cipher

Electronics Letters LETTER Detailed Assessment of Hardware Implementations, Attacks and Countermeasures for the Ascon Authenticated Cipher Miguel Martín-González1,2Erica Tena-Sánchez1,2Francisco Eugenio Potestad-Ordóñez1,2Antonio J. Acosta1,3 1Instituto de Microelectrónica de Sevilla IMSE-CNM, CSIC/University of Seville, Sevilla, Spain 2Department of Electronics Technology, Escuela Politécnica Superior, University of Seville, Sevilla, Spain 3Department of Electronics and Electromagnetism, Faculty of Physics, University of Seville, Sevilla, Spain Correspondence: Miguel Martín-González ([email protected]) Received: 5 March 2025 Revised: 11 April 2025 Accepted: 14 April 2025 Funding: This work has been funded by the project Grant PID2020-116664RB-I00 funded by MCIN/AEI/10.13039/501100011033. Authors want to thank the SPIRS (Secure Platform for ICT Systems Rooted at the Silicon Manufacturing Process) Project with Grant Agreement No. 952622 under the European Union’s Horizon 2020 Research and Innovation Programme and the Ministerio de Asuntos Económicos y Transformación Digital through TSI-069100-2023-1 PERTE-Chip Chair Project, with NextGenerationEU funds. ABSTRACT The design and implementation of lightweight-oriented ciphers on hardware has turned into an urgent matter with the expansive field of Internet of Things (IoT) and the ever increasing presence of small electronic devices that require fast and secure communication in our modern world. In 2023, the Ascon cipher was selected as the new standard authenticated encryption with associated data (AEAD) algorithm for lightweight environments by the National Institute of Standards and Technology (NIST). This paper provides a full comparison and joint evaluation of the hardware implementations, attacks and countermeasures that have been proposed for Ascon since it was published, aiming to shed light on some open development paths in addition to enable the hardware designer to make better informed decisions. All in all, Ascon implementations tend to achieve great performance while staying lightweight, but unprotected implementations are vulnerable to hardware attacks, and some attacks can even dodge counter measures. The very promising Ascon cipher will surely thrive in the field of lightweight cryptography, but further work into the design of secure implementations is still needed, being this paper a great starting point for researchers and designers alike. 1 Introduction Nowadays, the vast majority of digital telecommunication devices employ ciphers when secure communication is required. However, many of the currently used cryptographic algorithms are too resource intensive to be usable in lightweight (LW) environments, where resources and power are highly limited. These constrained devices are increasingly common with the growing Internet of Things (IoT), so the development of LWoriented ciphers has lately been a very active field of study. No standard cipher for lightweight environments existed until the US National Institute of Standards and Technology (NIST) hosted the Lightweight Cryptography Standardisation project [1] in 2018, which concluded in 2023 with the selection of the Ascon cipher as the new standard authenticated encryption with associated data (AEAD) cipher for LW cryptography [2]. With a fixed standard, development efforts can be more focused and exhaustive. Ascon’s ultimate selection was due to its outstandingly attractive lightweight-oriented design, that is, its simplicity, its robustness against cryptanalysis and the few potential leakage points that could be exploitable by hardware attacks. Furthermore, Ascon was also previously selected as the primary choice for authenticated encryption in lightweight applications in the CAESAR competition, that ran from 2013 to 2019 [3]. This is an open access article under the terms of the Creative Commons Attribution License, which permits use, distribution and reproduction in any medium, provided the original work is properly cited. © 2025 The Author(s). Electronics Letters published by John Wiley & Sons Ltd on behalf of The Institution of Engineering and Technology. Electronics Letters,2025;61:e70260 https://doi.org/10.1049/ell2.70260 1of8 TABLE 1 Implementation schemes, relative expected performance and cost. Reference values are represented as ‘⋅’, relative increment as ‘↑’, and relative decrement as ‘↓’. Implementation scheme Area Power Latency Throughput Iterated/Recursive [8–19]⋅⋅ ⋅ ⋅ Serialised [8, 12, 18]↓↓ ↓↓ ↑ ↓↓ Unrolled [8, 12, 14, 17, 18, 20]↑↑ ↑↑ ↓ ↑↑ Pipelined [21]↑↑ ↑ ↑ However, even if a cipher is mathematically resistant to cryptanalysis, its hardware security is not guaranteed, as physical information leakage through side channels on physical implementations may be exploitable by hardware attacks. Many viable attacks on ciphers have been developed these past few decades [4], but even if many countermeasure schemes have been proposed against them, there is no general countermeasure able to neutralise all of them simultaneously [5]. This paper aims to provide a full comparison and qualitative evaluation of the published Ascon hardware implementations in literature so far, the hardware attacks performed on them, and the proposed countermeasures against said attacks, updating the work in [6] with full comparisons and further analysis. 2The Ascon Cipher Ascon has been designed with LW environments in mind [2], where resources are scarce. Its simplicity provides great freedom to follow different implementation schemes while at the same time managing to maintain great performance and asking in return minimal implementation sacrifices. As a symmetric AEAD algorithm, it makes use of symmetric secret keys, as well as a public nonce per message and message tags for authentication. It is able to encipher/decipher arbitrary-length messages with or without associated data. The interested reader may refer to the official documentation [2] for an exhaustive description of Ascon’s permutation and its algorithmic structure. The NIST standard specifications [7] are still a draft as of the writing of this paper. Some naming conventions are modified in it, but the original names from Ascon documentation [2] will be maintained here for better compatibility with the referenced data. Correspondence between names is stated in the standard specifications draft [7]. That being said, Ascon is in fact an algorithmic family able to provide AEAD and hashing. This paper targets Ascon-128 (named Ascon-AEAD128 in the new standard), the default member of the Ascon AEAD family. All family members share most of their internal structure, so conclusions derived here should be mostly portable amongst them. 3HW Implementations To the best of our knowledge, 72 FPGA and 31 ASIC Ascon-128 implementations have been published on literature so far. This section delves a little on the different implementation schemes usable on Ascon, and provides some comparative metrics in order to enable the designer to make more informed decisions when deciding a proper scheme to follow. As a block cipher, Ascon allows the hardware designer to choose several distinct implementation schemes, some of them prioritise certain features while others are able to strike balance between some or all of them. Table 1shows the generic schemes that could be established, with their associated relative expected costs and performance metrics. It must be taken into account that, in general, these schemes are not mutually exclusive and can be applied in a gradual manner. They are briefly described as follows: ∙Iterative/recursive implementations perform permutation rounds iteratively until the full cipher phase is complete. This is usually the most balanced scheme so it is taken as a reference in Table 1. ∙Serialisation consists of reducing the data block size processed in parallel. This is very attractive when resource minimisation is required, but performance suffers consequently with reduced parallelism. ∙Loop unrolling allows iteration counts to be reduced, full unrolling can even dispose of recursivity, being able to perform a complete cipher phase combinationally. This allows extreme throughput potential, but at a massive area and power cost. ∙Pipelining consists of segmenting combinational stages with register layers in between, which may provide a significant increase in throughput as idle stages can be reduced, at the expense of a higher sensitivity to clock glitches. A sole pipelined implementations have been confirmed in literature, but it may be possible some of them were left unaccounted for, minute implementation details are not always disclosed by authors. Most implementations are iterated as only full unrolling can prevent the need for recursiveness. Fully unrolled implementation were proposed in [14]and[12], but their area requirements were on average a full order of magnitude greater than the implementations shown here. It could be argued that, Ascon being a LW-oriented cipher, full unrolling is contradictory to this end, the associated area costs are insurmountable when resources are few. Figure 1shows several published Ascon-128 implementations on various FPGA platforms, plotting their achieved data throughput versus the area they require in look-up tables (LUTs). Each implementation shown is represented by a shape that denotes 2of8 Electronics Letters,2025 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License FIGURE 1 Ascon FPGA implementations. Area efficiency: Achieved data throughput versus area required. its main implementation scheme, they are also colour-coded to the FPGA platform where they were benchmarked, with a label for identification. Implementations labelled N-p from [12] and unrolled-N from [8] perform loop unrolling, executing N permutations per clock cycle. Implementations serial-M from [12] are serialised, processing Mbits per clock cycle. Implementation (RECO-HCON) [13] uses a reconfigurable architecture able to operate either as Ascon-128, Ascon-128a, Ascon-Hash or Ascon-Hasha, here the full area is considered, although only throughput for the Ascon-128 is shown. Some implementations were fitted with hardware countermeasures, implementations labelled as (h-TI) [10, 19] represent hybrid 2/3-share threshold implementations, mentioned later with other countermeasures. As it can be seen from the figures, partially unrolled implementations achieve high throughput but greater unrolling requires more area, partially seraialised implementations tend to be less performant throughput-wise but are smaller in general, and HW countermeasures are area intensive, as expected. Figure 2plots the frequency required on each of the previously shown FPGA implementations to achieve their stated area efficiency (area efficiency is defined here as the ratio between an implementation’s achieved data throughput and the area it requires, what was plotted in Figure 1). That is, the speed at which they need to operate to reach their measured throughput-area ratio in Figure 1. Some conclusions can be reached with these data. As one could expect, the less bits processed at the same time in serialised implementations, the lower the area efficiency with a fixed operating frequency. Perhaps surprisingly, high unrolling may end up being counter-productive, as combinational paths can become so long that the maximum operating frequency may suffer a greater limitation, reducing throughput with it. Yet again, the presence of HW countermeasures decreases performance. Even with all published implementations, data are scarce and not unified. As it can be seen, most implementers targeted Spartan6 FPGAs, there are not enough data available for other FPGA models. Few implementations were fitted with HW counterFIGURE 2 Ascon FPGA implementations. Operating frequency versus area efficiency (achieved-data-throughput/area-required). measures: Only threshold implementations have been applied against power analysis attacks [10, 15, 19], and only error detection techniques have been employed against fault injection attacks [11, 15] (without enough data to be shown in these figures). More details will be given about attacks and countermeasures in subsequent sections. However, very few ASIC implementations have been proposed, and few within common technology nodes, so data are insufficient for relative performance evaluations. Still, a higher countermeasure diversity has been published for ASIC, enabling relative implementation cost comparisons, shown later in Table 6. 4HW Attacks on Ascon Hardware attacks exploit unsuspected information leakage through side-channels usually present on physical implementations. They can break ciphers by analysing variables that hold correlations with secret values. Two main attack categories may be distinguished: fault injection attacks and side-channel attacks (more concretely power analysis attacks). A variety of attacks from both kinds have been performed on Ascon, the two following sections delve briefly on the nature of both attack categories, the published HW attacks on Ascon, and Ascon’s resistance to them when implemented on different platforms. Fault injection attacks (FIA) recover information from a cipher’s output value distributions. On a correctly working cipher, its enciphered output should appear random, holding no exploitable correlation with secret information. FIA intends to force the cipher to leak secrets through its output by injecting faults during its operation, be it through the circuit’s clock signal, power input or through electromagnetic emitters. That way, output values may present tendencies and show correlations with ideally secret intermediate values, which FIA uses to discover the secret key. Three FIA attacks have been performed and published on Ascon to date, with their results collected in Table 2. All of them have 3of8 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License TABLE 2 Fault injection attacks performed on Ascon. Attack Injections Attacked platform SIFA [22] 13 to 2500 sim. unprot. SW FIMA [23] 305 to 250 sim. unprot. SW SSFA [24] 70to100 sim.unprot.SW been performed by simulation on unprotected SW implementations, targeting the last round of the cipher operation’s S-box for fault injection and using the message tag as the output to analyse: ∙Statistical ineffective fault analysis (SIFA) attack [22], instead of recovering information from faulty cipher outputs, exploits outputs from ineffective fault injections, that is, outputs that remain correct after an injection as a result of faults that were unable to propagate through the cipher to its outputs. ∙Fault intensity map analysis (FIMA) attack [23] combines SIFA with fault intensity analysis, so it gathers information as well about the target’s fault sensitivity (how intense faults have to be to become effective). ∙SubSet fault analysis (SSFA) attack [24] exploits bit-reset fault injections with a chosen granularity (the amount of bits affected), and tries to guess the key one fragment at a time through subset cryptanalysis. It can be seen that Ascon is not secure against FIA, although attack performance would likely be lower in physical scenarios as opposed to simulated environments, where noise is harder to control. Furthermore, HW implementations tend to be less leaky than SW running on microprocessors. Side-channel attacks (SCA), also called power analysis attacks, aim to recover secrets by exploiting the correlation between a target device’s power consumption with its internal state logic values and/or their transitions. Published SCA tended to target the starting round’s S-box on Ascon’s operation for power trace collection, exploiting the fact that most of the starting internal state is known, only the target key is private unavailable information. Two main SCA categories can be distinguished, depending on thedegreeofcontroltheattackerhasonthetargetdeviceorthe knowledge required about the internal system: model-based and profiling attacks. In model-based SCA, previous knowledge about the way the cipher is implemented is needed, as a power leakage model has to be developed in order to predict power consumption traces. Then, through correlation analysis with the gathered target’s power traces, the attacker may be able to infer the key associated with the measured traces. Table 3shows published results for these different attack techniques. The traditional and well known differential power analysis (DPA) attacks [17, 25] and correlation power analysis (CPA) attacks [26– 29] require a concrete model for the target S-box to generate the predicted power traces. On the other hand, the innovative side channel analysis with reinforcement learning (SCARL) attack [30] employs a versatile generalised leakage model usable on Sboxes of a given order, so it does not require a previous predicted trace database. It fits the generalised leakage model automatically to the received attack traces through reinforcement learning with an actor-critic neural network system. In contrast to model-based attacks, profiling attacks do not need a previous leakage model, they build a power consumption profile for the target device before the attack. This profile or template maps cipher inputs given by the attacker to the power consumption associated to their processing. Thus, the attacker is required to have full control over the target device for some time prior to the attack. With a rich enough profile, very few attack traces are needed to establish a key guess by correlation analysis. Table 4shows the best-performing profiling attack techniques that have been performed on Ascon. Soft analytical side channel attack (SASCA) [33], uses a factor graph that follows secret value probability distributions propagating through the cipher for better template matching; it was later reinforced with linear discrimination analysis (SASCA-LDA) [31] for reducing computational complexity through trace reduction. The template attack (TA) performed in [29] reduces profiling traces through the detection of points of interest aiming to lower computational complexity during correlation analysis. Furthermore, some profiling attacks make use of neural networks, deep learning side channel analysis (DLSCA) attack [28], also called deep learning assisted side channel analysis (DLASCA) attack in [29], employs neural networks, be it multi-layer perceptrons (MLPs) or convolutional neural networks (CNNs) trained on the profiling traces as attack trace analysers. In [29], transfer learning was also applied for network pre-training with simulated power traces, this reduces the amount of attack traces required, but the attacker needs to have a device model for previous simulation like in model-based attacks. Furthermore, in [32], a preliminary ensemble-based deep learning side channel analysis (EDLSCA) partial half-key-recovery attack was performed to demonstrate that neural network ensembles can enhance correlation analysis through DLSCA, but no full attack was performed. As it can be seen, neural networks have great potential as profiling attack tools for leakage assessment. 5HW Countermeasures It can be concluded from the previous section that unprotected Ascon implementations, be it HW or running on SW, are not safe from HW attacks. Hardware countermeasures can reinforce implementations by reducing information leakage, but always with some implementation costs. Sadly, no universal countermeasure scheme exists, though many techniques have been proposed, each one is only able to shield against certain attacks. Practical protection can only be achieved by combining them, which usually entails heavy implementation sacrifices. Countermeasure schemes against fault injection attacks proposed for Ascon may be grouped in two main categories: ∙Error detection/correction [11, 15, 34–37]: Based mainly upon operation redundance and result comparison or in operation result signature verification, prevents error propagation by 4of8 Electronics Letters,2025 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License TABLE 3 Model-based power analysis attacks on Ascon. Attack Attack traces Attacked platform DPA [25]∽10 4unprot. HW, Spartan-6. [17] 500 sim. ASIC 90nm, Ascon-x-low-area. [17] 1000 sim. ASIC 90nm, Ascon-fast. CPA [26]2×104unprot. HW, Spartan-6. [27]5×105unprot. SW, 32-bit, STM32F407IGT6. [28] 8000 unprot. SW, 32-bit, STM32F303. [29] 2000 unprot. SW, 32-bit, RV32IMC 180nm SCARL [30]2.4 ×104unprot. HW, Artix-7. TABLE 4 Profiling power analysis attacks on Ascon. Attack Profiling traces Attack traces Attacked platform SASCA-LDA [31] 81,000 2 unprot. SW, 32-bit, STM32F303. TA [29] 90,000 573 unprot. SW, 32-bit, 180nm RV32IMC. DLSCA MLP [32] 50,000 20 unprot. SW, 32-bit, ATMega8515. DLASCA CNN [29] 95,000 500 unprot. SW, 32-bit, 180nm RV32IMC. DLASCA CNN +transfer learning [29] 60,000 175 unprot. SW 32-bit, 180nm RV32IMC. contaminating results when one is detected, or correcting errors before they have a chance to propagate. Correction is a requirement for neutralising SIFA attacks, but it needs at least operation triplication. Depending on the target redundancy, area and power costs may be large when implementing these countermeasures. ∙Infective countermeasures [37–39]: These exotic techniques are based on guaranteeing full, balanced and consistent error propagation, infecting cipher outputs when faults have been injected in such a way that no usable tendency will ever be present, and no ineffective faults may ever take place as all of them get to propagate. Alternatively, all HW countermeasures proposed against power analysis attacks for Ascon fall under the masking umbrella. Masking consists in dividing internal secret values into independent ‘shares’ by mixing data with randomness. That way, operations that may be leaky are performed in an alternative data representation in which leakage is harmless. The transformation can only be reversed by mixing all shares, which increases the amount of information the attacker has to gather to uncover usable secrets. The different masking schemes, comparative achievable implementation features and associated costs are shown in Table 5. Briefly identifying each of the techniques mentioned: ∙Threshold implementations (TIs) [10, 15, 19]makeuseof at least three shares. They are the most common masking scheme nowadays as they prevent leakage through glitches and their design is not especially complex. Their costs are taken as reference in Table 5as all other masking schemes are built upon them. ‘Hybrid’ TIs [10, 19] use two shares where possible to reduce overhead without compromising security. ∙Domain oriented masking (DOM) [40, 41]: Encloses shares into domains to guarantee share independence, imposing hard domain boundary constraints to prevent collisions that may reunite shares prematurely, which would compromise security. ∙Unified masking approach (UMA) [41]: Unifies techniques from software and hardware masking aiming to reduce latency and randomness requirements. ∙Generic low-latency masking (GLM) [42]: Relaxes DOM’s domain constraints to greatly reduce latency, but design complexity increases as share collisions are harder to prevent. ∙SElf-SYnchronising masking (SESYM) [43]: Uses wave dynamic differential logic (WDDL) and self-synchronising techniques to reduce required internal sequential layers for lower latency, at a massive area cost. ∙Efficient low-latency masking without fresh randomness (ELM) [44]: Disposes of fresh randomness requirements by utilising neighbour S-box shares as randomness sources. All the mentioned countermeasure schemes have been proposed theoretically against the hardware attacks given here, but only a few of them have been implemented physically with their protection tested and their features benchmarked. On Table 6, focus is placed on relative implementation costs of the few countermeasure schemes that have been implemented on HW and benchmarked for Ascon. Columns show, from left to right: relative increase or decrease in area, power, latency/critical path delay, and throughput. Being relative/normalised values, results 5of8 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License TABLE 5 Masking countermeasures, relative implementation features and costs. Reference values are represented as ‘⋅’, relative increment as ‘↑’, relative decrement as ‘↓’. Technique Area Latency Throughput Rand. req. Design comp. TI: 3-share [15]⋅⋅ ⋅ ⋅ ⋅ Hybrid TI: 2/3-share [10, 19]↓⋅ ⋅ ↓ ⋅ DOM [40, 41]↓↓ ⋅ ↓ ↑ UMA [41]↑↓ ↓ ↓↓ ↑ GLM [42]↑↑ ↓ ↑ ↑↑ ↑↑ SESYM [43]↑↑↑ ↓ ↑ ↓ ↑↑ ELM [44]↑↓ ↑ ∅ ↑↑ TABLE 6 Relative countermeasure implementation costs. Platform Cntrmsure. Area Power Latency Throughput [11] FPGA: Spartan-7 unprot. 1x 1x 1x 1x sig. 1-bit 1.01x 1.00x 1.00x 1.00x interleaved-bit 1.02x 1.00x 1.00x 1.00x CRC-3 1.10x 1.00x 1.05x 0.96x [11] FPGA: Kintex-7 unprot. 1x 1x 1x 1x sig. 1-bit 1.01x 0.99x 1.00x 1.00x interleaved-bit 1.02x 0.99x 1.00x 1.00x CRC-3 1.02x 0.99x 1.02x 0.98x [17][18] ASIC: 90nm fast 1x 1x N/A 1x fast-TI 3.83x 4.23x N/A 0.68x x-low-area 1x 1x N/A 1x x-low-TI 2.45x 3.00x N/A 1.07x [15] ASIC: 130 nm unprot. 1x 1x 1x N/A err. dtc. 2.62x 3.08x 1.00x N/A TI 3.70x 5.73x 1.15x N/A TI +err. dtc. 9.63x 14.58x 1.15x N/A should be partially extrapolable to other ASIC technologies or FPGA platforms. As it can be seen, data are still very limited, very few countermeasure schemes have been physically implemented and benchmarked, be it on their own or combined with others, let alone tested against HW attacks. 6 Conclusions Ascon will surely receive much attention in the immediate future while it ripens as the new NIST-appointed standard lightweight AEAD cipher. A sizeable amount of Ascon HW implementations have been published, most of them on FPGAs, very few as ASIC. In both cases, a limited variety of countermeasures have been implemented. Several HW attacks have been successful against unprotected Ascon, though most of the published attacks were performed on microcontrollers running SW implementations. Thus, more attacks on HW implementations are required to test attack performance. There are now many countermeasure schemes proposed in theory, but even if countermeasures are theoretically secure, leakage can still occur on HW where parasitics and couplings are ubiquitous. Even small couplings and other higher order effects can lead to exploitable leakage still when countermeasures are present. Physical countermeasure implementations and their evaluation are imperative, as very few schemes have been physically designed, benchmarked and tested on HW to date. As are needed attacks against implementations fitted with countermeasures, both to test countermeasure strength and attack power. All in all, Ascon is expected to thrive in the field of LW cryptography in the near future, but further work is yet required until it is ready for general deployment. Author Contributions Miguel Martín-González: data curation, formal analysis, investigation, methodology, resources, software, validation, visualization, writing 6of8 Electronics Letters,2025 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License – original draft, writing – review and editing. Erica Tena-Sánchez: conceptualization, formal analysis, funding acquisition, project administration, supervision, validation, writing – review and editing. Francisco Eugenio Potestad-Ordóñez: formal analysis, validation, writing – review and editing. Antonio J. Acosta: conceptualization, formal analysis, funding acquisition, project administration, supervision, validation, writing – review and editing. Acknowledgements This work has been funded by the project Grant PID2020-116664RBI00 funded by MCIN/AEI/10.13039/501100011033. Authors want to thank the SPIRS (Secure Platform for ICT Systems Rooted at the Silicon Manufacturing Process) Project with Grant Agreement No. 952622 under the European Union’s Horizon 2020 research and innovation programme and the Ministerio de Asuntos Económicos y Transformación Digital through TSI-069100-2023-1 PERTE-Chip Chair Project, with NextGenerationEU funds. Conflicts of Interest The authors declare no conflicts of interest. Data Availability Statement The data that support the findings of this study are available through the article’s reference list. References 1. NIST, “Lightweight Cryptography Standardisation Project,” accessed January 8, 2025, https://csrc.nist.gov/projects/lightweight-cryptography (2024). 2. C. Dobraunig, M. Eichlseder, F. Mendel, and M. Schläffer, “Ascon v1.2,” Submission to NIST Lightweight Cryptography Standardisation Project, https://ascon.iaik.tugraz.at/specification.html (2021). 3. CAESAR, “Caesar Submissions Final Portfolio,” accessed January 8, 2025, https://competitions.cr.yp.to/caesar-submissions.html (2025). 4. F. X. Standaert, “Secure Integrated Circuits and Systems. Integrated Circuits and Systems,” in Introduction to Side-Channel Attacks (Springer, 2009), 27–42. 5. W. Hu, C.-H. Chang, A. Sengupta, et al., “An Overview of Hardware Security and Trust: Threats, Countermeasures, and Design Tools,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems 40, no. 6 (2021): 1010–1038, https://doi.org/10.1109/TCAD.2020.3047976. 6. M. Martín-González, E. Tena-Sanchez, F. E. Potestad Ordöñez, and A. J. Acosta, “Hardware Implementations, SCA/FIA attacks, and Countermeasures for the Ascon AEAD Cipher: A review,” in 2024 39th Conference on Design of Circuits and Integrated Systems (DCIS) (IEEE, 2024), 1–6, https://doi.org/10.1109/DCIS62603.2024.10769155. 7. NIST, “Nist sp 800-232 (Initial Public Draft), Ascon-Based Lightweight Cryptography Standards for Constrained Devices: Authenticated Encryption, Hash, and Extendable Output Functions,” National Institute of Standards and Technology, accessed February 7, 2025, https://csrc.nist. gov/pubs/sp/800/232/ipd. 8. M. Fivez and I. Verbauwhede, “Energy Efficient Hardware Implementations of CAESAR Submissions,” (PhD Thesis, KU Leuven, 2016), https://cosicdatabase.esat.kuleuven.be/backend/publications/ files/these/279. 9. P. Yalla and J. P. Kaps, “Evaluation of the Caesar Hardware API for Lightweight Implementations,” in 2017 International Conference on ReConFigurable Computing and FPGAs (ReConFig), (IEEE, 2017), 1–6, https://doi.org/10.1109/RECONFIG.2017.8279790. 10. W. Diehl, F. Farahmand, A. Abdulgadir, J.-P. Kaps, and K. Gaj, “FaceOff Between the Caesar Lightweight Finalists: Acorn vs. Ascon,” in 2018 International Conference on Field-Programmable Technology (FPT), (IEEE, 2018), 330–333, https://doi.org/10.1109/FPT.2018.00066. 11. J. Kaur, M. M. Kermani, and R. Azarderakhsh, “Hardware Constructions for Error Detection in Lightweight Authenticated Cipher Ascon Benchmarked on FPGA,” IEEE Transactions on Circuits and Systems II: Express Briefs 69, no. 4 (2022): 2276–2280, https://doi.org/10.1109/TCSII. 2021.3136463. 12. S. Khan, W. K. Lee, and S. O. Hwang, “Scalable and Efficient Hardware Architectures for Authenticated Encryption in IOT Applications,” IEEE Internet of Things Journal 8, no. 14 (2021): 11260–11275, https://doi.org/10. 1109/JIOT.2021.3052184. 13. X. Wei, M. El-Hadedy, S. Mosanu, Z. Zhu, W.-M. Hwu, and X. Guo, “RECO-hcon: A High-Throughput Reconfigurable Compact Ascon Processor for Trusted IOT,” in 2022 IEEE 35th International System-on-Chip Conference (SOCC) (IEEE, 2022), 1–6. 14. S. Khan, W. K. Lee, and S. O. Hwang, “Evaluating the Performance of Ascon Lightweight Authenticated Encryption for AI-Enabled IoT Devices,” in 2022 TRON Symposium (TRONSHOW) (IEEE, 2022), 1–6, https://ieeexplore.ieee.org/abstract/document/10024417. 15. A. Kandi, A. Baksi, T. Gerlich, et al., “Hardware Implementation of Ascon,” NIST Lightweight Cryptography Workshop 2023, accessed January 8, 2025, https://csrc.nist.gov/events/2023/lightweight-cryptographyworkshop-2023. 16. K. Raj and S. Bodapati, “Fpga Based Light Weight Encryption of Medical Data for IOMT Devices Using Ascon Cipher,” in 2022 IEEE International Symposium on Smart Electronic Systems (iSES) (IEEE, 2022), 196–201, https://doi.org/10.1109/iSES54909.2022.00048. 17. H. Gross, E. Wenger, C. Dobraunig, and C. Ehrenhöfer, “Ascon Hardware Implementations and Side-Channel Evaluation,” Microprocessors and Microsystems 52 (2017): 470–479, https://doi.org/10.1016/j.micpro. 2016.10.006. 18. H. Gross, E. Wenger, C. Dobraunig, and C. Ehrenhöfer, “Suit up! – Made-To-Measure Hardware Implementations of Ascon,” in 2015 Euromicro Conference on Digital System Design (IEEE, 2015), 645–652. 19. W. Diehl, A. Abdulgadir, F. Farahmand, J.-P. Kaps, and K. Gaj, “Comparison of Cost of Protection Against Differential Power Analysis of Selected Authenticated Ciphers,” in 2018 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) (IEEE, 2018), 147–152, https://doi.org/10.1109/HST.2018.8383904. 20. A. Abdulgadir, W. Diehl, and J. P. Kaps, “An Open-Source Platform for Evaluation of Hardware Implementations of Lightweight Authenticated Ciphers,” in 2019 International Conference on ReConFigurable Computing and FPGAs (ReConFig) (IEEE, 2019), 1–5, https://doi.org/10. 1109/ReConFig48160.2019.8994788. 21. G. Surya, P. Maistri, and S. Sankaran, “Local Clock Glitching Fault Injection With Application to the Ascon Cipher,” in 2020 IEEE International Symposium on Smart Electronic Systems (iSES) (IEEE, 2020), 271–276, https://doi.org/10.1109/iSES50453.2020.00067. 22. K. Ramezanpour, P. Ampadu, and W. Diehl, “A Statistical Fault Analysis Methodology for the Ascon Authenticated Cipher,” in 2019 IEEE International Symposium on Hardware Oriented Security and Trust (HOST) (IEEE, 2019), 41–50, https://doi.org/10.1109/HST.2019.8741029. 23. K. Ramezanpour, P. Ampadu, and W. Diehl, “Fima: Fault Intensity Map Analysis,” in Constructive Side-Channel Analysis and Secure Design (Springer,2019),63–79,https://doi.org/10.1007/978-3-030-16350-1_5. 24. P. Joshi and B. Mazumdar, “Ssfa: Subset Fault Analysis of Ascon128 Authenticated Cipher,” Microelectronics Reliability 123 (2021): 114–155, https://doi.org/10.1016/j.microrel.2021.114155. 25. N. Samwel and K. Papagiannopoulos, “Side-Channel Analysis of Keccak and Ascon,” (master’s thesis, Radboud University Nijmegen, 2016), https://api.semanticscholar.org/CorpusID:43167034. 26. N. Samwel and J. Daemen, “DPA on Hardware Implementations of Ascon and Keyak,” in CF’17: Proceedings of the Computing Frontiers 7of8 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License Conference (Association for Computing Machinery, 2017), 415–424, https://doi.org/10.1145/3075564.3079067. 27. L. Batina, I. R. Buhan, L. M. Chmielewski, et al., Side-Channel Evaluation Report on Implementations of Several NIST LWC Finalists, (Nijmegen: Cryptographic Engineering & Side-Channel Analysis (CESCA) Lab, 2022), https://hdl.handle.net/2066/253567. 28. L. Weissbart and S. Picek, “Lightweight But Not Easy: Side-Channel Analysis of the Ascon Authenticated Cipher on a 32-Bit Microcontroller,” preprint, Cryptology ePrint Archive, October 16,2023,https://eprint.iacr. org/2023/1598. 29. D. Shanmugam and P. Schaumont, “Improving Side-Channel Leakage Assessment Using Pre-Silicon Leakage Models,” in Constructive SideChannel Analysis and Secure Design (Springer, 2023), 105–124, https://doi. org/10.1007/978-3-031-29497-6_6. 30. K. Ramezanpour, P. Ampadu, and W. Diehl, “Scarl: Side-Channel Analysis With Reinforcement Learning on the Ascon Authenticated Cipher,” preprint, arXiv:2006.03995, June 6, 2020, https://doi.org/10. 48550/arXiv.2006.03995. 31. S. C. You, M. G. Kuhn, S. Sarkar, and F. Hao, “Low Trace-Count Template Attacks on 32-Bit Implementations of Ascon AEAD,” IACR Transactions on Cryptographic Hardware and Embedded Systems 2023, no. 4 (2023): 344–366, https://doi.org/10.46586/tches.v2023.i4.344-366. 32. A. Rezaeezade, A. Basurto-Becerra, L. Weissbart, and G. Perin, “One for All, All for Ascon: Ensemble-Based Deep Learning SideChannel Analysis,” preprint, Cryptology ePrint Archive, Paper 2023/1922, December 16, 2023, https://eprint.iacr.org/2023/1922. 33. S. Lou, W. Wu, Y. Li, R. Zhang, and Z. Liu, “An Efficient Soft Analytical Side-Channel Attack on Ascon,” Wireless Algorithms, Systems, and Applications (Springer, 2022), 389–400, https://doi.org/10.1007/9783-031-19208-1_32. 34. S. Saha, D. Jap, D. B. Roy, A. Chakraborty, S. Bhasin, and D. Mukhopadhyay, “A Framework to Counter Statistical Ineffective Fault Analysis of Block Ciphers Using Domain Transformation and Error Correction,” IEEE Transactions on Information Forensics and Security 15 (2020): 1905–1919, https://doi.org/10.1109/TIFS.2019.2952262. 35. A. Baksi, V. B. Y. Kumar, B. Karmakar, S. Bhasin, D. Saha, and A. Chattopadhyay, “A Novel Duplication Based Countermeasure to Statistical Ineffective Fault Analysis,” preprint, Cryptology ePrint Archive, Paper 2020/1268, October 14, 2020, https://eprint.iacr.org/2020/1268. 36. A. Baksi, S. Bhasin, J. Breier, A. Chattopadhyay, and V. B. Y. Kumar, “Feeding Three Birds With One Scone: A Generic Duplication Based Countermeasure to Fault Attacks (Extended Version),” preprint, Cryptology ePrint Archive, Paper 2020/1542, December 13, 2020, https:// eprint.iacr.org/2020/1542. 37. J. Daemen, C. Dobraunig, M. Eichlseder, H. Gross, F. Mendel, and R. Primas, “Protecting Against Statistical Ineffective Fault Attacks,” preprint, Cryptology ePrint Archive, Paper 2019/536, May 22, 2019, https:// eprint.iacr.org/2019/536. 38. J. Jacob, J. Joseph, M. K. Abinshad, K. N. Ambili, and J. Jose, “Prevention of Fault Attacks in Ascon Authenticated Cipher Using Cellular Automata,” in Cellular Automata (Springer, 2021), 18–25, https:// doi.org/10.1007/978-3-030-69480-7_3. 39. K. N. Ambili and J. Jose, “Reinforcing Lightweight Authenticated Encryption Schemes Against Statistical Ineffective Fault Attack,” Cryptology ePrint Archive, Paper 2022/041, January 14, 2022, https://eprint.iacr. org/2022/041. 40. H. Gross, S. Mangard, and T. Korak, “Domain-Oriented Masking: Compact Masked Hardware Implementations With Arbitrary Protection Order,” in Proceedings of the 2016 ACM Workshop on Theory of Implementation Security (Association for Computing Machinery, 2016), 1–3, https://eprint.iacr.org/2016/486. 41. H. Gross and S. Mangard, “Reconciling d+1 Masking in Hardware and Software,” preprint, Cryptology ePrint Archive, Paper 2017/103, 26 June, 2017, https://eprint.iacr.org/2017/103. 42. H. Gross, R. Iusupov, and R. Bloem, “Generic Low-Latency Masking in Hardware,” IACR Transactions on Cryptographic Hardware and Embedded Systems 2018, no. 2 (2018): 1–21, https://doi.org/10.13154/tches. v2018.i2.1-21. 43. R. Nagpal, B. Gigerl, R. Primas, and S. Mangard, “Riding the Waves Towards Generic Single-Cycle Masking in Hardware,” IACR Transactions on Cryptographic Hardware and Embedded Systems 2022, no. 4 (2022): 693–717, https://doi.org/10.46586/tches.v2022.i4.693-717. 44. S. H. Prasad, F. Mendel, M. Schlaeffer, and R. Nagpal, “Efficient Low-Latency Masking of Ascon Without Fresh Randomness,” preprint, Cryptology ePrint Archive, Paper 2023/1914, 13 December, 2023, https:// eprint.iacr.org/2023/1914. 8of8 Electronics Letters,2025 1350911x, 2025, 1, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/ell2.70260 by Readcube (Labtiva Inc.), Wiley Online Library on [30/06/2025]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License