Software Benchmarking of NIST Lightweight Hash Function Finalists on

Resource-Constrained AVR Platform via ChipWhisperer

Mohsin Khan

, H

avard Dagenborg

and Dag Johansen

UiT The Arctic University of Norway, Tromsø, Norway

Keywords:

NIST, Lightweight Hash Functions, Software Benchmarking.

Abstract:

This paper presents a novel performance evaluation of ﬁve key lightweight hash functions on an ATxmega128

microcontroller, using our E-RANK metric as a composite metric that integrates execution speed, memory

footprint, and energy efﬁciency into a uniﬁed and balanced ranking. We leverage hardware-speciﬁc proﬁling

techniques, where counter registers are accessed directly on the microcontroller to measure execution speed

and analyze RAM and ROM footprints post-compilation to determine memory usage. Energy consumption

is measured using the ChipWhisperer FPGA toolkit, capturing voltage traces via an oscilloscope probe. Our

evaluations provide new insights into the trade-offs inherent in each lightweight hash function, providing

guidance on which one is most suitable for various application-speciﬁc constraints.

1 INTRODUCTION

Cryptographic hash functions are essential compo-

nents in many security mechanisms. They provide

data integrity, verify authenticity, and prevent repu-

diation. Traditional hash functions are, however, not

optimized for resource-constrained devices, such as

those commonly used in Internet of Thing (IoT) and

RFID applications. As an alternative, many spe-

cialized Lightweight Hash Functions (LWHFs), like

PHOTON (Guo et al., 2011) and SPONGENT (Huang

et al., 2021), have been proposed and standardized un-

der ISO/IEC 29192-5 for use in resource-constrained

environments.

In 2019, NIST called for the standardization of

lightweight cryptographic algorithms, receiving 57

submissions for consideration. Among the sub-

missions, many cryptographic algorithms included

their associated LWHFs, including the winner AS-

CON (Dobraunig et al., 2021). The NIST re-

ports on lightweight cryptographic algorithms include

software implementation results for the NIST stan-

dardized LWHFs, evaluating execution time, mem-

ory footprint, and power consumption on ARM

Cortex-M4, ESP32, and AVR ATmega328P (Tu-

ran et al., 2019; Turan et al., 2021; Turan et al.,

https://orcid.org/0000-0003-1815-8642

https://orcid.org/0000-0002-1637-7262

https://orcid.org/0000-0001-7067-6477

2023). However, these benchmarking results lack

ﬁne-grained power proﬁling, trade-off analysis be-

tween performance and cost, and performance tun-

ing for speciﬁc embedded platforms. Others (Win-

darta et al., 2022) have provided a comparative anal-

ysis of NIST LWHFs but compile results obtained

through different methodologies without ensuring di-

rect comparability or focusing on hardware imple-

mentations (Khan et al., 2023) without providing a

uniﬁed benchmarking approach to standardize perfor-

mance comparisons.

In this paper, we benchmark the LWHFs from the

ﬁve ﬁnalists in the NIST lightweight cryptography

standardization process, evaluating their performance

based on Cycles per Byte (CPB), RAM and ROM

footprint, and energy consumption. Our experimen-

tal setup includes a novel hardware proﬁling approach

that combines the NewAE ChipWhisperer platform

with an ATxmega128 microcontroller. This setup en-

ables high-resolution power analysis and energy pro-

ﬁling, making it possible to accurately measure the

computational efﬁciency of each LWHF. We use our

novel E-RANK metrics to assess and compare the

overall efﬁciency of the LWHFs, which balances the

tradeoff between the various measurement types. Our

measurements show that the selected LWHFs have

different performance characteristics, and the selec-

tion of which one to use is highly application depen-

dent.

690

Khan, M., Dagenborg, H. and Johansen, D.

Software Benchmarking of NIST Lightweight Hash Function Finalists on Resource-Constrained AVR Platform via ChipWhisperer.

DOI: 10.5220/0013560700003979

In Proceedings of the 22nd International Conference on Security and Cryptography (SECRYPT 2025), pages 690-695

ISBN: 978-989-758-760-3; ISSN: 2184-7711

Table 1: Comparison of the structure of ﬁnalist LWHFs from the NIST lightweight cryptography competition.

LWHF Internal Parameters Structure (Sponge Construction)

Output Hash

Rate

(bits)

State

(bits)

Capacity

(bits)

Permutation

Round

Structure

Rounds (bits)

ASCON 64 320 256 Ascon-p SPN 12/8 256

PHOTON-Beetle 32 256 224 PHOTON

AES-like SPN

12 256

Xoodyak 128 384 256 Xoodoo

SPN with ARX

based Plane Diffusion

12 256

SPARKLE 128 384 256 SPARKLE-384

ARX-based SPN

var 256

ISAP var 320 / 400 var Ascon-p / Keccak-p[400] SPN var 256

2 BACKGROUND

This section provides an overview of the ﬁve NIST

lightweight cryptography ﬁnalists that we study in

this paper, summarized in Table 1. Note that all are

based on a Sponge construction approach.

ASCON (Dobraunig et al., 2021) uses a 320-bit

internal state, a 64-bit rate for input, and a 256-bit

capacity for cryptographic strength. During initializa-

tion, a predeﬁned IV is loaded, and a 12-round Ascon-

p permutation is applied. Messages are processed in

64-bit blocks, XORed into the rate, followed by an 8

or 12-round permutation. Once all input is processed,

a ﬁnal 12-round permutation occurs before extracting

the digest. For longer outputs, extra squeezing rounds

are done.

PHOTON-Beetle (Bao et al., 2021) utilizes a

sponge construction based on the PHOTON-256 per-

mutation. The hash function has a 256-bit inter-

nal state, split into 32-bit rate and 224-bit capac-

ity, balancing speed and security. During initializa-

tion, the state is set to zero, and the ﬁrst 128-bit in-

put block is absorbed. The absorption phase pro-

cesses the message in 32-bit blocks, each XORed

with the rate portion, followed by 12 rounds of the

PHOTON-256 permutation, which includes four core

operations: AddConstant, SubCells (4-bit S-box),

ShiftRows, and MixColumnSerial, ensuring diffusion

and cryptographic strength. The squeezing phase de-

rives the ﬁnal hash output by applying another round

of PHOTON-256 and extracting two 128-bit parts

from the state.

Xoodyak (Daemen et al., 2020) function is based

on the Xoodoo permutation. Its internal state con-

sists of 384 bits, split into 128 bits for the rate and

256 bits for capacity. Xoodyak employs a duplex

sponge structure for hashing and authenticated en-

cryption. Initialization sets the internal state to zero.

During absorption, input blocks XOR with the state’s

rate portion, followed by 12 rounds of the Xoodoo

permutation, which involves bitwise mixing, a non-

linear layer, and diffusion transformations. Finally, in

the squeezing phase, the hash output is taken from the

state, with an option for extendable output length.

ESCH (Beierle et al., 2020) is based on a sponge

construction and features an Addition-Rotation-XOR

(ARX) design. ESCH processes messages itera-

tively, padding and absorbing them into an internal

state before transforming them via SPARKLE-384

(Esch256) or SPARKLE-512 (Esch384). These per-

mutations use the Alzette ARX-box, a lightweight

cryptographic primitive that ensures non-linearity and

diffusion while remaining efﬁcient in constrained en-

vironments. The internal state undergoes multiple

transformation rounds, combining modular addition,

bitwise rotation, and XOR operations to enhance se-

curity. After absorbing all input data, a ﬁnalization

step produces the 256-bit output (Esch256) or 384-bit

output (Esch384).

ISAP (Dobraunig et al., 2017) employs a sponge-

based construction approach, using Ascon-p or

Keccak-p[400] permutation. The hash function fea-

tures an iterative permutation structure where input is

absorbed into a ﬁxed-size internal state, processed via

multiple rounds of the chosen permutation, and then

squeezed to generate the ﬁnal hash. The state begins

with a predeﬁned value. Input blocks are XORed into

the state’s rate portion during absorption, followed by

a permutation round for diffusion. Finalization ap-

plies extra rounds before output extraction.

3 RESEARCH METHODOLOGY

3.1 Measurements

To obtain precise CPB, RAM, ROM, and energy

consumption measurements, we are using the open-

source ChipWhisperer

platform by NewAE Tech-

nology. ChipWhisperer is a suite of hardware and

https://www.newae.com/chipwhisperer

Software Benchmarking of NIST Lightweight Hash Function Finalists on Resource-Constrained AVR Platform via ChipWhisperer

691

software tools created to ﬁnd security vulnerabili-

ties in embedded systems. Its modular structure

enables the integration of specialized modules, en-

abling precise measurements and advanced crypto-

graphic testing. The Chipwhisperer uses features such

as high-precision oscilloscope integration, triggering

mechanisms, and clock-glitching capabilities. The

ChipWhisperer-lite variant of the toolkit consists of

a capture board and a target board.

The capture board consists of an Xilinx Spartan-

6 LX9 FPGA, an ARM Cortex-M3 (ATSAM3U2C)

microcontroller, an AD9215 BRUZ-105 Analog-to-

Digital converter (ADC), and an AD8331ARQZ

Low-Noise Ampliﬁer (LNA). The FPGA serves as

the core processing unit responsible for data ac-

quisition and clock synchronization. The ARM

Cortex-M3 manages USB communication between

ChipWhisperer and a host PC to provide command

execution and communication protocols. In our

case, we use the Universal Asynchronous Receiver-

Transmitter (UART) to program the target board and

send trigger signals. The LNA ampliﬁes weak power

traces from the target board before forwarding them to

the ADC, offering an adjustable gain from 0 to 55 dB.

In our experimental setup, we are using an

ATxmega128 microcontroller as our target board,

mounted on a Universal Feature Observation (UFO)

board, which provides a standardized interface for

power, clock, and data connections. The oscillo-

scope probe connects the capture board and the UFO

Board, capturing voltage glitches upon triggering.

The FPGA on the capture board controls and synchro-

nizes the oscilloscope.

3.2 Experiment Overview

Our experiment consists of three main stages.

Stage 1: Firmware Development. The ﬁrmware

development for the target board is carried out in the

C language, with the LWHF implementations sourced

from the NIST website. A base C program is devel-

oped to enable simple serial communication with the

ChipWhisperer Python API, enabling trigger signal

handling and the execution of speciﬁc hash functions.

The selected LWHFs are integrated into the base C

program through macros, allowing for a ﬂexible se-

lection of different algorithms during compilation.

The ﬁrmware compilation process utilizes the

AVR-GCC compiler, incorporating compiler ﬂags for

object ﬁles and macros that specify the hash function

name and variant. During compilation, the C imple-

mentation ﬁles of the chosen LWHFs are translated

into object ﬁles, which are then linked together to

generate the .elf and .map ﬁles. The .elf is then

converted to .hex ﬁle for ﬂashing on the target. Also,

the compiler is conﬁgured to generate .su ﬁles for

each object ﬁle, providing stack usage. Finally, the

ChipWhisperer Python API uses the generated .hex

ﬁle to program the ATxmega128 target device.

Stage 2: Target Flashing. The ChipWhisperer cap-

ture board is initialized by conﬁguring the scope and

setting its key parameters, including gain, sample

rate, trigger settings, and clock sources. Once the

scope is initialized, the selected Programmer is used

to ﬂash the compiled .hex ﬁle onto the ATxmega128

target board. After ﬂashing, the ﬁrmware is veriﬁed

and debugged.

Stage 3: Evaluation Metrics Measurement. This

stage involves initializing and conﬁguring simple se-

rial communication and the scope, which are then

used to initialize the target device by linking it with

the scope and serial interface. Once the initialization

is complete, the system determines the speciﬁc per-

formance metric to be measured, selecting from RAM

usage, ROM usage, CPB, or energy consumption.

3.3 Evaluation Metrics

The performance metrics used for benchmarking the

selected LWHFs are as follows.

Cycles per Byte (CPB): represents the number

of processor cycles required to process each byte

of input data. The CPB measurement is con-

ducted using a hardware-speciﬁc technique that uti-

lizes the TCC0.CTRLA register (Control Register for

Timer/Counter C0) on the ATxmega128 target board.

It is responsible for conﬁguring the clock source and

prescaler settings.

To measure execution cycles, the TCC0.CTRLA

operation, and as the selected LWHF processes the in-

put data, the timer records the total clock cycles con-

sumed. At the end of the hashing process, the register

is accessed to retrieve the ﬁnal cycle count, which is

then divided by the number of input bytes to compute

the CPB value. The calculated CPB is transmitted to

the host system via simple serial communication.

RAM: is determined by summing the initialized

and uninitialized global/static variables along with the

stack memory utilized by the LWHF. The initialized

(.data) and uninitialized (.bss) segments are ex-

tracted from the .map ﬁle, which is generated dur-

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

692

ing the linking stage of compilation using AVR-GCC.

Also, both dynamic and static stack usage are ob-

tained from the .su ﬁle, which is created during the

compilation of each object ﬁle, provides a detailed

breakdown of memory allocation.

ROM: is determined by adding the memory occu-

pied by the program code (.text) and constant data

(.rodata). The .map ﬁle, generated during the link-

ing stage of compilation, provides a detailed memory

map of the program code and constant data, allowing

precise measurement of the total ROM footprint.

Energy: is measured using ChipWhisperer’s API

function cw.capture trace, which returns an array

of instantaneous voltage samples acquired through the

ADC when a high-to-low trigger signal is detected

from the target device. The obtained samples are nor-

malized values in the range -0.5 to 0.5 and must be

converted into actual voltages for energy calculations.

Given a raw ADC voltage sample V

raw

, as returned by

the API, the ADC reference voltage V

ref

, and the gain

amp

of the ampliﬁer applied to the signal before dig-

itization, the actual voltage V

actual

is given as follows.

actual

= V

raw

ref

amp

(1)

Given the shunt resistance R

shunt

and the supply

voltage V

sup

, Ohm’s Law gives us the instantaneous

power as follows.

trace

= I

trace

×V

sup

actual

shunt

×V

sup

(2)

Because the ADC normalized samples may end up

negative due to signal oscillations or AC coupling ef-

fects, we use the Root Mean Square (RMS) power of

a trace to obtain average power and ensure precise en-

ergy calculations. Given N samples, the output RMS

power P

rms

of a trace is given as follows.

rms

∑

i=1

trace,i

(3)

The time taken by the microcontroller to execute

a hash function is given by T

exec

= C/ f

clk

, where C

represents the total number of cycles utilized during

the execution of the hash function, and f

clk

denotes

the clock frequency of the microcontroller. This gives

us the energy consumption E as a function of power

and time as follows.

E = P

rms

× T

exec

rms

×C

clk

(4)

1000

2000

3000

4000

5000

ASCON PHOTON-

Beetle

Xoodyak ESCH ISAP

2531

2158

2450

1633

3953

Exec. Speed (CPB)

Figure 1: Execution speed (CPB) of selected LWHFs.

100

200

300

400

500

ASCON PHOTON-

Beetle

Xoodyak ESCH ISAP

153

263

390

396

250

RAM (bytes)

Figure 2: RAM usage of selected LWHFs.

E-RANK: is our improved variant of the RANK

metric (Beaulieu et al., 2015) that combines execution

time, memory footprint, and energy consumption into

a single metric. Although the RANK metric has pre-

viously been used as a performance trade-off metric to

evaluate execution efﬁciency relative to resource con-

sumption, it does not account for power dissipation.

Our modiﬁed version incorporates energy consump-

tion, as shown in Equation 5.

E-RANK =

/CPB

(ROM + 2 × RAM)× E

(5)

4 RESULTS AND ANALYSIS

The measured execution speeds, in terms of CPB,

are shown in Figure 1. We found that ESCH runs

fastest, followed by PHOTON-Beetle, Xoodyak, and

ASCON. ISAP demonstrates the highest execution

time by a large margin.

For memory consumption, ASCON exhibits the

smallest RAM footprint followed by ISAP and

PHOTON-Beetle, as can be seen in Figure 2. ESCH,

with Xoodyak closely trailing, has the highest RAM

usage. ROM usage is shown in Figure 3. PHOTON-

Beetle requires the least ROM, followed by ASCON

and Xoodyak, while ISAP and ESCH have the highest

ROM allocation.

The measured energy consumption is shown in

Figure 4. Each data point is the mean of 10 runs, and

the plotted error bars indicate insigniﬁcant variability

across executions. The ﬁgure highlights that ESCH

Software Benchmarking of NIST Lightweight Hash Function Finalists on Resource-Constrained AVR Platform via ChipWhisperer

693

1000

2000

3000

4000

5000

ASCON PHOTON-

Beetle

Xoodyak ESCH ISAP

2648

1936

2804

3990

4040

ROM (bytes)

Figure 3: ROM usage of selected LWHFs.

500

1000

1500

2000

ASCON PHOTON-

Beetle

Xoodyak ESCH ISAP

1099.3

950.55

1058.72

719.05

1714.84

Energy (nJ)

Figure 4: Energy consumption of selected LWHFs.

and PHOTON-Beetle are the most energy-efﬁcient

LWHFs, while ISAP registers the highest energy con-

sumption. ASCON and Xoodyak have a moderate

and similar level of energy consumption, with only

a slight difference.

The calculated E-RANK is plotted in Figure 5. As

can be seen in the ﬁgure, PHOTON-Beetle outper-

forms all other candidates, followed by ESCH. AS-

CON and Xoodyak are positioned in the middle with

a slight difference in their E-Rank. On the lower end,

ISAP has the lowest E-RANK values.

A comparative analysis of the LWHFs based on

execution efﬁciency, memory footprint, energy con-

sumption, and overall efﬁciency (i.e., E-RANK) can

be found in Figure 6. Here, we normalize each met-

ric to a common scale to prevent any single one

from dominating the radar chart visualization. CPB

is normalized by dividing the highest CPB value by

each LWHF’s CPB, ensuring faster execution yields

a higher score. Energy, RAM, and ROM are nor-

malized using their respective minimum values, so

lower resource consumption translates to a higher nor-

malized score. Since lower values for CPB, energy

consumption, RAM, and ROM indicate better perfor-

mance, these metrics are inverted and appropriately

scaled. E-RANK is a positive metric, so it is scaled

by dividing each value by the highest observed value.

From Figure 6, we observe clear trade-offs, cor-

relations, and dominant trends among the bench-

marked LWHFs. The ESCH LWHF offers the fastest

execution speed and least energy consumption, but

has higher RAM and ROM usage. ASCON and

PHOTON-Beetle consume low memory footprints

with moderate energy consumption and execution

0.05

0.1

0.15

0.2

0.25

ASCON PHOTON-

Beetle

Xoodyak ESCH ISAP

0.12

0.2

0.11

0.18

0.032

E-RANK

Figure 5: Calculated E-RANK of selected LWHFs (Higher

values indicate better overall trade-off performance).

ASCON

PHOTON-Beetle

Xoodyak

ESCH

ISAP

0.5

1.5

2.5

Energy

Exec.

Speed

E-RANKROM

RAM

Figure 6: Multi-metric comparison of selected LWHFs.

speed. Xoodyak consumes moderate amounts of en-

ergy, execution speed, and RAM, but its RAM usage

is higher than that of ASCON, PHOTON-Beetle, and

ISAP. In addition, ISAP exhibits the highest CPB, en-

ergy, and ROM, highlighting its design as a security-

focused function rather than one aimed at efﬁciency.

This highlights a key trade-off: faster execution gen-

erally demands more memory, and designs that prior-

itize security execute slowly.

Among evaluated LWHFs, the best overall bal-

ance among speed, energy, and memory efﬁciency is

achieved by PHOTON-Beetle, which has the highest

E-RANK. PHOTON-Beetle is followed by ESCH due

to its highest execution speed and lowest energy re-

quirement. Although ESCH boasts a high execution

speed, its E-RANK lies after PHOTON-Beetle be-

cause of its increased memory requirements. ASCON

has a low memory requirement, but lies in third place

in terms of E-RANK due to its low execution speed

and moderate level of energy consumption. Xoodyak

has a lower E-RANK because it offers a mix of mod-

erate energy efﬁciency and execution speed, requir-

ing more RAM than ASCON and PHOTON-Beetle.

ISAP ranks the lowest in E-RANK, indicating that its

focus on security comes at a trade-off, as explained

earlier.

SECRYPT 2025 - 22nd International Conference on Security and Cryptography

694

Table 2: Application-speciﬁc suitability of LWHFs.

Application Recommended LWHF

Low-Power

(Battery-powered, energy-efﬁcient)

ESCH

Memory-Constrained

(Limited ROM/RAM availability)

PHOTON-Beetle

ASCON

High-Speed Execution

(Real-time, high-throughput processing)

ESCH

Security critical

(Robust against side-channel attacks)

ISAP

As is clear from Figure 6, there is not a single op-

timal LWHF for every scenario. This suggests that

the choice of hash function is based on the speciﬁc

application requirements. Also, different microcon-

troller (MCU) architectures impact the choice of an

appropriate LWHF for real-world deployments. Ta-

ble 2 outlines the most suitable LWHFs for various

application scenarios best suited for each use case.

5 CONCLUSION

This paper presents a comprehensive benchmarking

of the ﬁve ﬁnalist LWHFs from the NIST standard-

ization process using the ChipWhisperer platform

with an ATxmega128 microcontroller as the target.

We evaluate key performance metrics including CPB,

RAM usage, ROM footprint, and energy consump-

tion, using hardware-speciﬁc proﬁling and optimized

compilation techniques that ensure precise and re-

liable measurements. Our measurements reveal in-

herent trade-offs among the different LWHFs, where

achieving faster execution often comes at the cost of

higher memory and energy consumption. This em-

phasizes that the selection of an optimal LWHF is

highly application-dependent.

ACKNOWLEDGEMENTS

The authors acknowledge the use of AI tools in

preparing this paper, including Grammarly for gram-

mar and style correction and OpenAI ChatGPT and

Microsoft CoPilot for reﬁning certain sections. The

ﬁnal content has been reviewed for accuracy and

alignment with the research contributions.

REFERENCES

Bao, Z., Chakraborti, A., Datta, N., Guo, J., Nandi, M.,

Peyrin, T., and Yasuda, K. (2021). Photon-beetle au-

thenticated encryption and hash family (2020). Sub-

mission to the NIST Lightweight Competition.

Beaulieu, R., Shors, D., Smith, J., Treatman-Clark, S.,

Weeks, B., and Wingers, L. (2015). The Simon and

Speck block ciphers on AVR 8-bit microcontrollers.

In Eisenbarth, T. and

Ozt

urk, E., editors, Lightweight

Cryptography for Security and Privacy, pages 3–20,

Cham. Springer International Publishing.

Beierle, C., Biryukov, A., Cardoso dos Santos, L.,

Großsch

adl, J., Perrin, L., Udovenko, A., Velichkov,

V., and Wang, Q. (2020). Lightweight aead and hash-

ing using the sparkle permutation family. IACR Trans-

actions on Symmetric Cryptology, 2020(S1):208–261.

Daemen, J., Hoffert, S., Peeters, M., Van Assche, G., and

Van Keer, R. (2020). Xoodyak, a lightweight cryp-

tographic scheme. IACR Transactions on Symmetric

Cryptology, pages 60–87.

Dobraunig, C., Eichlseder, M., Mangard, S., Mendel, F.,

and Unterluggauer, T. (2017). Isap–towards side-

channel secure authenticated encryption. IACR Trans-

actions on Symmetric Cryptology, pages 80–105.

Dobraunig, C., Eichlseder, M., Mendel, F., and Schl

affer,

M. (2021). Ascon v1. 2: Lightweight authenticated

encryption and hashing. Journal of Cryptology, 34:1–

42.

Guo, J., Peyrin, T., and Poschmann, A. (2011). The pho-

ton family of lightweight hash functions. In Rogaway,

P., editor, Advances in Cryptology – CRYPTO 2011,

pages 222–239, Berlin, Heidelberg. Springer Berlin

Heidelberg.

Huang, Y., Li, S., Sun, W., Dai, X., and Zhu, W. (2021).

HVH: A lightweight hash function based on dual

pseudo-random transformation. In Security, Privacy,

and Anonymity in Computation, Communication, and

Storage, pages 492–505, Cham. Springer Interna-

tional Publishing.

Khan, S., Lee, W.-K., Karmakar, A., Mera, J. M. B., Ma-

jeed, A., and Hwang, S. O. (2023). Area–time efﬁcient

implementation of nist lightweight hash functions tar-

geting iot applications. IEEE Internet of Things Jour-

nal, 10(9):8083–8095.

Turan, M. S., McKay, K. A., C¸ alik, C¸ ., Chang, D., Bassham,

L., et al. (2019). Status report on the ﬁrst round

of the nist lightweight cryptography standardization

process. National Institute of Standards and Tech-

nology, Gaithersburg, MD, NIST Interagency/Internal

Rep.(NISTIR), 108.

Turan, M. S., Turan, M. S., McKay, K., Chang, D.,

Bassham, L. E., Kang, J., Waller, N. D., Kelsey, J. M.,

and Hong, D. (2023). Status report on the ﬁnal round

of the NIST lightweight cryptography standardization

process. US Department of Commerce, National In-

stitute of Standards and Technology.

Turan, M. S., Turan, M. S., McKay, K., Chang, D., Calik,

C., Bassham, L., Kang, J., and Kelsey, J. (2021). Sta-

tus report on the second round of the nist lightweight

cryptography standardization process.

Windarta, S., Suryadi, S., Ramli, K., Pranggono, B., and

Gunawan, T. S. (2022). Lightweight cryptographic

hash functions: Design trends, comparative study, and

future directions. IEEE Access, 10:82272–82294.

Software Benchmarking of NIST Lightweight Hash Function Finalists on Resource-Constrained AVR Platform via ChipWhisperer

695