# Accelerating first-order secure ML-KEM with masked SHA-3: cost, randomness, and security evaluation

Stefano Di Matteo, Diamante-Simone Crescenzo, Rafael Carrera Rodriguez, Emanuele Valea, Florent Bruguier, Pascal Benoit

► To cite this version:

Stefano Di Matteo, Diamante-Simone Crescenzo, Rafael Carrera Rodriguez, Emanuele Valea, Florent Bruguier, et al.. Accelerating first-order secure ML-KEM with masked SHA-3: cost, randomness, and security evaluation. IEEE Access, 2025, 13, pp.173254-173266. 10.1109/ACCESS.2025.3616775. cea-05320523

HAL Id: cea-05320523

https://cea.hal.science/cea-05320523v1

Submitted on 17 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Received 11 September 2025, accepted 29 September 2025, date of publication 1 October 2025, date of current version 9 October 2025.

Digital Object Identifier 10.1109/ACCESS.2025.3616775

RESEARCH ARTICLE

# Accelerating First-Order Secure ML-KEM With Masked SHA-3: Cost, Randomness, and Security Evaluation

STEFANO DI MATTEO<sup>1,2</sup>, DIAMANTE SIMONE CRESCENZO<sup>1,2</sup>, RAFAEL CARRERA RODRIGUEZ<sup>3</sup>, EMANUELE VALEA<sup>1,2</sup>, FLORENT BRUGUIER<sup>1,3</sup>, (Member, IEEE), AND PASCAL BENOIT<sup>1,3</sup>

Corresponding author: Stefano Di Matteo (stefano.dimatteo@cea.fr)

This work was supported by French National Research Agency (ANR) through CARNOT LIST AxPQC under Grant ANR-22-PETQ-0008 PQ-TLS.

**ABSTRACT** Hash functions are fundamental for ensuring authenticity and integrity in digital communications. Their importance has grown with the advent of Post-Quantum Cryptography (PQC), as many newly standardized PQC algorithms, such as ML-KEM, heavily rely on hash functions for pseudo-random number generation. Among available standards, SHA-3, published by NIST in 2015, is the recommended choice for PQC applications. However, its adoption in embedded platforms remains limited, particularly in the presence of security threats such as side-channel attacks (SCAs). To mitigate SCAs, masking techniques are widely employed, but their implementation on SHA-3 accelerators is complex due to the non-linearity of the Keccak function. Domain-Oriented Masking (DOM) provides strong security guarantees but requires a significant amount of randomness, introducing additional implementation costs often overlooked in the literature. For instance, existing DOM implementations of Keccak demand 1600 bits of fresh randomness per clock cycle, raising practical concerns about randomness generation and deployment overhead. In this work, we present a hardware accelerator supporting all the SHA-3 functions with first-order masking countermeasure based on a DOM implementation of the Keccak core. For the generation of the randomness required by the DOM countermeasure, we implemented a randomness dispatcher based on Trivium and Bivium ciphers, and we evaluated the cost in terms of area of the circuit in FPGA and ASIC of the countermeasure and of the randomness generation. In addition, we assess its security through Test Vector Leakage Assessment on FPGA. Finally, the accelerator is integrated into a RISC-V-based 32-bit SoC and used to accelerate a first-order masked implementation of ML-KEM, achieving a speed-up ranging from 95x to 264x for the SHA-3-based functions of the KEM decapsulation.

**INDEX TERMS** Domain-oriented masking, side-channel attacks, SHA-3, randomness generation, PQC, ML-KEM.

## I. INTRODUCTION

Hash functions play a crucial role in ensuring confidentiality and integrity in digital communications, since they can be flexibly used for both *message authentication* and *pseudo-random number generation* (PRNG). In addition, the recent

The associate editor coordinating the review of this manuscript and approving it for publication was Mohamad Afendee Mohamed<sup>1,2</sup>.

advent of *Post-Quantum Cryptography* (PQC) has further amplified their importance, as most newly standardized PQC algorithms heavily rely on hash functions for the generation of random numbers or polynomials [1]. Among PQC standards, lattice-based algorithms, such as ML-KEM [2], serve as an illustrative example, as most of their execution time is spent on the generation of pseudo-random polynomials through hash functions [1], [3], [4].

<footnote n="1">¹CEA, LETI, University Grenoble Alpes, 38000 Grenoble, France</footnote>

<footnote n="2">²CEA, LIST, University Grenoble Alpes, 38000 Grenoble, France</footnote>

<footnote n="3">³LIRMM, CNRS, University of Montpellier, 34095 Montpellier, France</footnote>
The use of hash functions is regulated by standards, such as the most recent SHA-3 standard, published by the National Institute of Standards and Technology (NIST) in 2015 [5]. The SHA-3 standard offers a set of specifications for implementing several types of hash functions based on the common Ke'accak primitive, and it is recommended by the NIST for the implementation of hash functions needed in PQC algorithms [2]. Due to its recent standardization, hardware support for SHA-3 functions remains limited in most embedded microprocessors. On top of this, the threat of physical attacks, such as Side-Channel Attacks (SCAs) is of paramount importance. For this reason, it is fundamental to protect PQC implementations against SCAs, requiring the additional cost of implementing countermeasures in all their sub-functions, including the hash functions [6]. One of the most popular countermeasures is masking, that is based on the obfuscation of secret data by splitting them into random independent shares. Implementing masking on hardware accelerators for SHA-3 functions is not trivial. In fact, masking non-linear operations requires the combination of different shares, which can lead to leakage due to recombination and micro-architectural glitches; to mitigate this, masking techniques such as Domain-Oriented Masking (DOM) [7] may be needed.

The application of masking to hardware implementations of the Ke'accak function has been extensively studied by the scientific community. However, the implementation costs of masking are often only partially considered. Beyond the area overhead introduced by the masked implementation, a frequently overlooked cost in the literature is the additional randomness required to refresh intermediate shares. For instance, the DOM implementation of Ke'accak proposed in [8] requires the generation of 1600 bits of randomness per clock cycle throughout the execution of the Ke'accak function. The practical feasibility of providing such a large amount of randomness, along with its associated implementation cost, remains a largely unexplored subject [9].

In this paper, we present a first-order masked SHA-3 hardware accelerator based on a DOM implementation of the Ke'accak core. Our goal is to fairly and comprehensively evaluate the implementation cost of the masking countermeasure compared to an unprotected implementation, considering not only the overhead of the masking itself but also the randomness generation required by the DOM scheme. We assess the security of the proposed design through a Test Vector Leakage Assessment (TVLA) [10]. Furthermore, we integrate the proposed accelerator into a 32-bit RISC-V based System-on-Chip (SoC) architecture and use it to accelerate a first-order masked implementation of the ML-KEM PQC standard.

The contributions provided by this work can be summarized as follows:

* we propose a first-order masked SHA-3 accelerator, able to execute all the functions of the standard, based on the DOM implementation of the Ke'accak function of [8];

* we propose an architectural solution for managing the randomness generation required by the DOM countermeasure, based on stream ciphers, called Randomness Dispatcher;

* we evaluate the implementation cost of the masking countermeasure, considering both the area overhead introduced by the masking itself and the additional overhead required for deploying the Randomness Dispatcher;

* we assess the security of the proposed accelerator through a TVLA conducted on an FPGA platform.

* we integrate the accelerator on a RISC-V based 32-bit SoC and we use it to accelerate a first-order masked implementation of the ML-KEM PQC algorithm, showing from 95x to 264x of speed-up for the SHA-3-based functions and a 50% reduction of the execution time on the decapsulation function.

While acknowledging the importance of fault-injection attacks, this work focuses on side-channel leakage, leaving fault-attacks mitigation for future study. The rest of the paper is organized as follows: Section II provides an overview of the fundamentals of this paper: the role of SHA-3 functions in Post-Quantum Cryptography, Side-Channel Attacks and the first-order masked implementation of the ML-KEM algorithm. Section III depicts the state of the art about masked architectures of Ke'accak and randomness generation for masking, and highlights the research gaps. Section IV contains a detailed description of the proposed accelerator for masked SHA-3 functions, the Randomness Dispatcher and the RISC-V SoC used to prototype the proposed solution. Implementation results and security analysis of the proposed countermeasure are reported in Section V. Finally, Section VI draws some conclusions.

## II. BACKGROUND

### A. THE SHA-3 STANDARD AND THE KECCAK FUNCTION

The SHA-3 standard has been specified by the NIST in the Federal Information Processing Standard (FIPS) 202 [5], that specifies two families of functions: SHA-3 functions and SHAKE functions. SHA-3 functions are meant to be used for hashing data, while SHAKE functions are used as eXtendable Output Functions (XOFs), thus for pseudo-randomness generation.

A hash function is a deterministic algorithm that transforms input data of arbitrary size into a fixed-size output, called a *hash* or *digest*, ensuring that even slight changes in the input result in significantly different outputs. XOFs are an extension of a hash function: the produced output can be of variable length, allowing for the generation of arbitrarily long hash values by continually extracting additional output. XOFs can be used to generate pseudo-random streams when given a truly random seed as input. As reported in Table 1, the FIPS 202 standard specifies the characteristics of four hash functions and two XOF functions, which are constructed thanks to the underlying Ke'accak sponge function.
Ke'accak [11] is a versatile cryptographic function used as
hash function, authenticated encryption and pseudo-random
number generation. Its structure, shown in 1, is the well-
known sponge construction [12]. From a general standpoint,
a sponge construction can be viewed as a function that takes
an input of arbitrary size and produces an output of any length
required by the user. The sponge construction is composed
mainly of three components: a state register, whose size is
defined by the rate section r, where the message will be
absorbed, plus the capacity section c, which are additional
bits needed to improve security; a permutation function (f)
of fixed length which transforms the state; a padding function
which appends enough bits to the input message such that the
total input length is a whole multiple of r. The permutation
function of Ke'accak, which is named Ke’accak-p[1600,24],
is made of 24 iterations of the same round. The round is in
turn made of 5 permutation steps: 4 linear ones (θ, ρ, π, ι)
based on simple bit-wise operations (i.e., XORs, rotations,
addition of constants), and one non-linear step (χ) that also
involves the AND operator.

<figure><img src="image_2.png" /><figcaption>FIGURE 1. Ke'accak sponge function.</figcaption></figure>

To implement the SHA-3 family of hash functions, the input must be *padded*, divided into blocks of size *r*, and then *absorbed*. The digest of the message is extracted from the *rate* section of the state register after the permutation function is applied to the last absorbed message block. The size of the digest depends on the required security level, along with the *rate* and *capacity* parameters, as shown in 1. For what concerns the SHAKE family of XOFs, the fixed-length input is absorbed analogously. However, the output can be of arbitrary length and it is extracted from the entire *rate* section of the state register.

B. SIDE-CHANNEL ATTACKS AND MASKING COUNTERMEASURE

Side Channel Attacks (SCAs), discovered by Kocher et al. [13], leverage physical signals produced during computation of a cryptographic algorithm, such as power consumption, electromagnetic radiation, and execution time, to infer sensitive information. Masking is a countermeasure against side-channel attacks that aims to protect sensitive data by introducing randomness into cryptographic computations. By splitting critical variables (e.g., secret keys) into randomized shares that are independently processed, masking

<table><caption>TABLE 1. Parameters of FIPS 202 functions (bits).</caption><thead><tr><th>Function</th><th>r</th><th>c</th><th>Output Size</th></tr></thead><tbody><tr><td>SHA3-224</td><td>1152</td><td>448</td><td>224</td></tr><tr><td>SHA3-256</td><td>1088</td><td>512</td><td>256</td></tr><tr><td>SHA3-384</td><td>832</td><td>768</td><td>384</td></tr><tr><td>SHA3-512</td><td>576</td><td>1024</td><td>512</td></tr><tr><td>SHAKE128</td><td>1344</td><td>256</td><td>Unlimited</td></tr><tr><td>SHAKE256</td><td>1088</td><td>512</td><td>Unlimited</td></tr></tbody></table>

ensures that no single physical signals directly correlates with
the original value.

Masking works by breaking the statistical dependency
up to a certain order by randomizing intermediate values
while maintaining correctness. For instance, let $x$ be a critical
intermediate variable and $y = f(x)$ be a function applied
on such variable. A way of masking is to split $x$ and $y$ into
$d+1$ shares, such that $x = r(x_0, x_1, x_2, \dots, x_d)$ and $y =
r(y_0, y_1, y_2, \dots, y_d)$, where $r(\cdot)$ is a recombination function,
each of the shares of $x$ and $y$ are statistically independent
of $x$ and $y$ and $d$ is the order of the masking. If $x$ and $y$
are variables in a Galois field of characteristic 2, $GF(2^p)$,
the recombination function can be simply a bitwise XOR.
To avoid statistical dependencies, the masked version of
the $f$ function, that we call $\mathcal{F}^{(d)}$, must comply with three
properties: correctness, such that $y$ can be recovered from the
shares generated by $\mathcal{F}^{(d)}$, non-completeness, such that every
function in the set is independent of at least one share of $x$ and
uniformity, such that there is not any statistical bias on any of
the shares. If $f$ is linear, then simply each of the functions
in $\mathcal{F}^{(d)}$ are equal to $f$ and they act on a single share of $x$,
provided that $f$ does not produce a statistical bias. When $f$ is
not linear, the computation needs to combine multiple shares,
which can cause recombination of the shares and leakage of
information; in Ke'accak, this applies to the non-linear step $\chi$,
which must be accurately implemented to avoid unwanted
leakage.

In hardware masked circuits, one physical phenomena that
may produce unwanted recombination is *glitching* [14]. It can
be defined as the presence of multiple switching in a single
clock cycle, which can occur by the inherent imbalance
in critical paths in a circuit. Two of the possible solutions
for avoiding glitches are: Threshold Implementations (TI),
proposed by Nikova et al. [15] and Domain Oriented Masking
(DOM), proposed by Gross et al. [7]. Based on multi-
party computation, TI aims to comply to the three security
properties of masking schemes by increasing the number
of input shares to $s_{in} \ge td+1$, where $t$ is the algebraic
degree of the operation and $d$ is the equivalent security
order. DOM on the other hand, keeps the number of shares
to $d+1$, by separating domains of inputs and resharing
with a register stage when domains are crossed. In general,
the techniques of creating glitch-resistant masked circuits
lie on the fine balance of latency increase and randomness
requirements, by augmenting the number of shares or
resharing.
### C. SHA-3 FUNCTIONS IN MASKED ML-KEM

The ML-KEM [2] is a recently standardized protocol for Key Encapsulation Mechanism (KEM), which allows establishing a shared secret key between two parties communicating over a public channel. Like all NIST-selected PQC algorithms, ML-KEM relies heavily on SHA-3 functions for its cryptographic construction.

The construction of the ML-KEM scheme proceeds in two main steps: the first leverages the hardness of the Module Learning With Errors (MLWE) problem to build a public-key encryption (PKE) scheme, which is used to encrypt and decrypt a shared secret, providing IND-CPA (Indistinguishability under Chosen Plaintext Attack) security. The second step converts the PKE scheme into a key-encapsulation mechanism using the Fujisaki-Okamoto (FO) transform, providing IND-CCA (Indistinguishability under Chosen Ciphertext Attack) security.

In ML-KEM, the decapsulation function is the most critical for both performance and security reasons compared to the others. According to the FO transform, the decapsulation function must decrypt the received ciphertext, re-encrypt it, and verify the equality between the received and re-encrypted ciphertexts. This procedure is the most time-consuming compared to key generation and encapsulation. Additionally, the decapsulation function may use the private key multiple times for different executions of the KEM protocol, which opens the door to a range of side-channel attacks that require multiple traces (e.g., power or electromagnetic emission), such as Differential Power Analysis (DPA) [6]. For this reason, the decapsulation function is the main target for masking countermeasures, which protect or at least mitigate against such attacks.

#### Algorithm 1 ML-KEM.Decaps

**Require:** Ciphertext $c$

**Require:** Decapsulation key

1. $dk \leftarrow (s, pk, \text{SHA3-Hash}(pk), z)$

**Ensure:** Shared key $K$

2. $m' \leftarrow \text{PKE.Decrypt}(s, c)$

3. $(K', r') \leftarrow \text{SHA3-Hash}(m' \parallel \text{SHA3-Hash}(pk))$

4. $K'' \leftarrow \text{SHA3-Hash}(z \parallel c)$

5. $c' \leftarrow \text{PKE.Encrypt}(pk, m', r')$

6. **if** $c = c'$ **then**

7. **return** $K'$

8. **else**

9. **return** $K''$

10. **end if**

Algorithm 1 reports the ML-KEM.Decaps function: it exploits the PKE.Decrypt function (line 1) to retrieve a shared secret message $m'$, the $G()$ function (SHA3-512) to compute the shared key $K'$, the $J()$ function (SHAKE-256) to compute an ephemeral shared key $K''$, and the PKE.Encrypt function to recompute the ciphertext to guarantee CCA security. Algorithms 2 and 3 report the PKE.Decrypt and PKE.Encrypt functions, respectively. SHAKE-256 is used to

#### Algorithm 2 PKE.Decrypt

**Require:** Secret key $s$

**Require:** Ciphertext $c = (c_1, c_2)$

**Ensure:** Message $m$

1. $\mathbf{u} \leftarrow \text{Decompress}_q(c_1, d_u)$

2. $v \leftarrow \text{Decompress}_q(c_2, d_v)$

3. $m \leftarrow \text{Compress}_q(v - s \cdot \mathbf{u}^\top, 1)$

4. **return** $m$

#### Algorithm 3 PKE.Encrypt

**Require:** Public key $pk = (\text{seed}_A, \mathbf{b})$

**Require:** Message $m$

**Require:** Seed $r$

**Ensure:** Ciphertext $c = (c_1, c_2)$

1. $\mathbf{A} \leftarrow \mathcal{U}(\mathbb{Z}_q^{k \times k})^{\text{seed}_A}$

2. $(\mathbf{s}', \mathbf{e}_1, \mathbf{e}_2) \leftarrow \Psi_{\eta_1} \times \Psi_{\eta_2} \times \Psi_{\eta_2}^{\text{SHA3-XOF}(r)}$

3. $\mathbf{u} \leftarrow \mathbf{A} \cdot \mathbf{s}' + \mathbf{e}_1$

4. $v \leftarrow \mathbf{b}^\top \cdot \mathbf{s}' + \mathbf{e}_2 + \lfloor q/2 \rfloor \cdot m$

5. $c_1 \leftarrow \text{Compress}_q(\mathbf{u}, d_u)$

6. $c_2 \leftarrow \text{Compress}_q(v, d_v)$

7. **return** $(c_1, c_2)$

transform seeds into pseudo-random values for generating lattice parameters (line 2 of Algorithm 3), while SHAKE-128 is used to expand the matrix $\mathbf{A}$ from seed$_A$ (line 1 of Algorithm 3).

According to Section II-B, a first-order masked implementation of the ML-KEM decapsulation function requires that all sensitive data are split into two independent shares; a schematic representation is shown in Figure 2. Here, variables in red are sensitive and split into shares (e.g., $s^0, s^1$), while variables in green are non-sensitive and remain unmasked. In Figure 2 we emphasize the role of SHA-3 functions: red boxes correspond to masked instances of SHA-3 functions operating on sensitive data, whereas green boxes correspond to unmasked instances operating on public data.

The masked PKE.Decrypt function decrypts the ciphertext $(c_1, c_2)$ with the masked secret key shares $s^0$ and $s^1$. The resulting masked message shares $m'^0$ and $m'^1$ are concatenated with $\mathcal{H}(pk)$ and hashed with the masked $G()$ function: the least significant 256 bits of the result correspond to the masked shared key $(K'^0, K'^1)$, and the most significant 256 bits serve as seed for the masked XOF (masked SHAKE-256) functions in the masked PKE.Encrypt. The sequence of XOF-CBD-B2Aq operations in Figure 2 corresponds to line 2 of Algorithm 3. The B2Aq block converts Boolean masked variables into their arithmetic representation. The public matrix $\mathbf{A}$ is generated from seed$_A$ using the unmasked SHAKE-128. All polynomial operations of PKE.Encrypt (lines 3 and 4 of Algorithm 3) are grouped in the Poly box. The Masked Compress block (lines 5 and 6 of Algorithm 3) produces the masked ciphertext shares, which must be securely compared with the original unmasked ciphertext: this can be done by verifying $\mathcal{H}(c^1 \oplus c_1^0) = \mathcal{H}(c_1^1)$
<figure><img src="image_3.png" /><figcaption>FIGURE 2. Schematic view of the first-order masked ML-KEM.Decaps function. Red boxes indicate FIPS 202 functions in masked form, while green boxes in unmasked form.</figcaption></figure>

and $\mathcal{H}(c^2 \oplus c_2^0) = \mathcal{H}(c_2^1)$. If equality holds, the masked shared key $K^0, K^1$ is returned; otherwise, the ciphertext and masked random values $z^0, z^1$ are hashed with the masked $J()$ function to produce the final output.

### III. RELATED WORKS

#### A. MASKED KECCAK HARDWARE ARCHITECTURES

The first masked accelerator for Keccak was introduced by the Keccak developers in [16]. This architecture employs a three-share scheme for first-order security. However, [17] later identified a security flaw due to the absence of the *uniformity property* in the non-linear $\chi$ step, which can lead to information leakage in side-channel attacks. To mitigate this, researchers proposed two solutions: adding a fourth data share or incorporating *fresh randomness* after each $\chi$ step. These approaches were implemented in ASIC hardware using the evaluation platform from [18], which includes both the original three-share non-uniform solution and its improved variants. Subsequent works introduced further enhancements. Hardware *glitches*, a known source of leakage, were addressed in [19] by combining *threshold implementations (TI)* with DOM. However, [18] demonstrated that applying TI resulted in the loss of non-completeness. To counteract this, [20] proposed an algorithm-level solution offering a low-latency implementation with countermeasure costs dependent on the Keccak permutation width.

The final design we analyzed, from [8], was selected for our SHA-3 masked hardware accelerator. This implementation is optimized for minimal *shares*, making it more efficient than TI-based solutions while maintaining a low-latency operation of one round per clock cycle, similar to [16]. Figure 3 refers to the architectural scheme of the masked Keccak core from [8]. The term *d* indicate the masking order, which in our case is set to 1. Thus, each share has a width of 1600 bits, according to the parameters of the Keccak function used in the FIPS 202 standard.

Here, we describe the Keccak core from a hardware perspective, focusing on the scenario considered in this paper,

<figure><img src="image_4.png" /><figcaption>FIGURE 3. High-level architecture of the masked Keccak core [8]. *d* is equal to the masking order. The input passes through diffusion ($\theta$), registers, and the permutation steps ($\pi \circ \rho$) for shuffling/rotation and $\iota \circ \chi$ for nonlinear mixing. Refreshing ensure the state remains securely masked against side-channel leakage.</figcaption></figure>

i.e., when $d = 1$. The input data can assume a bit size that depends on the selected FIPS 202 algorithm, as reported in the column *r* of Table 1. Before the *Mux. 1*, the inputs are padded with zeroes, and four shares are constructed. The $\theta$ function acts on four shares, and it is followed by one 1600-bit register per share (6400 bits). This register is needed for two main purposes: it samples the results of each round of the Keccak transformations (functional purpose) and it avoids recombination of the shares due to glitches (security purpose). In addition, to preserve *non-completeness*, the $\chi$ and $\theta$ functions are aligned so that each $\chi$ component receives only a single input share. This structure prevents unintended recombination, mitigating glitches. The compression stage compresses four shares into two; this point of the circuit is used as output point for the last round of Keccak, thanks also to the *Mux. 2* that bypasses the $\theta$ function at the end of the last round. According to the DOM principle, the refreshing function is applied to cross-domains to restore uniformity: this operation requires a 1600-bit share made of fresh randomness.

Unlike previous works that focus solely on accelerating masked Keccak, our contribution stands out by proposing a complete SHA-3 masked accelerator, fully integrated and operational within a realistic cryptographic context. Existing designs, while offering valuable solutions for masking Keccak, often neglect essential aspects for practical
deployment, including the efficient management of randomness generation.

## B. RANDOMNESS GENERATION FOR MASKED IMPLEMENTATIONS

Masked implementations of cryptographic algorithms typically require a substantial amount of randomness per clock cycle—a factor often overlooked in research focused on masking techniques. However, for masked SHA-3 implementations, this issue is particularly critical: in one-round-per-cycle designs, executing Ke'accak demands up to 1600 bits of fresh randomness per clock cycle.

Most of the works in literature adopt Linear Feedback Shift Registers (LFSR) for this purpose, without further analysis on the security of this method. The work in [8] for instance, employs a 31-bit LFSR with the feedback polynomial $x^{31} + x^{28} + 1$, which is seeded randomly at the power up of the device and updated at every clock cycle. A similar approach is adopted in [21] and [22]. The work in [23] considers a 64-bit LFSRs with feedback polynomial $x^{64} + x^{63} + x^{61} + x^{60} + 1$, in order to increase the period of oscillation. Moreover, the authors state that LFSRs do not provide security against state recovery, meaning that the knowledge of a certain number of outputs leads to a full recovery of the shift register. Nevertheless, authors remark that the security against state recovery may not be required in the context of SCA. In addition, the authors estimate the area overhead of LFSRs solutions compared with PRNG based on Ke'accak function (unrolled and round-based). This analysis shows that only unrolled versions of Ke'accak can be suitable for randomness generation but with a high cost in terms of resource consumption.

The work in [24] deeply analyzes different ways to generate randomness for secure hardware masking schemes, in particular they evaluate the efficiency and security of three classes of random number generators: True Random Number Generators (TRNGs), LFSRs and PRNG based on stream ciphers, block ciphers and permutations. In the case of TRNGs, the authors explored the architectures proposed in [25], [26], [27], and [28], which represent the most efficient in the state of the art. The authors concluded that PRNG-based solutions present higher throughput-area ratio with respect to TRNGs. For what concerns LFSRs, the authors demonstrate security weaknesses of unrolled LFSRs in three use cases with a practical analysis (i.e., statistical t-test) on FPGA and a theoretical attack. For PRNG implementations, the authors compared the most cost-efficient NIST lightweight block ciphers like Subterranean 2.0, Gimli and SPEEDY, and the stream ciphers Trivium and its reduced version Bivium B, submitted to the eSTREAM competition.

The usage of stream ciphers as PRNGs has been shown to be of particular interest. Stream ciphers are commonly used for encryption, relying on internal architectures that are based on Non-Linear Shift Registers (NLFSRs). Stream ciphers take as input a secret key and an Initialization Vector (IV) and they produce a serial output of

pseudo-random bit, that is commonly called *keystream*. In the cipher scenario, the keystream can be used for encrypting a message, through bit-wise XOR of the message bits with the keystream bits. Alternatively, the keystream can be directly used as a *pseudo-random* sequence of bits. This last usage is the one that is of interest for randomness generation in masked implementations, as has been showed in [24]. The authors consider unrolled versions of the target stream ciphers, thus being able to generate multiple bits of pseudo-randomness per clock cycle. In particular, they show that the usage of the Trivium, or Bivium, stream ciphers with an unrolling level of 64 bits (i.e., 64 random bits generated per clock cycle) are the most efficient in term of area-performance trade-off.

# IV. PROPOSED MASKED SHA-3 ACCELERATOR

## A. MASKED SHA-3 ACCELERATOR

In this Section, we will describe the architecture of the proposed masked SHA-3 accelerator. The accelerator has been designed to be compatible with 32-bit systems, which is the word size for both input and output modes. In fact, specific control signals to handle bus transactions have been included in the design, both for control and data bits. Figure 4 shows the top-level architecture of the accelerator.

<figure><img src="image_5.png" /><figcaption>FIGURE 4. Architecture of the proposed masked SHA-3 accelerator.</figcaption></figure>

The accelerator includes four main parts: the Input Management Module, the Output Management Module, the Masked Ke'accak core and the Control Unit. The Input Management Module prepares input data, including padding, before they are stored in one of the register files (REG File in Figure 4). Two distinct 1344-bit register files are employed, each one dedicated to a distinct share. Byte-wise padding, consisting of a delimiter, zero bytes, and an end marker, is applied exclusively to the 32-bit words of a single share. This design choice is crucial to avoid deterministic cancellation of the padding during recombination: applying identical padding to both shares would cause the padding bytes to cancel out when they are combined. The hardware circuit is implemented through four byte-selection multiplexers forming a 32-bit output word. These multiplexers select between original data, zero bytes, padding delimiters for SHA-3 and SHAKE, or padding end-markers.
The Masked Ke'accak core is based on the work of [8], as described in Subsection III. The core executes one round of the Ke'accak function in one clock cycle on both shares. It takes as input two shares of 1600-bit, so the output of the register files (1344-bit) is zero-padded before being sent to the Ke’accak core. The zero-padding is necessary for those bits that always belong to the capacity part of the state. The FRESH RANDOMNESS input is required by the DOM countermeasure, and it should be fed with 1600-bit of fresh randomness per clock cycles during the execution of Ke’accak. The Output Management Module constructs the output stream starting from the internal state of the Ke’accak core, by selecting (Output Selection Unit) internal registers from the register files and zeroing bytes (Output Masking Unit), enabling byte-aligned outputs for SHAKE and SHA-3 functions. The Control Unit manages the operation flow and the modes of operation of the accelerator.

B. MODES OF OPERATION

The proposed accelerator supports all the FIPS 202 algo-
rithms, as reported in Table 1, in both masked and unmasked
version. In fact, the KEM.Decaps function requires both
masked implementations of FIPS 202 algorithms (i.e., SHA-
3-512 and SHAKE-256 in the red boxes of Figure 2), and
unmasked implementations (i.e., SHAKE-128 and SHA-
3-256 in the green boxes of Figure 2). This requirement
can also be extended to other masked implementations of
PQC algorithms. This functionality has been implemented
thanks to a set of commands managed by the Control Unit.
This module is in charge of orchestrating all the datapath
components described in Section IV-A. The Control Unit
recognizes and manages the following commands:

*   **RESET**: this command resets the entire accelerator, by setting all the internal registers to zero and by forcing the internal Finite State Machine (FSM) to an idling state.

*   **RD_SH1**: this command configures the datapath in order to store the first share of the input message into the *REG File 1*. It will expect one message word per clock cycle whenever the input data is available; otherwise, it will suspend the reading operation.

*   **RD_SH2**: this command sets the datapath up to receive the second share of the input message, similarly to the **RD_SH1** state, but now the incoming share is stored into the **REG File 2**. When the storing phase is complete, it proceeds with the computation of one of the supported FIPS 202 functions. This command must be used when the incoming data corresponds to the first block of a new message.

*   **RD_SH2GNR**: performs the storing phase in the
    exact same way as the previous one. When this is
    complete, it proceeds with a hash function absorption.
    To be used when the passed input data is a new block of
    the same input message whose computation previously
    started.

*   SQUEEZE: whenever a SHAKE function has been computed, this command allows to request the computation of additional bytes to realize the XOF functionality.

*   **OUTPUT**: with this command, the accelerator outputs the two shares word-wise. They are output one after the other, potentially one word per clock cycle.

The instruction format of the accelerator includes one
of the commands described above plus the size of the
message block to be processed; this field is accepted by
the accelerator only for the commands RD_SH1, RD_SH2
and RD_SH2GNR, which require knowledge of the
message size to pad it according to the selected mode of
operation, otherwise it is ignored. Thanks to this mechanism
it is possible to manage masked and unmasked computation
of FIPS 202 functions. In case of masked computation, the
first share shall be written after the command RD_SH1,
by indicating also the size of the data block. After, the second
share can be written using RD_SH2 or RD_SH2GNR,
depending on the absorption phase (first or non-first block of
the message), again specifying the size of the block. To be
noted that in the masked computation, fresh randomness
should be provided (1600-bit of new fresh randomness per
clock cycle during the computation of Ke'accak). In the
unmasked case, the unique share (the plaintext message is
not divided in shares) should be provided in the same way
of the masked case; after that, one of the commands RD_SH2
or RD_SH2GNR shall be set (first or non-first block of
the message) but the size of the message must be set to zero,
this way the accelerator starts immediately the computation of
the selected FIPS 202 algorithm in unmasked version. In this
case, the fresh randomness shall be set to zero.

C. RANDOMNESS DISPATCHER

We have implemented a hardware module, called *Randomness Dispatcher*, in order to efficiently provide the 1600 bits per clock cycles of randomness required by the proposed masked SHA-3 accelerator. The Randomness Dispatcher is based on PRNGs, which can be implemented relying on two different stream cipher architectures, namely Trivium and Bivium.

Trivium [29] is a stream cipher that has lately been
standardized as part of the lightweight stream cipher standard
ISO/IEC 29192-3. Trivium is based on a combination of three
Non-Linear Feedback Shift Registers (NLFSRs) of degree
93, 84 and 111 (288 bits in total). It has two input parameters,
an 80-bit secret key and an 80-bit public Initialization Vector
(IV), which are loaded into the state registers at the beginning
of the operation. Then, the cipher is clocked for 1152 cycles
without producing any keystream, which corresponds to
4 rotations of the state (4 × 288 = 1152), that randomizes
the content of the registers. After the initialization phase is
completed, the online phase begins and the valid keystream
is generated. Two reduced variants of Trivium exist, called
Bivium A and Bivium B [30]. We do not focus on Bivium
A because it has been demonstrated highly unsecure (it has
<figure><img src="image_6.png" /><figcaption>FIGURE 5. 2-bit Unrolled Bivium.</figcaption></figure>

been broken in about one day [30]). Bivium B (for simplicity we call it Bivium in the paper) consists of only two of the Trivium NLFSRs, namely the 93-bit and the 84-bit ones. In Bivium, the keystream is generated as the sum of 4 state bits, 2 from each NLFSR. An interesting feature of hardware implementations of Trivium and Bivium is that they can be unrolled, which means that multiple instances are realized in hardware without any memory elements in-between so that the combinational logic of multiple steps is evaluated in a single cycle [24]. Figure 5 refers to a 2-bit unrolled version of Bivium. The dotted line indicates the unrolled path, which allows to generate the keystream with a rate that is twice that of regular Bivium.

Following this principle, the proposed hardware architecture of the Randomness Dispatcher is presented in Figure 6. It includes 25 instances of a 64-bit unrolled version of Trivium, a five stages 32-bit shift register and a finite state machine. The unrolled Trivium can be substituted by the unrolled Bivium cipher during the synthesis phase of the circuit. The output stream is composed of 1600-bit, which are the parallel outputs of the 25 Trivium ciphers, each of 64-bit. The circuit has four operating states, managed by the state machine:

*   **Idle**: the random dispatcher is not initialized and the output is set to zero.

*   **Initialization**: in this phase, all the 25 Trivium ciphers must be initialized with the IV and the key. The shift register (160 bits in total) is used for this purpose: once all the 160 bits have been written in the shift register (they correspond to the size of the IV and the key of each Trivium), its content is sampled by the state register of one of the Trivium stages. From the software point of view, this operation is completely transparent: the user shall only write the initialization sequence (160 bits for each Trivium) at the corresponding address at which the random dispatcher has been mapped in the SoC. Each state register of each Trivium is automatically filled by the finite state machine. This mechanism also enables on-demand reseeding via software at any time, allowing the internal states to be refreshed without additional hardware.

<figure><img src="image_7.png" /><figcaption>FIGURE 6. Hardware architecture of the Randomness Dispatcher. The design employs 25 parallel instances of Trivium or Bivium, each initialized with independent IV and key inputs. These parallel cores generate the required 1600-bit randomness output, controlled by the FSM and status register.</figcaption></figure>

*   **Warm-up**: in this state the content of the state registers of the 25 Trivium ciphers is randomized by means of 4 rotations of the state. This operation takes 18 clock cycles.

*   **Running**: in this state, the random dispatcher generate 1600 bits of random strings per clock cycle.

## D. INTEGRATION IN A 32-BIT RISC-V SYSTEM-ON-CHIP

We integrated the proposed masked accelerator for SHA-3 and the Randomness Dispatcher in a RISC-V System-on-Chip (SoC), reported in Figure 7. It is built around the CV32E40P, a 32-bit RISC-V core optimized for embedded applications. The processor is connected to separate instruction and data memory blocks, thanks to a 32-bit Open Bus Interface (OBI). To support development and debugging, the SoC includes standard peripherals such as a JTAG interface and a UART module. At the core of the design is our masked SHA-3 accelerator, which is tightly coupled with the dedicated Randomness Dispatcher. This dispatcher ensures the secure and timely delivery of fresh randomness required by the Domain-Oriented Masking scheme. The accelerator is memory-mapped and controlled via the RISC-V core, enabling flexible integration with higher-level cryptographic protocols. To be noted that in our SoC, no performance degradation due to bus contention is granted, since the CPU is the sole active bus master during the software execution.

## V. RESULTS AND COMPARISON

### A. IMPLEMENTATION RESULTS ON FPGA AND ASIC

Table 2 reports the synthesis results of the proposed SHA-3 accelerator plus the Randomness Dispatcher on the Artix-7 FPGA contained in the development board Arty
<figure><img src="image_8.png" /><figcaption>FIGURE 7. Integration of the Masked SHA-3 Accelerator and the Randomness Dispatcher in the target SoC.</figcaption></figure>

A7-100T of Digilent. The synthesis tool is Vivado 2021.1 and no particular optimization strategies have been applied (Vivado Synthesis Defaults). The maximum frequency on the target FPGA is 163 MHz, with an area of 18,805 LUTs and 9168 FFs. In the first row of Table 2, we reported also the synthesis results of our SHA-3 accelerator without the masking countermeasure. The maximum frequency is 166 MHz and the resource consumption is 6990 LUTs and 4706 FFs. To be noted that both architectures follow the one-round-per-clock-cycle approach: this means that the Ke'accak function takes the same number of clock cycles (i.e., 24 clock cycles). Thus, excluding the fact that the masked version works with two shares (two shares shall be written in the register file of the module), the performance of the two implementations are the same, in terms of clock cycles. The synthesis results show that the maximum frequency is not affected by the masking countermeasure on FPGA. However, the countermeasure has a significant cost in terms of hardware resources: 269% for LUTs and 194% for FFs. Concerning the Randomness Dispatcher, the version with the Trivium stream cipher consumes 11,966 LUTs and 7403 FFs. The version with the Bivium stream cipher is smaller, with 9201 LUTs and 4663 FFs. This analysis clearly shows that the area overhead of the masking countermeasure (first order) on a one-round-per-clock-cycle SHA-3 architecture should take into account also the area of the Randomness Dispatcher, which cannot be neglected. So, the real overhead is around 440% of LUTs and 352% of FFs in case of Random Dispatcher implemented with the Trivium cipher and around 400% of LUTs and 293% of FFs in the case of Random Dispatcher implemented with the Bivium cipher.

<table><caption>TABLE 2. Synthesis results of the SHA-3 accelerator and the Randomness Dispatcher on an Artix-7 FPGA.</caption><thead><tr><td>Module</td><td>LUTs</td><td>FFs</td></tr></thead><tbody><tr><td>SHA-3 Accelerator (No-masking)</td><td>6990</td><td>4706</td></tr><tr><td>SHA-3 Accelerator (Masked)</td><td>18805</td><td>9168</td></tr><tr><td>Randomness Dispatcher (Trivium)</td><td>11966</td><td>7403</td></tr><tr><td>Randomness Dispatcher (Bivium)</td><td>9201</td><td>4663</td></tr></tbody></table>

We synthesized our accelerators on a standard cell 22nm FD-SOI technology. Synthesis are performed with Synopsys

Design Compiler [31]. Figure 8 presents a design space exploration (frequency vs area) in this technology. In black, we show the area of the unmasked SHA-3 accelerator; in red, the area of the masked version. The orange section represents the combined area of the masked SHA-3 accelerator and the random dispatcher based on Bivium, while in pink, Trivium replaces Bivium as Randomness Dispatcher. We evaluated the area consumption in Gate Equivalents (GE), which is calculated as the ratio between the area of the circuit and the area of the smallest NAND2 port of the technological library. The maximum frequency of the SHA-3 accelerator is 1.76 GHz. At this frequency, the area of the SHA-3 accelerator is 213 kGE, the area of the Randomness Dispatcher with Trivium is 130 kGE, while the Bivium version takes 86 kGE. At 735 MHz, the area of the SHA-3 accelerator becomes 186 kGE, while the area of the Randomness Dispatcher remains unvaried. The area of the unmasked version of the SHA-3 accelerator ranges from 54 kGE to 64 kGE, so the overhead of the masking countermeasure ranges from 500% (at 1.76GHz with Randomness Dispatcher based on Trivium), to 300% (at 735 MHz with Randomness Dispatcher based on Bivium). Extending the accelerator to second-order masking would increase the accelerator area by more than 2x and require roughly 3x the amount of randomness [8], making higher-order masking impractical in hardware.

<figure><img src="image_9.png" /><figcaption>FIGURE 8. Synthesis results and design space exploration of the proposed accelerators on a 22nm FD-SOI standard cell technology.</figcaption></figure>

It is worth noting that the observed area overhead of 300-500% is an inherent feature of masking-based countermeasures, which should be taken into account when considering the cost of masking. In fact, as we have shown, the randomness generation, essential for granting the security of DOM implementation, is a very expensive feature that is often overlooked in the literature. While this naturally results in notable overhead, our work provides a transparent and comprehensive analysis, reporting both the cost of the masked SHA-3 accelerator and the associated randomness generation infrastructure. The absolute overhead, though high, reflects the basic cost of achieving side-channel resistance and the trade-offs involved.

## B. SECURITY ANALYSIS WITH TEST VECTOR LEAKAGE ASSESSMENT

In this Section, we present the security analysis that has been conducted in order to validate the hardware countermeasure
that has been implemented in the proposed SHA-3 accelerator. The chosen methodology is the Test Vector Leakage Assessment (TVLA) [32], [33], which is a well-established methodology in the side-channel community for leakage detection during implementation evaluation and for points-of-interest selection in attack scenarios. It is a pass/fail test based on the Welch *t* statistic. Specifically, the statistic tests the hypothesis of whether the difference between the moments of two sets of samples is significant. Our security evaluation relies on TVLA to confirm the absence of first-order leakage; although stronger attacks like CPA could offer additional insights, they are outside the scope of this study. The *t*-statistic is defined as:

$$t = \frac{\mu_0 - \mu_1}{\sqrt{\frac{s_0^2}{n_0} + \frac{s_1^2}{n_1}}} \quad (1)$$

where $\mu_0$ and $\mu_1$ are the mean values of the two sets of measurements, $s_0^2$ and $s_1^2$ are their variances, and $n_0$ and $n_1$ are the number of samples in each set. The variant of the methodology that we adopt in this security analysis is the non-specific *t*-test, where samples from random inputs are compared against samples captured when executing SHA-3 functions with a previously selected fixed input. As for the threshold for the pass/fail test, we consider a sample to be leaking when $|t| > 4.5$, as widely employed in the literature [33]. We performed statistical leakage detection according to the TVLA methodology on the FPGA board Arty A7-100, and we measured the electromagnetic emission during the execution of SHA-3 and SHAKE algorithms. We used an electromagnetic probe connected to a Tektronix MSO 6 series oscilloscope for the traces acquisition. Figure 9 (a) reports the *t*-statistic obtained with 20k traces using the SHA-3 accelerator in the unmasked mode of operation. We remark that leakage appears throughout the execution. Figure 9 (b) shows the *t*-statistic obtained with 20k traces using the SHA-3 accelerator in the masked version with the Randomness Dispatcher deactivated (OFF). In this case, the first-order masking is active, but the DOM countermeasure is not, and leakage appears due to the lack of randomness in the nonlinear operations. Specifically, the presence of shares without proper refreshing allows leakage to arise from cross-domain operations such as AND gates. Figure 9 (c) shows the *t*-statistic obtained with one million traces using the SHA-3 accelerator in the masked version with the Randomness Dispatcher activated (Trivium version). In this case, no leakage is detected ($|t| < 4.5$). Figure 10 shows the *t*-statistic obtained with 1M traces using Trivium (a) or Bivium (b) as Randomness Dispatcher. No leakage is detected in both configurations.

We acknowledge that the TVLA experiments were performed with up to 1 million traces. This number of traces is sufficient to reliably detect first-order leakage in our implementation, as widely accepted in the side-channel community [32], [33]. While attackers could, in principle, collect more traces, the results provide strong evidence of

<table><caption>TABLE 3. Execution time (in clock cycles) of masked the KEM.Decaps function using full software and SHA-3 hardware accelerator.</caption><thead><tr><th>Operation</th><th>Full-SW</th><th>SHA-3 Accel.</th><th>Gain</th></tr></thead><tbody><tr><td><strong>ML-KEM.decaps</strong></td><td>6,868,657</td><td>3,164,677</td><td><strong>2.1</strong>×</td></tr><tr><td>PKE.Decrypt</td><td>427,786</td><td>427,786</td><td>–</td></tr><tr><td>G()</td><td>179,540</td><td>678</td><td><strong>265</strong>×</td></tr><tr><td>PKE.Encrypt</td><td>4,684,373</td><td>2,729,732</td><td><strong>1.7</strong>×</td></tr><tr><td>J()</td><td>1,576,958</td><td>6,481</td><td><strong>243</strong>×</td></tr><tr><td><strong>PKE.Decrypt</strong></td><td>427,786</td><td>427,786</td><td>–</td></tr><tr><td>masked_polylotmsg</td><td>67,833</td><td>67,833</td><td>–</td></tr><tr><td>poly arithmetic</td><td>350,589</td><td>350,589</td><td>–</td></tr><tr><td>decompression</td><td>9,364</td><td>9,364</td><td>–</td></tr><tr><td><strong>PKE.Encrypt</strong></td><td>4,684,373</td><td>2,729,732</td><td><strong>1.7</strong>×</td></tr><tr><td>CBD</td><td>572,362</td><td>572,362</td><td>–</td></tr><tr><td>poly_frommsg</td><td>546,009</td><td>546,009</td><td>–</td></tr><tr><td>hash</td><td>1,975,347</td><td>20,706</td><td><strong>95</strong>×</td></tr><tr><td>poly arithmetic</td><td>1,244,689</td><td>1,244,689</td><td>–</td></tr><tr><td>compare</td><td>345,966</td><td>345,966</td><td>–</td></tr></tbody></table>

first-order resistance, and extending the experiments to larger trace counts is expected to confirm the trends observed.

### C. MASKED ML-KEM PERFORMANCE WITH MASKED SHA-3 ACCELERATOR ON A RISC-V SOC

The proposed hardware accelerator for SHA-3 and the Randomness Dispatcher have been deployed in the SoC described in Section IV-D, which has been used for the execution of a first-order masked implementation of ML-KEM. We considered the masked implementation from [34] as baseline for our masked ML-KEM.

As first step, we updated the code according to the latest NIST standard for ML-KEM (FIPS 203 [2]). The implementation from [34] includes dedicated assembly instructions for ARM processors of several functions: NTT, masking conversions, binomial sampling and others. Consequently, we rewrote all such functions in clean C language, in order to be compatible with our CV32E40P RISC-V processor. Table 3 reports the execution time of the masked KEM.Decaps, running on the target platform. We reported the clock cycles taken by the full-SW implementation running on the CV32E40P processor (second column of Table 3), and the SW implementation accelerated through the masked SHA-3 accelerator (third column of Table 3). We divided hierarchically the contributions of the subroutines included in the KEM.Decaps, by considering the hash functions G() and J(), the PKE.Decrypt and the PKE.Encrypt. In addition, we extended this analysis also for the PKE.Decrypt and the PKE.Encrypt. The full-SW implementation of KEM.Decaps takes approximately 6.8 million clock cycles, with around 62% of this time consumed by the SHA-3 functions, as shown in Figure 11. In particular, the J() function alone takes over 1.5 million clock cycles, while the combined contribution of all SHA-3 functions within PKE.Encrypt accounts for nearly 2 million clock cycles. Thanks to hardware acceleration, the execution time of the J() function is reduced by a factor of 243, the G() function by a factor of 264, and the total contribution of the hash functions in PKE.Encrypt is reduced
<figure><img src="image_10.png" /><figcaption>**FIGURE 9.** Leakage assessment of the masked SHA-3 accelerator during one round of the Keurm function. Horizontal red lines correspond to the threshold of $|t| = 4.5$ above which we are in the presence of information leakage. (a) $t$-statistic obtained with 20k traces with the SHA-3 accelerator used in the unmasked mode of operation. (b) $t$-statistic obtained with 20k traces with the SHA-3 accelerator used in masked version with the Randomness Dispatcher OFF. (c) $t$-statistic obtained with 1M traces with the SHA-3 accelerator used in masked version with Randomness Dispatcher (Trivium version) ON.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>**FIGURE 10.** In (a) the $t$-statistic obtained with 1M traces with the SHA-3 accelerator used in masked version with Randomness Dispatcher (Trivium version) ON. In (b) the $t$-statistic obtained with 1M traces with the SHA-3 accelerator used in masked version with Randomness Dispatcher (Bivium version) ON.</figcaption></figure>

<figure><img src="image_12.png" /><figcaption>**FIGURE 11.** On the left side, cycles count and percentage of the Full-SW implementation of the KEM. Decaps divided per family of primitives (SHA-3 functions, polynomial computation and others). On the right side, the SW implementation accelerated by the proposed masked SHA-3 accelerator.</figcaption></figure>

by a factor of 95. Overall, KEM.Decaps is accelerated by a factor of 2. More notably, the share of SHA-3 functions in the total runtime drops from 62% (in the full-software implementation) to just 1% when using the proposed SHA-3 hardware accelerator.

## D. COMPARISON WITH THE STATE OF THE ART

This work presents a deployable SHA-3 accelerator for post-quantum cryptography with masking-based counter-measure against physical attacks. It supports both masked and unmasked modes, efficiently handles randomness generation through a dedicated hardware module, and is evaluated in a real-world use case. We assess the cost of randomness, measure the performance gain in masked ML-KEM decapsulation, and validate security through TVLA. A comprehensive comparison with related work is challenging, as the literature offers limited results on fully masked,

deployable SHA-3 accelerators with integrated randomness generation and system-level evaluation. In comparison to [6], which proposes a set of hardware accelerators and instruction set extensions targeting post-quantum cryptographic workloads—including support for NTT operations and masking conversions—our work focuses specifically on the SHA-3 functions, which are the dominant computational component in masked ML-KEM decapsulation. While [6] addresses a broader scope by accelerating other arithmetic primitives, their SHA-3 implementation differs significantly from ours: we propose a one-round-per-cycle masked SHA-3 accelerator, designed for high throughput and full compliance with the FIPS 202 standard in both masked and unmasked modes. This architectural choice enables substantially higher performance; however, a direct numerical comparison is not possible, as [6] does not provide detailed latency or cycle-level results for their SHA-3 implementation. A comparison with [34], which presents a full software implementation of masked Kyber on ARM Cortex-M4, highlights important differences in both scope and methodology. Their implementation achieves faster performance than our software baseline, primarily because it targets an earlier draft of the ML-KEM specification, whereas we adopt the final standardized version (FIPS 203). Additionally, [34] includes heavily optimized assembly routines for computationally intensive components such as the NTT and masking conversions. In contrast, our implementation is entirely written in portable C to ensure compatibility with a generic 32-bit RISC-V core, and focuses specifically on hardware acceleration of SHA-3 functions,
which are the dominant runtime component in masked ML-KEM decapsulation. The acceleration of NTT and masking conversions is explicitly out of the scope of this work, which concentrates instead on analyzing the cost and performance trade-offs of SHA-3 masking and randomness generation. Due to these differences in algorithm version, optimization level, and system targets, a direct performance comparison is not meaningful, but the two works are complementary: [34] advances optimized software for lattice arithmetic, while we focus on secure and efficient hardware acceleration of the cryptographic hash layer. Other relevant works include [35] and [36], which explore full hardware implementations of masked Kyber with side-channel protections. However, a direct comparison with our work is not possible due to the different focus of these papers: they target lattice-based arithmetic and masking of polynomial operations, while our work concentrates specifically on the cost, performance, and security of masked SHA-3 acceleration.

## VI. CONCLUSION

In this work, we presented a first-order masked SHA-3 hardware accelerator built upon a Domain-Oriented Masking (DOM) implementation of the Ke'accak function, targeting secure and efficient deployment in post-quantum cryptographic applications. We highlighted the often-overlooked costs associated with the high randomness requirements of DOM, which demand 1600 bits of fresh randomness per clock cycle for one-cycle-per-round implementation of Ke'accak. Our design was rigorously evaluated on FPGA using Test Vector Leakage Assessment, confirming its robustness against first-order side-channel attacks. Furthermore, by integrating the accelerator into a RISC-V-based 32-bit SoC and applying it to a masked ML-KEM implementation, we demonstrated significant performance gains, achieving up to 264x speed-up for SHA-3-based functions during KEM decapsulation. However, the proposed approach also comes with important limitations. In particular, the first-order countermeasure introduces a large area overhead, ranging from 300% to 500% on ASIC compared to an unprotected design. For higher-order protections, this overhead would increase even further, making scalability a major challenge. Overall, these results emphasize both the benefits and the trade-offs of deploying masked SHA-3 accelerators in embedded environments, bridging the gap between theoretical security and practical implementation for post-quantum cryptographic systems.

## REFERENCES

[1] M. Pursche, N. Puch, S. N. Peters, and M. P. Heinl, “SoK: The engineer’s guide to post-quantum cryptography for embedded devices,” *Cryptol. ePrint Arch.*, vol. 2024, p. 1345, 2024.

[2] FIPS 203: Module-lattice-based Key-encapsulation Mechanism Standard, National Institute of Standards and Technology, Gaithersburg, MD, USA, 2024.

[3] A. Dolmeta, M. Mirigaldi, M. Martina, and G. Masera, “Implementation and integration of KECCAK accelerator on RISC-V for CRYSTALS-kyber,” in *Proc. 20th ACM Int. Conf. Comput. Frontiers*, May 2023, pp. 381–382.

[4] D. S. Crescenzo, R. C. Rodriguez, R. Alidori, F. Bruguier, E. Valea, P. Benoit, and A. Bosio, “Hardware accelerator for FIPS 202 hash functions in post-quantum ready SoCs,” in *Proc. IEEE 30th Int. Symp. On-Line Test. Robust Syst. Design (IOLTS)*, Jul. 2024, pp. 1–6.

[5] M. J. Dworkin, “SHA-3 standard: Permutation-based hash and extendable-output functions,” NIST, Tech. Rep., Jul. 2015.

[6] T. Fritzmann, M. Van Beirendonck, D. Basu Roy, P. Karl, T. Schamberger, I. Verbauwhede, and G. Sigl, “Masked accelerators and instruction set extensions for post-quantum cryptography,” *IACR Trans. Cryptograph. Hardw. Embedded Syst.*, vol. 2021, pp. 414–460, Nov. 2021.

[7] H. Gross, S. Mangard, and T. Korak, “Domain-oriented masking: Compact masked hardware implementations with arbitrary protection order,” in *Proc. ACM Workshop Theory Implement. Secur.*, Oct. 2016, pp. 1–3.

[8] S. Zarei, A. Rezaei Shahmirzadi, H. Soleimany, R. Salarifard, and A. Moradi, “Low-latency KECCAK at any arbitrary order,” *IACR Trans. Cryptograph. Hardw. Embedded Syst.*, vol. 2021, pp. 388–411, Aug. 2021.

[9] G. Cassiers, L. Masure, C. Momin, T. Moos, A. Moradi, and F.-X. Standaert, “Randomness generation for secure hardware masking-unrolled trivium to the rescue,” *IACR Commun. Cryptol.*, vol. 1, no. 2, Jul. 2024. [Online]. Available: https://eprint.iacr.org/2023/1134

[10] T. Lev-Ami and M. Sagiv, “TVLA: A system for implementing static analyses,” in *Proc. Int. Static Anal. Symp.*, 2000, pp. 280–301.

[11] G. Bertoni, J. Daemen, M. Peeters, and G. V. Assche. (Jan. 2011). *The KECCAK Reference*. [Online]. Available: https://keccak.team/files/Keccak-reference-3.0.pdf

[12] G. Bertoni, J. Daemen, M. Peeters, and G. V. Assche. (2011). *Cryptographic Sponge Functions*. [Online]. Available: https://keccak.team/files/CSF-0.1.pdf

[13] P. Kocher, J. Jaffe, and B. Jun, “Differential power analysis,” in *Advances in Cryptology—CRYPTO*. Cham, Switzerland: Springer, 1999, pp. 388–397.

[14] S. Mangard, T. Popp, and B. M. Gammel, “Side-channel leakage of masked CMOS gates,” in *Topics in Cryptology—CT-RSA 2005*, vol. 3376, D. Hutchison, T. Kanade, J. Kittler, J. M. Kleinberg, F. Mattern, J. C. Mitchell, M. Naor, O. Nierstrasz, C. Pandu Rangan, B. Steffen, M. Sudan, D. Terzopoulos, D. Tygar, M. Y. Vardi, G. Weikum, and A. Menezes, Eds., Berlin, Germany: Springer, 2005, pp. 351–365.

[15] S. Nikova, C. Rechberger, and V. Rijmen, “Threshold implementations against side-channel attacks and glitches,” in *Information and Communications Security*, P. Ning, S. Qing, and N. Li, Eds., Berlin, Germany: Springer, 2006, pp. 529–545.

[16] G. Bertoni, J. Daemen, M. Peeters, and G. V. Assche, “Building power analysis resistant implementations of KECCAK,” Tech. Rep., 2010, vol. 142.

[17] B. Bilgin, J. Daemen, V. Nikov, S. Nikova, V. Rijmen, and G. V. Assche, “Efficient and first-order DPA resistant implementations of KECCAK,” in *Proc. Smart Card Res. Adv. Appl. Conf.*, 2013, pp. 187–199.

[18] T. Korak and M. Hutter, “Towards evaluating DPA countermeasures for KECCAK on a real ASIC,” Springer, Tech. Rep., pp. 222–236, 2015.

[19] V. Arribas, B. Bilgin, G. Petrides, S. Nikova, and V. Rijmen, “Rhythmic KECCAK: SCA security and low latency in HW,” *IACR Trans. Cryptograph. Hardw. Embedded Syst.*, vol. 2018, p. 1193, Feb. 2018.

[20] A. Purnal, V. Arribas, and L. D. Meyer, “Trade-offs in protecting KECCAK against combined side-channel and fault attacks,” in *Proc. Int. Workshop Constructive Side-Channel Anal. Secure Design*, 2019, pp. 285–302.

[21] A. Rezaei Shahmirzadi and A. Moradi, “Second-order SCA security with almost no fresh randomness,” *IACR Trans. Cryptograph. Hardw. Embedded Syst.*, vol. 2021, pp. 708–755, Jul. 2021.

[22] D. Knichel, P. Sasdrich, and A. Moradi, “Generic hardware private circuits–towards automated generation of composable secure gadgets,” *Cryptol. ePrint Archive*, 2021.

[23] D. Knichel and A. Moradi, “Composable gadgets with reused fresh masks: First-order probing-secure hardware circuits with only 6 fresh masks,” *IACR Trans. Cryptograph. Hardw. Embedded Syst.*, vol. 2022, no. 3, pp. 114–140, 2022.

[24] G. Cassiers, L. Masure, C. Momin, T. Moos, A. Moradi, and F.-X. Standaert, “Randomness generation for secure hardware masking-unrolled trivium to the rescue,” *Cryptol. ePrint Arch.*, 2023.

[25] B. Yang, V. Rožic, M. Grujic, N. Mentens, and I. Verbauwhede, “ES-TRNG: A high-throughput, low-area true random number generator based on edge sampling,” *IACR Trans. Cryptograph. Hardw. Embedded Syst.*, vol. 2018, pp. 267–292, Aug. 2018.
[26] I. Levi, D. Bellizia, and F.-X. Standaert, “Tight-ES-TRNG: Improved construction and robustness analysis,” *Social Netw. Comput. Sci.*, vol. 3, no. 4, p. 321, Jul. 2022.

[27] A. Cherkaoui, V. Fischer, A. Aubert, and L. Fesquet, “A self-timed ring based true random number generator,” in *Proc. IEEE 19th Int. Symp. Asynchronous Circuits Syst.*, May 2013, pp. 99–106.

[28] A. Cherkaoui, V. Fischer, L. Fesquet, and A. Aubert, “A very high speed true random number generator with entropy assessment,” in *Proc. 15th Int. Workshop Cryptograph. Hardw. Embedded Syst.*, Santa Barbara, CA, USA. Cham, Switzerland: Springer, Aug. 2013, pp. 179–196.

[29] C. D. Canniere, “Trivium: A stream cipher construction inspired by block cipher design principles,” in *Proc. Int. Conf. Inf. Secur*. Cham, Switzerland: Springer, 2006, pp. 171–186.

[30] H. Raddum, “Cryptanalytic results on TRIVIUM. eSTREAM, ECRYPT stream cipher project, report 2006/039,” Tech. Rep., 2006.

[31] (2020). *Design Compiler*. [Online]. Available: https://www.synopsys.com/

[32] G. Goodwill, B. Jun, J. Jaffe, and P. Rohatg, “A testing methodology for side-channel resistance validation,” in *Proc. NIST Non-Invasive Attack Test. Workshop*, 2011, pp. 115–136.

[33] T. Schneider and A. Moradi, “Leakage assessment methodology,” *J. Cryptograph. Eng.*, vol. 6, no. 2, pp. 85–99, Feb. 2016.

[34] D. Heinz, M. J. Kannwischer, G. Land, T. Pöppelmann, P. Schwabe, and A. Spenkels, “First-order masked Kyber on ARM cortex-M4,” *Cryptol. ePrint Arch.*, 2022.

[35] T. Kamucheka, A. Nelson, D. Andrews, and M. Huang, “A masked pure-hardware implementation of kyber cryptographic algorithm,” in *Proc. Int. Conf. Field-Programmable Technol. (ICFPT)*, Dec. 2022, p. 1.

[36] A. Jati, N. Gupta, A. Chattopadhyay, and S. K. Sanadhya, “A configurable CRYSTALS-kyber hardware implementation with side-channel protection,” *ACM Trans. Embedded Comput. Syst.*, vol. 23, no. 2, pp. 1–25, Mar. 2024.

<figure><img src="image_13.png" /></figure>

**STEFANO DI MATTEO** received the M.Sc. and Ph.D. degrees in electronic engineering and information engineering from the University of Pisa, in 2019 and 2023, respectively. He is currently a tenure-track Researcher in hardware implementation of post-quantum cryptography with CEA, Grenoble. His research interests include hardware implementation of PQC with countermeasures against physical attacks, RISC-V architectures, and instruction set extensions for PQC.

<figure><img src="image_14.png" /></figure>

**DIAMANTE SIMONE CRESCENZO** received the bachelor's degree in computer science and the master's degree in embedded systems from Politecnico di Torino, in 2021 and 2023, respectively. He is currently pursuing the Ph.D. degree with CEA, LIST, Grenoble, focusing on new approximation strategies for post-quantum cryptography (PQC). His research interests include hardware implementation of cryptographic algorithms, approximation techniques for PQC, and design optimization for secure embedded systems.

<figure><img src="image_15.png" /></figure>

**RAFAEL CARRERA RODRIGUEZ** received the bachelor's degree in electronic engineering from Universidad del Norte, Colombia, in 2019, the master's degree in embedded systems and cybersecurity from Grenoble INP-Ensimag, France, in 2021, and the Ph.D. degree from the University of Montpellier, France, in 2025. He is currently a Hardware Security Analyst with eShard, Pessac, France. His research interests include secure embedded implementations of post-quantum cryptography from both the attacks and countermeasures standpoints.

<figure><img src="image_16.png" /></figure>

**EMANUELE VALEA** received the master's degree in electronic engineering from Politecnico di Torino, Italy, in 2016, and the Ph.D. degree in microelectronics from the University of Montpellier, France, in 2020. He is currently a Researcher with CEA, LIST, Grenoble, France. His research interests include hardware security and trust, cryptographic primitives for microelectronics, and security-related aspects of VLSI testing and reliability.

<figure><img src="image_17.png" /></figure>

**FLORENT BRUGUIER** (Member, IEEE) received the M.S. and Ph.D. degrees in microelectronics from the University of Montpellier, France, in 2009 and 2012, respectively. In 2015, he joined the ADAC Team as an Associate Professor. Since 2016, he has been in charge of the SECNUM Platform, a platform dedicated to the side-channel attacks. His research interests include self-adaptive and secured approaches for embedded and high-performance systems and cryptographic systems, including PQC implementation and their susceptibility to side-channel attacks.

<figure><img src="image_18.png" /></figure>

**PASCAL BENOIT** received the Ph.D. degree in microelectronics, in 2004, and the Habilitation degree from Montpellier Laboratory of Informatics, Robotics, and Microelectronics (LIRMM), in 2015. He is currently a Professor with the University of Montpellier. Then, he completed Postdoctoral Research with Karlsruhe Institute of Technology, Germany, further developing his expertise, before returning to France to advance his career. Specifically, he works on the architecture of embedded electronic systems with the interface of software and hardware. He has co-authored over 150 scientific publications. His research interests include the development of edge computing, aiming to optimize storage and computation across networks to enhance energy efficiency, and security.

...