Low-Latency Masked Gadgets Robust against Physical Defaults with Application to Ascon

IACR Transactions on Cryptographic Hardware and Embedded Systems ISSN 2569-2925, Vol. 2024, No. 3, pp. 603–633. DOI:10.46586/tches.v2024.i3.603-633 Low-Latency Masked Gadgets Robust against Physical Defaults with Application to Ascon Gaëtan Cassiers1†, François-Xavier Standaert1and Corentin Verhamme1 1Crypto Group, ICTEAM, UCLouvain, Louvain-la-Neuve, Belgium. Abstract. Low-latency masked hardware implementations are known to be a difficult challenge. On the one hand, the propagation of glitches can falsify their independence assumption (that is required for security) and can only be stopped by registers. This implies that glitch-robust masked AND gates (maintaining a constant number of shares) require at least one cycle. On the other hand, Knichel and Moradi’s only known single-cycle multiplication gadget that ensures (composable) security against glitches for any number of shares requires additional care to maintain security against transition-based leakages. For example, it cannot be integrated in a single-cycle roundbased architecture which is a natural choice for low-latency implementations. In this paper, we therefore describe the first single-cycle masked multiplication gadget that is trivially composable and provides security against transitions and glitches, and prove its security in the robust probing model. We then analyze the interest of this new gadget for the secure implementation of the future lightweight cryptography standard Ascon, which has good potential for low-latency. We show that it directly leads to improvements for uniformly protected implementations (where all computations are masked). We also show that it is can be handy for integration in so-called leveled implementations (where only the key derivation and the tag generation are masked, which provides integrity with leakage in encryption and decryption and confidentiality with leakage in encryption only). Most importantly, we show that it is very attractive for implementations that we denote as multi-target, which can alternate between uniformly protected and leveled implementations, without latency overheads and at limited cost. We complete these findings by evaluating different protected implementations of Ascon, clarifying its hardware design space. Keywords: Lightweight Authenticated Encryption · Masking · Probing Security · Glitches ·Transitions ·Leakage-Resistance ·Leveled Implementations 1 Introduction The National Institute of Standards and Technology (NIST) recently selected Ascon as a new standard for lightweight cryptography [ DEMS21 ]. 1 Ascon is aimed at efficient and low-cost implementations, but is also anticipated to be easier to protect against side-channel analysis than authenticated encryption based on the AES Rijndael, thanks to two relevant features. First, its 5-bit S-box has a simple bit-level representation that only takes five AND gates with an AND-depth of one, which is especially suitable for masking [ BMD+20 ]. As a result, efficient masked implementations have been the focus of a sequence of works, exploiting either Threshold Implementations (TIs) with low security order [ GWDE15 , GWDE17 , KBG+23 ] or generic solutions with arbitrary security order [ GM17 , GIB18 , VCS22 ]. Second, its mode of operation enables so-called leveled †Work performed in parts during a post-doctoral stay at IAIK, TU Graz, Graz, Austria. 1https://csrc.nist.gov/Projects/lightweight-cryptography Licensed under Creative Commons License CC-BY 4.0. Received: 2024-01-15 Accepted: 2024-03-15 Published: 2024-07-18 604 Low-Latency Masked Gadgets with Application to Ascon implementations, where different parts of the implementations have different security requirements and can therefore be protected with different (more or less expensive) countermeasures [ GPPS20 , BBC+20 , VCS22 ]. More precisely, this second sequence of works shows that a leveled implementation of Ascon can reach the highest possible integrity with leakage, coined Ciphertext Intergrity with Misuse and Leakage in encryption and decryption (CIML2), and confidentiality against Chosen Ciphertext Attacks with misuseresilience in case Leakage can only be observed in encryption (CCAmL1). Concretely, such an implementation combines a masked implementation of the Ascon permutation for key derivation and tag generation, and an unprotected (parallel) one for the message processing. By contrast, if confidentiality with leakage in decryption is needed, the only solution is to step back to a (more expensive) uniformly protected implementation. These good features of Ascon, and especially its low AND-depth, are naturally appealing for low-latency implementations. Yet, it is well-known that hardware implementations of cryptographic algorithms combining low latency and side-channel security are difficult to design. This is because such implementations have to resist against physical defaults like glitches [ MPG05 , MPO05 ], and established methodologies to prevent the propagation of glitches require register stages [ NRS11 , FGP+18 ]. Briefly summarized, most of the known gadgets that provide higher-order composable security require two cycles per AND gate [ CGLS21 ]; first attempts to design low-latency gadgets were limited to low number of shares [ ABP+17 , MMM21 , KSM22 , BDMS22 ]; and the generalizations to arbitrary numbers of shares proposed in [ GIB18 ] and [ ZSS+21 ] were shown to suffer from security flaws [ MMSS19 ] or to leak at reduced security orders when transition-based leakages can be observed [ MM22 ], respectively. As a result, and to the best of our knowledge, the only published masked gadgets combining resistance against glitches and low latency are the lowlatency Hardware Private Circuits (HPC3) of Knichel and Moradi [ KM22 ]. Formally, these gadgets are Probe-Isolating Non-Interferent (PINI) [ CS20 ] in the glitch-robust probing model [ FGP+18 ]. It was shown in [ CS21 ] that they ensure composable security against transitions and glitches as long as transitions only occur between parallel evaluations of a gadget. This concretely means that in round-based implementations, there must be a bubble in the pipeline between the execution of consecutive rounds. Unfortunately, when aiming for a low-latency implementation of Ascon with a single-cycle round-based architecture, this condition prevents from using PINI gadgets such as HPC3.2 Based on this state-of-the-art, our contributions are twofold. On the one hand, we design and prove the first low-latency masked hardware gadgets that offer unconditional composable security against transitions and glitches, which we denote as HPC4. Formally, these gadgets ensure the Output-Probe-Isolating Non-Interference (O-PINI) security notion [ CS21 ], which guarantees that they can be trivially composed, even in the case of single-cycle per round implementations. The only known O-PINI gadgets have a latency of (at least) two cycles [ CS21 , KM22 ]. The HPC4 gadgets have a latency of a single cycle. We argue that they are directly useful for uniformly protected implementations of Ascon with CCAmL2 security, since they halve their latency. On the other hand, we investigate the interest of such low-latency gadgets at a higher architectural level. So far, the literature has shown that compared to uniformly protected implementations, leveled implementations of Ascon can bring significant performance (e.g., latency, energy) gains at limited area cost if only CIML2 and CCAmL1 security have to be guaranteed [ VCS22 ]. But if one additionally requires CCAmL2 security (i.e., confidentiality with leakage in decryption), Ascon implementations must be protected uniformly. This naturally leads to the question whether a single implementation could provide both at limited cost, thanks to resource sharing. We show that such multi-target designs can 2By this, we mean an architecture that performs a single round of the Ascon permutation per cycle. Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1605 highly benefit from HPC4 gadgets, which can come in two flavors. In a fully shared design, the same (masked) Ascon permutation is re-used for both CCAmL1and CCAmL2-secure implementations of the mode, and the masking’s randomness generation is frozen during the message processing in case only CCAmL1 is required. In a partially shared design, we still add an unprotected parallel (possibly unrolled) permutation to the architecture for the CCAmL1 part. These investigations lead us to simplify the design space of masked hardware implementations of Ascon providing composable security against both transitions and glitches for arbitrary number of shares, as depicted in Figure 1. security target(s) security requirements resource sharing prefered gadgets CIML2 + CCAmL2 (single-target) uniform X HPC2 for cost HPC4 for latency CIML2 + CCAmL1 (single-target) leveled X HPC2 for long messages (HPC3 intermediate sizes) HPC4 for short messages CIML2 + CCAmL1 or CIML2 + CCAmL2 (multi-target) uniform or leveled full HPC4 latency fixed flexible (with unrolling) fixed CIML2 + CCAmL1 or CIML2 + CCAmL2 (multi-target) uniform or leveled partial HPC2 for cost HPC4 for latency flexible (with unrolling) Figure 1: Masked hardware implementations of Ascon: design space of architectures with composable security against transitions & glitches for arbitrary number of shares. In summary, if targeting CIML2 and CCAmL2 security with a uniformly protected implementation, the HPC2 gadgets are preferable for cost and HPC4 ones are preferable for latency. If targeting CIML2 and CCAmL1 security with a leveled implementation, the HPC2 gadgets are preferable for long messages (i.e., when the latency of Ascon’s masked key derivation and tag generation is amortized) and the HPC4 gadgets are preferable for short messages (i.e., when such an amortization does not take place). These leveled implementations offer a flexible latency, because their message processing is performed by an unprotected parallel implementations of the Ascon permutation, for which it is possible to adapt the level of unrolling. Eventually, in case a multi-target design (that can either guarantee CIML2+CCAmL1 or CIML2+CCAmL2) is desired, the HPC4 gadget is the best solution. This is because its low latency makes it the best option for resource sharing. In the fully shared case, the key derivation, tag generation and message processing can then be performed using the same masked architecture, with limited latency penalty (i.e., one cycle per round, only loosing the flexibility that the single-target leveled implementation enables thanks to unrolling) and energy gains for the CIML2+CCAmL1 mode, for which the masking’s randomness generation can be frozen during the message processing part. In the partially shared version, flexible latency is restored by using an additional unprotected parallel (possibly unrolled) implementation of the Ascon permutation and the choice of gadgets follows the same tradeoff as in the single-target uniformly protected case. We further observe that the HPC3 gadgets in [ KM22 ] provide a combination between local low-latency features and a need to be integrated in an implementation with more than one cycle per round (with a pipeline bubble) to maintain their security guarantees. As such, they stand between the single-cycle HPC4-based implementations and the area/randomnessefficient (but slower) HPC2-based ones. They are therefore most relevant when the masked permutation does not have to achieve very low latency, but should not have a too high latency either. This may for example happen in the case where a single-target leveled 606 Low-Latency Masked Gadgets with Application to Ascon implementation is used for encrypting messages of intermediate length. Given the relatively narrow nature of this sweet spot, we leave it as a scope for further investigations. We also note that the table excludes optimizations that specifically target low number of shares (in which case performance improvements are possible – see the aforementioned references). We finally mention the related works [ SBHM20 , NGPM22 , SBB+23 , SBB+22 ] which propose alternative methodologies for low-latency masked implementation by leveraging different technologies (e.g., asynchronous or and/or dual-rail logic syles) and stronger physical assumptions, recently discussed (and in part falsified) in [ LMM23 ]. As such, they are hardly comparable with the standard CMOS-based solutions we propose. We additionally discuss other possible applications of HPC4 gadgets in Section 7. 2 Background This section adopts a top-down approach by showcasing how modes of operation can contribute to side-channel security and describing masking as a primitive-level countermeasure. We use this structure in order to provide a global picture on the security requirements that cryptographic designs put on implementers, and on how to ensure these requirements in practice, while also motivating the design of low-latency masked gagdets. 2.1 Mode-level security against leakage Authenticated Encryption (AE) aims at ensuring both message integrity and confidentiality. This can be formalized both with an “all-in-one” definition as proposed by Rogaway and Shrimpton [ RS06 ] or with the composite definitional framework of Guo et al. [ GPPS19 ]. We use the second option which allows leveraging the fact that integrity with leakage and confidentiality with leakage impose quite different security requirements, which is the basis of leveled implementations [BBC+20]. It relies on the following notions: Definition 1 (Ciphertext Integrity with Leakage (informal)) . In the Ciphertext Integrity with Leakage (CIL) security game, the adversary can perform a number of queries to encryption and decryption oracles enhanced with leakage functions, that capture the implementation of an AE scheme. Her goal is to produce a valid fresh ciphertext. The implementation is secure if the adversary can only succeed with negligible probability. Definition 2 (Confidentiality with leakage (informal)) . In the Chosen Ciphertext Attack with Leakage (CCAL) security game, the adversary can perform a number of queries to encryption and decryption oracles enhanced with leakage functions, that capture the implementation of an AE scheme. During a so-called “challenge query”, she picks up two fresh messages X0 and X1 and receives a ciphertext Yb encrypting Xb for b∈0,1 , with the corresponding leakage. Her goal is to guess the bit b . The implementation is secure if the adversary can only succeed with negligible advantage over a random guess. These two games can be played in different variants, corresponding to more or less powerful adversaries. A first axis of variants specifies whether leakage can be observed in encryption only (which is reflected by a “1” in the notations) or in encryption and decryption (which is reflected by a “2” in the notations). For example, CIL1 and CCAL1 stand for integrity and confidentiality with leakage in encryption only, CIL2 and CCAL2 stand for their counterpart with additional leakage in decryption. Another axis of variants specifies whether the implementation is assumed to be nonce-respecting or if some kind of nonce control is allowed. We consider the possibility of nonce misuse-resistance [ RS06 ] (which is reflected by a capital M in the notations) when targeting integrity with leakage, and the possibility of nonce misuse-resilience [ ADL17 ] (which is reflected by a small m in the notations) when targeting confidentiality with leakage. In the first case, the nonce Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1607 can be misused even in the challenge query. In the second case, misuse is excluded for the challenge query, which aims to ensure that although confidentiality may be lost when the nonce is under adversarial control, it is restored as soon as fresh nonces are used. For example, CIML1 and CIML2 stand for integrity with misuse-resistance and leakage, CCAmL1 and CCAmL2 stand for confidentiality with misuse-resilience and leakage.3 Thanks to this definitional framework, it is possible to analyze the security of a mode of operation with leakage under different physical assumptions for its different parts, in turn leading to leveled implementations. Ascon’s leveling opportunities have been formally investigated in [ GPPS20 ] and are summarized in Figure 2. Informally, CIML2 security only requires to protect the key derivation and tag generation against Differential Power Analysis (DPA), leaving the message processing part unprotected; CCAmL1 security additionally requires that the message processing part is protected against Simple Power Analysis (SPA); CCAmL2 security finally requires a uniform protection against DPA. By DPA (resp., SPA), we mean side-channel attacks where the adversary can observe the encryption of many plaintexts (resp., a few plaintexts) with the same key. We can already observe that taking advantage of Ascon’s leveling opportunities requires knowing the security target (e.g., for confidentiality) in advance. This raises the question whether an implementation with a security target selected at execution time can be built more efficiently than with the naive solution where multiple designs are just implemented independently. 2.2 Masking as primitive-level countermeasure Figure 2shows the different security targets that can be ensured by Ascon, with the security requirements they imply for the implementation of its permutation. In our hardware implementation context, security against SPA can be obtained quite efficiently, by just using an architecture with a sufficient level of parallelism [ USS+20 , BMPS21 ]. As a result, the main challenge to implement Ascon securely lies in the permutations that must resist against DPA. For this purpose, the standard approach in the literature is to rely on masking [ CJRR99 ]. We next provide the background necessary to introduce our new low-latency gadgets that provide composable security against transitions and glitches. From now on, we denote a random variable by lowercase letter : x∈F2 denotes a binary random variable. In the particular case of masking we will denote by xi the i -th share of the x variable such that L∀ixi = x, i ∈ { 0 , . . . , d− 1 } where d denotes the number of shares. Besides, drawing a value uniformly at random from a set is denoted as x$ ←− S. 2.2.1 Circuit definition The circuit model we use comes from [ CS21 ]. We keep its formalism but restrain some of the notions to fit our needs that are limited to a single-cycle pipelined gadgets. This model first designates physical circuits as sets of gates and wires: Definition 3 (Structural gate).A structural gate is a tuple (I, P, f, lat), where •Iis the set of inputs of the gate, •Pis the set of parameters and the union of public and private parameters PP,PS, •f: (I→Fq)×(P→S)→Fq(where Sis any set) is the evaluation function, •lat : I→N is the latency of the inputs (i.e., one if the input is required one clock cycle before the output is produced, zero if it is required at the same cycle). 3 As discussed in [ GPPS19 ], this restriction is needed because confidentiality with leakage and nonce misuse-resistance can only be obtained with unrealistic (leak-free) requirements for the implementers. 608 Low-Latency Masked Gadgets with Application to Ascon N K 128 128 pa ⊕ K 256 ⊕ 64 M1C1 pb 256 ⊕ Mm−1Cm−1 pb ⊕ Mm Cm 64 ⊕ K 256 pa ⊕ K 128 T (a) CIML2-secure implementation. N K 64 256 pa ⊕ K 256 ⊕ 64 M1C1 pb 256 ⊕ Mm−1Cm−1 pb ⊕ Mm Cm 64 ⊕ K 256 pa ⊕ K 128 T (b) CCAmL1-secure implementation. N K 64 256 pa ⊕ K 256 ⊕ 64 M1C1 pb 256 ⊕ Mm−1Cm−1 pb ⊕ Mm Cm 64 ⊕ K 256 pa ⊕ K 128 T (c) CCAmL2-secure implementation. Figure 2: Leveled implementation of Ascon for different security targets. The blue blocks have to be protected against DPA, the green ones have to be protected against SPA and the white ones do not require protection against side-channel leakage. Definition 4 (Structural wire) . A structural wire is a pair ( g, ( g0, i )) which connects a (source) gate gto the input iof a (destination) gate g0, denoted as (g0, i). Merging these two notions, one can define structural circuits : Definition 5 (Structural circuit) . A structural circuit is a directed graph whose nodes are structural gates and whose edges are structural wires. A wire connects its source to its destination. In a structural circuit, there must be no combinational loop (i.e., there must be no cycle for which all the wires have a destination with latency 0). We then need to define the execution of a structural circuit: Definition 6 (Circuit execution) . The execution of a structural circuit C = ( G, W )for the set of cycles T = {t0, . . . , tL−1} is a directed graph whose set of nodes is G×T (the gates) and whose set of edges is W×T (the wires). Wires connect gates according to their latency: let w = ( g, ( g0, i )) be a structural wire and ( g0, t )a gate, the wire ( w, t )connects its source ( g, t −latg0 ( i )) to its destination ( g0, t ), where latg0 is the latency function of the gate g0 . If the source does not exist, then the wire is connected to a fresh “initial state” source gate (i.e., a no-input gate having as output a public parameter). Each gate may be annotated with a parametrization function, mapping the set of all (resp., public) parameters of the underlying structural gate to values, in which case the execution is full (resp., partial). Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1609 Now that objects are formally defined, we next introduce a security notion over them. 2.2.2 Probing model and robust probing model We will use the following two definitions in our contributions. Definition 7 (Probing security [ ISW03 ]) . A set of probes P in a gadget execution G is a subset of its gates and input wires. In an evaluation of G with input values x , the values of the probes are denoted as GP ( x ). The sensitive values are defined as the sums of the values on the wires of each input sharing. A gadget execution G is secure against a set of probes P if GP ( x )is independent of the sensitive values when the inputs x are uniformly distributed. Gis t-probing secure if it is secure against any Psuch that |P| ≤ t. A more generic model exists that models physical defaults thanks to extended probes: Definition 8 (Robust probing security [ FGP+18 ]) . A probe expansion scheme is a function that maps a gadget execution to a larger set of extended probes, which are sets of probes in the gadget execution. The probes in those sets are named expanded probes. A gadget execution is t -robust probing secure with respect to a probe expansion scheme if it is secure against all the expanded probes from any set of textended probes. In this work, we will be interested in glitchand transition-extended probes. Informally, glitch-extended probes turn any probe on combinatorial wire into all its (registered) inputs (for registered input wires, there is no extension); and transition-extended probes turn any probe on a register into a pair of values that correspond to consecutive invocations. When combining both, the set of extended probes is obtained by first computing the set transition-extended probes and then replacing every expanded probe in a transitionextended probe with all the expanded probes contained in the glitch-extended probe that correspond to it. Physically, this models the fact that the propagation of a glitch (e.g., its timing) depends on both the new and the previous values on the wire. 2.2.3 Circuit composition Proving the robustness to probing becomes computationally hard when the size of the circuit to verify and the number of shares increase [ BBD+15 , BGI+18 , BBC+19 , KSM20 ]. A standard approach to enable the more efficient verification of complex circuits is to require the gadgets to ensure some (stronger) composability properties [BBD+16]. We first introduce the simulatability framework that we will use in our results: Definition 9 (Simulatability [ BBP+16 ]) . A set of probes P in a gadget execution G can be simulated by a set of input shares I = (i1, j1),...,(ik, jk) if there exists a randomized simulator algorithm S such that the distributions GP ( x∗,∗ )(the values of the probes) and S(xi1,j1, . . . , xik,jk)are equal for any value of the inputs x∗,∗. Definition 10 (Glitch+Transition robust Simulatability [ CS21 ]) . A set of extended probes P in a gadget execution G can be simulated by a set of input shares I = (i1, j1),...,(ik, jk) if there exists a randomized simulator algorithm S such that the distributions GP ( x∗,∗ ) and S(xi1,j1, . . . , xik,jk)are equal for any value of the inputs x∗,∗. Next, the PINI property is used to capture trivial composition: Definition 11 (Probe-Isolating Non-Interference [ CS20 ]) . Given a gadget execution G , let I be a set of at most t1 probes on its internal wires and O a set of probes on its output shares. Let A be the set of the share indexes of the shares in O , and t2 = |A| . Let I and O be chosen such that t1 + t2≤t . The gadget G is t -PINI iff for all I and O there exists a set of at most t1share indexes Bsuch that observations corresponding to Iand Ocan be simulated using only the shares with indexes A∪Bof each input sharing. 610 Low-Latency Masked Gadgets with Application to Ascon Algorithm 1 HPC2 AND gadget with dshares. Require: Sharings x,y Ensure: Sharing zsuch that z=x·y. 1: for i= 0 to d−1do 2: for j=i+ 1 to d−1do 3: rij =rji $ ←F2 4: end for 5: end for 6: for i= 0 to d−1do 7: for j= 0 to d−1, j 6=ido 8: uij ←(xi⊕1) ⊗Reg [rij] 9: vij ←yj⊕rij 10: end for 11: end for 12: for i= 0 to d−1do 13: zi←Reg [xi⊗Reg [yi]] ⊕Ld−1 j=0,j6=i(Reg [uij ]⊕Reg [xi⊗Reg [vij]]) 14: end for Eventually, the O-PINI property is used to capture trivial composition with glitches and transitions. It can be viewed as a strengthening of PINI, where the simulator must simulate the outputs with same share index as the one on which an input share index is probed: Definition 12 (Output Probe-Isolating Non-Interference [ CS21 ]) . Given a gadget execution G , let I be a set of at most t1 probes on its internal wires and O a set of probes on its output shares. Let A be the set of the share indexes of the shares in O , and t2 = |A| . Let I and O be chosen such that t1 + t2≤t . The gadget G is t -O-PINI iff for all I and O there exists a set of at most t1 share indexes B such that observations corresponding to I , O and output shares with index in B can be simulated using only the shares with indexes A∪Bof each input sharing. We say a gadget is O-PINI if it is t-O-PINI for any t. It has been proven in that such gadgets can be trivially composed: Theorem 1 (Trivial composition of O-PINI gadgets [ CS21 ]) . Let Si be a set of pipeline t -O-PINI structural gadgets, and let Gi be their executions. If the structural gadget S is a composition of Sigadgets, then it is t-O-PINI. 2.2.4 Hardware Private Circuits Hardware Private Circuits are adaptations of Ishai et al.’s seminal private circuits [ ISW03 ], adapted in order to better cope with physical defaults that are typical from hardware implementations. This generally comes at the cost of stronger contraints on their latency (since registers are instrumental to avoid the propagation of glitches) and larger randomness requirements. We next describe the two main gadgets that will drive our discussions (while there exists other HPC gadgets, they are not relevant for our use-case). First, the HPC2 gadget introduced in [ CGLS21 ] is described in Algorithm 1. It achieves trivial composition against glitches in two clock cycles (with respect to one of its inputs, and only one cycle with respect to the other one) and requires d(d−1) 2 fresh random bits per evaluation (with d shares). Since HPC2 is glitch-robust PINI but not glitch-robust O-PINI, it is not trivially composable in presence of transitions, although a more restricted form of composition is possible, which may come with added latency [CS21]. Second, the HPC3 multiplication gadget introduced in [ KM22 ] is described in Algorithm 2. It achieves trivial composition against glitches in one clock cycle and requires Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1611 Algorithm 2 HPC3 AND gadget with dshares. Require: Sharings x,y Ensure: Sharing zsuch that z=x·y. 1: for i= 0 to d−1do 2: for j=i+ 1 to d−1do 3: rij =rji $ ←F2 4: r0 ij =r0 ji $ ←F2 5: end for 6: end for 7: for i= 0 to d−1do 8: for j= 0 to d−1, j 6=ido 9: uij ←Reg [yj⊕rij] 10: vij ←Reg (xi⊕1) ⊗rij ⊕r0 ij 11: wij ←Reg [xi]⊗uij ⊕vij 12: end for 13: end for 14: for i= 0 to d−1do 15: zi←Reg [xi⊗yi]⊕Ld−1 j=0,j6=i(wij ) 16: end for d ( d− 1) fresh random bits per evaluation. Similarly to HPC2, HPC3 is PINI but not O-PINI, with the same impact on composability with transition-based leakages. Let us remark that HPC2 and HPC3 have O-PINI variants (O-PINI1/2 and HPC3+ respectively), which cost one additional clock cycle of latency and d− 1additional random bits. Hence, no existing solution allows single-cycle round-based implementations. 3 The HPC4 gadget In this section, we introduce the new single-cycle HPC4 AND gadget, prove that it is glitch-robust O-PINI and discuss its performance figures compared to HPC2 and HPC3. Let us first recall why the HPC2 and HPC3 gadgets are not O-PINI, which will give some motivation for the design choices of HPC4. For HPC2, and looking at Algorithm 1, a probe on uij = ( xi⊕ 1) ⊗rij requires knowledge of xi and rij to be simulated. 4 Therefore, following the O-PINI definition, zi should be simulated which, due to glitches, means that the value xi⊗ ( yj⊕rij )should be simulated. This in turn means that yj⊕rij must be known to the simulator, which, combined with the simulation of rij means that yj must be known as well. This contradicts the definition of O-PINI: it should be possible to simulate one probe using only one input share. For HPC3, the issue is similar: if there is a probe in the computation of vij , then xi , rij and r0 ij are observed. Therefore, zi must be simulated. With glitches, it leads to the same requirement on the simulation of yj⊕rij. From these examples, we can see that the core issue comes from (i) yj being masked by a single random value, which (ii) appears in a computation with xi , and that (iii) glitches on the output shares zi leak a lot of information about the intermediate computations in the gadget. We may try to fix the issue by removing any of these conditions. Eliminating (iii) is the approach of existing O-PINI gadgets: they essentially refresh the shares zi , but this has a latency cost. We therefore look at the other solutions: eliminating (ii) appears difficult while preserving the correctness of the gagdet. By contrast, for (i), we mask yj 4When discussing the values of wires, registers are irrelevant and therefore omitted for readability. 618 Low-Latency Masked Gadgets with Application to Ascon Uniform(HPC2-ser) Leveled(HPC2-ser, r.b.) Leveled(HPC2-ser, unr-2) Leveled(HPC2-ser, unr-3) Uniform(HPC4-r.b.) Leveled(HPC4-r.b., r.b.) Leveled(HPC4-r.b., unr-2) Leveled(HPC4-r.b., unr-3) Uniform(HPC2-ser) Leveled(HPC2-ser, r.b.) Leveled(HPC2-ser, unr-2) Leveled(HPC2-ser, unr-3) Uniform(HPC4-r.b.) Leveled(HPC4-r.b., r.b.) Leveled(HPC4-r.b., unr-2) Leveled(HPC4-r.b., unr-3) Uniform(HPC2-ser) Leveled(HPC2-ser, r.b.) Leveled(HPC2-ser, unr-2) Leveled(HPC2-ser, unr-3) Uniform(HPC4-r.b.) Leveled(HPC4-r.b., r.b.) Leveled(HPC4-r.b., unr-2) Leveled(HPC4-r.b., unr-3) 0 50 100 150 200 Area [kGE] Mode DPA SPA d= 2 d= 3 d= 4 Figure 6: Single-target implementations: area comparisons. comparisons are depicted in Figure 6. For completeness, we additionally report the exact gate counts (in kilo-gate equivalent) in Appendix A,Table 6. As for the latencies of the modes, they are depicted on Figure 7 and we also provide the explicit equations. First, when using a uniformly protected implementation, we have: Lu(m) = 24c+m+ 1 64 ∗6c, (2) which gives the latency of the mode of operation when encrypting an m -bit message, where c = 6 cycles if using HPC2-ser gadgets and c = 1 cycle if using HPC4-r.b. gadgets. Next, when using a leveled implementation, we have: Ll(m) = 24 ∗c+m+ 1 64 ∗6 u,(3) where u is the number of rounds computed in one clock cycle for the unprotected implementation used in the message processing part of the mode. Similarly to the uniform case, c = 6 cycles (resp., c = 1 cycle) when using HPC2-ser (resp., HPC4-r.b.) gadgets for the key derivation and tag generation parts of the authenticated encryption mode. Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1619 0 50 100 150 200 250 300 350 400 450 500 50 100 150 200 250 300 350 400 Message size [byte] Encryption latency [cycle] Uniform(HPC2-ser) Leveled(HPC2-ser, r.b.) Leveled(HPC2-ser, unr-2) Leveled(HPC2-ser, unr-3) Unif.(HPC4-r.b.) - Lev.(HPC4-r.b., r.b.) Leveled(HPC4-r.b., unr-2) Leveled(HPC4-r.b., unr-3) Figure 7: Single-target implementations: latency comparisons. These evaluations confirm the intuitive recommendations outlined in introduction (Figure 1). In the uniformly protected implementation case, HPC2 is less expensive than HPC4 but implies significant latency overheads. In the leveled case, unrolling the unprotected implementation provides significant latency gains while the choice between HPC2 and HPC4 provides a cost vs. latency tradeoff. Overall, leveling comes at limited area cost and is therefore relevant in case only CCAmL1 security is needed. Comparison with state of the art implementations. The work in [ GIB18 ] reports an area of 42.75 kGE and consumes 2048 bits of randomness per cycle for a uniformly protected implementation. Our uniformly protected implementation with HPC4 requires and area of 46.66 kGE and consumes 1600 bits of randomness per cycle. In term of latency, they both achieve one round per cycle (see the continuous blue line on Figure 7). We therefore achieve similar performances while provably avoiding the flaws put forward in [ MMSS19 ]. The work in [ VCS22 ] proposes a leveled implementation where the key derivation and tag generation function are instantiated with 80-bit serialized implementations using HPC2 gadgets, while the message is processed by a round-based unprotected implementation. Their reported area is 43 kGE while we achieve 31.5 kGE for a similar architecture using similar latencies (see the dashed red line on Figure 7). We additionally offer the possibility to unrol the unprotected implementation. These comparisons are summarized in Table 4. 5 Multi-target implementations In this section, we move the the integration of the HPC4 (and other relevant) gadget(s) into the multi-target implementations reported in the lower part of Figure 1. These implementations provide a run-time selection between two modes: either CIML2 and CCAmL2 security with uniform protection or CIML2 and CCAmL1 security with leveled protection. 620 Low-Latency Masked Gadgets with Application to Ascon Table 4: Comparison between the state of the art and our proposed solutions. Reference Architectures Area (kGE) Latency (cycle for specified blocks) 1 4 10 [VCS22](HPC2-ser, r.b.) 43 150 168 204 This 31.5 150 168 204 [GIB18] GLM 42.75 30 48 84 This HPC4-r.b. 46.66 30 48 84 ⊕ K0 0 T ⊕p M CT {IV, 0, N} ⊕ M CT p Figure 8: Multi-target implementation with partial resource sharing. We propose two such implementations. The first one, described Section 5.1, instantiates one masked permutation (used for both modes) and a non-protected permutation which enables high throughput in the leveled mode. The other one, described in Section 5.2, instantiates a single masked permutation unit that can operate in a non-protected way, by clock gating most of its state, thereby saving energy in the CIML2+CCAmL1 mode. We finally evaluate performances for such implementations in Section 5.3. 5.1 Partial resource sharing with unrolling We first design a multi-target implementation with an architecture similar to the leveled implementation of Section 4.3. It is represented in Figure 8and mixes the two target security levels of the previous section with both a masked and an unprotected permutation. This implementation requires additional resources due to the control logic needed to interconnect the primitives. Its main advantage is to maintain the possibility to unroll the unprotected permutation, in order to improve the latency. The masked permutation also offers some flexibility, since it can be instantiated with HPC2 or HPC4 gadgets. 5.2 Full resource sharing without unrolling We next push the resource sharing the previous implementation even further, by exploiting specific properties of the HPC4 gagdet. The main idea of this last architecture is to reuse the same (low-latency) masked permutation for both the DPA-protected and SPA-protected parts of the implementation, in order to reduce the area requirements while keeping the energy gains of a leveled implementation when only CCAmL1 is required for confidentiality Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1621 ⊕ K0 0 T ⊕p M CT {IV, 0, N} Figure 9: Multi-target implementation with full resource sharing. with leakage (since the making’s randomness can then be frozen during the message processing). This optimization comes at the cost of being limited to a single-cycle round architecture in this case as well (hence removing the possibility to unroll the unprotected permutation as in the partial sharing case). Such a design is depicted in Figure 9. Concretely, this last design computes the SPA-protected permutation using the DPAprotected one by clock gating d− 1bits of each sharing and keeping the last bit running with the value on which to aim to compute. This is directly achievable for affine operations (i.e., it only require to coherently use the selected index), but requires a slight modification of HPC4 to perform the AND gate. Indeed, since the masked gadet mixes different shares, it is not possible to just ignore the other shares. To solve this issue, d− 1output shares of the HPC4 gadget are set to 0, while the last share forwards the already existing AND gate performed over xiyi. This modified AND gate design is represented on Figure 10. 5.3 Performance evaluation We implemented different multi-target Ascon architectures in the NanGate 45 Open Cell Library, for designs synthetized using the Cadence Design Vision toolchain. Area comparisons are depicted in Figure 11. For completeness, we additionally report the exact gate counts (in kilo-gate equivalent) in Appendix A,Table 7. Latencies are the same as in Equation 2 and Equation 3. It should however be noted that the shared implementation cannot be unrolled and its latency is calculated by considering only u= 1. The area figures essentially suggest that the overheads of a multi-target design (over a single-target one) are limited. For example, the full resource sharing option allows us to reduce the 2-share design area to 58 [kGE]. It additionally offers the possibility to perform an unprotected Ascon operation (e.g., for hashing). However we note that the mild overhead of a partially shared implementation comes with the capacity to unroll the unprotected implementation, leading to significant gains in latency. This table depicts an interesting part of Ascon’s design space. From a cost-performance point of view, two sweetspots clearly emerge, with an expensive but cycle-efficient AsconHPC4 and an area-efficient but more cycle-intensive Ascon-HPC2. Overall, we believe the mix of implementations in this and the previous section nicely reflect Ascon’s good implementation features and can cover a wide range of applications. 622 Low-Latency Masked Gadgets with Application to Ascon Figure 10: HPC4 gate adapted for sharing (examplary example for d= 2). PS(HPC2-ser, r.b.) PS(HPC2-ser, unr-2) PS(HPC2-ser, unr-3) FS(HPC4-r.b.) PS(HPC4-r.b., r.b.) PS(HPC4-r.b., unr-2) PS(HPC4-r.b., unr-3) PS(HPC2-ser, r.b.) PS(HPC2-ser, unr-2) PS(HPC2-ser, unr-3) FS(HPC4-r.b.) PS(HPC4-r.b., r.b.) PS(HPC4-r.b., unr-2) PS(HPC4-r.b., unr-3) PS(HPC2-ser, r.b.) PS(HPC2-ser, unr-2) PS(HPC2-ser, unr-3) FS(HPC4-r.b.) PS(HPC4-r.b., r.b.) PS(HPC4-r.b., unr-2) PS(HPC4-r.b., unr-3) 0 50 100 150 200 250 Area [kGE] Mode DPA SPA d= 2 d= 3 d= 4 Figure 11: Multi-target implementations: area comparisons. Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1623 6 Randomness generation Our evaluations so far excluded the cost of randomness generation. In this section, we therefore complete our investigations by analyzing this part of the implementation figures. For this purpose, we use the Trivium stream cipher which, as recently discussed in [ CMM+23 ], provides a good tradeoff between strong masking randomness that should not weaken the security of the implementations and good performances. Starting with generalities, we observe that since the cost of the PRNG is directly related to the amount of randomness required, the corresponding overheads will be the same for singleand multi-target designs, and depend on the underlying architecture of the protected primitive (serialized/round-based) and its masking scheme (HPC2/HPC4). More concretely, for d = 2 (resp., d = 3 , 4), the (serial) HPC2 implementation of the Ascon permutation requires 80 (resp., 240, 480) bits per cycle, for which a single (resp., two, four) Trivium instance(s), each one enabling to unroll up to 128 bits, is sufficient. By contrast, the (round-based, parallel) HPC4 one requires 1600 (resp., 4800, 9600) bits for d= 2 (resp., d= 3,4), which requires 13 (resp., 38, 75) Trivium instances. We implemented a selection of the previously presented designs using HPC2 and HPC4 gadgets in the NanGate 45 Open Cell Library, using the Cadence Design Vision toolchain. Area comparisons are depicted in Figure 12. For completeness, we additionally report the exact gate counts (in kilo-gate equivalent) in Appendix A,Table 8. Latencies are (again) the same as given by Equation 2 and Equation 3. Overall, these additional results essentially amplify the previous observations. HPC4-based implementations remain the most adequate when low-latency is the main design goal. Yet, their excellent performances come with significant area and, as shown in this section, randomness overheads – the optimization of which is an important open problem that we extend in conclusions. 7 Other applications As argued in introduction, Ascon is a timely target for implementations with HPC4 gadgets: it is being standardized by the NIST and has good features for side-channel security, both in terms of latency and leveling opportunities. In this section, we briefly discuss additional primitives that can benefit from HPC4 gadgets. We start with other low-latency ciphers in Section 7.1 and follow with iterative AND computations that can be used by authenticated encryption schemes or even post-quantum (public-key) cryptographic algorithms. 7.1 Low-latency ciphers Among the cipher using quadratic substitution layers, one illustration is Keccak and the SHA-3 standard, of which the permutation shares the low-latency features of Ascon. We give results for the (most standard) 1600-bit version SHA3-512. Another one is the authenticated encryption mode Ketje which is derived from Keccak (see https: //keccak.team/ketje.html ), which is more comparable to Ascon, but does not benefit from its strong model-level security guarantees. We give results for the 400-bit version Ketje Sr (which has a size close to Ascon). Our area (in kilo-gate equivalent) and latency results for uniformly protected implementations of these algorithms are in Table 5. Other examples can be found in the literature, like the Gimli permutation [BKL+17]. 7.2 Iterative AND reduction The computation of the conjuction of many bits, also known as the “AND reduction” of a vector of bits, appears in many cryptographic algorithms, for example when verifying 624 Low-Latency Masked Gadgets with Application to Ascon Uniform(HPC2-ser) Leveled(HPC2-ser, unr-3) PS(HPC2-ser, unr-3) Uniform(HPC4-r.b.) Leveled(HPC4-r.b.) PS(HPC4-r.b., unr-3) FS(HPC4-r.b.) Uniform(HPC2-ser) Leveled(HPC2-ser) PS(HPC2-ser, unr-3) Uniform(HPC4-r.b.) Leveled(HPC4-r.b.) PS(HPC4-r.b., unr-3) FS(HPC4-r.b.) Uniform(HPC2-ser) Leveled(HPC2-ser) PS(HPC2-ser, unr-3) Uniform(HPC4-r.b.) Leveled(HPC4-r.b.) PS(HPC4-r.b., unr-3) FS(HPC4-r.b.) 0 100 200 300 400 500 600 700 800 Area [kGE] Mode PRNG DPA SPA d= 2 d= 3 d= 4 Figure 12: Examplary implementations with randomness generation: area comparisons. Table 5: Performance characteristic for low-latency uniformly implementations of Ascon, SHA3-512 and Ketje Sr using HPC4 gadgets: area in [kGE] and latency results for 1, 4 and 10 blocks of 576 bits (the specified block size of SHA-512). dPrimitive Area (kGE) Latency (in cycle to process the amount of bits) 576 2034 5760 2 SHA3-512 207.7 48 192 480 Ketje-SR 50.3 39 85 201 Ascon 45.8 78 216 564 3 SHA3-512 594 48 192 480 Ketje-SR 118 39 85 201 Ascon 100 78 216 564 4 SHA3-512 1072.5 48 192 480 Ketje-SR 215.8 39 85 201 Ascon 179 78 216 564 Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1625 ⊗ x(i) s 1 0 1 Figure 13: Iterative AND architecture. a tag of an AE or when verifying component-wise properties of vectors in lattice-based cryptography (e.g., this happens for ciphertext equality checks in Kyber [ ABD+19 ] or for norm checks in Dilithium [ DKL+18 ]). In both cases, leakage on the AND reduction can lead to security issues requiring masking [ BMPS21 , UXT+22 , ABC+23 ]. 5 Therefore, these algorithms require verifying that all the bits of two η -bit vectors v and v0 are identical, without leaking about these bits. For this purpose, a standard option is to compute the difference x=v⊕v0and to output the conjunction of this difference to test equality. Figure 13 depicts a simple architecture to perform this computation at a rate of one bit of x per cycle. The MUX selects the sharing of 1 to reset ( s = 1) for one clock cycle, then activates the loop ( s = 0) to iteratively process the AND with x ’s bits afterward. The throughput of this circuit can be increased by adding a pre-processing pipeline circuit connected to the input x that computes the AND of a chunk of the input bit vector. Due to its single-cycle interative architecture, this implementation may exhibit composition issues when the AND gadget is not O-PINI, leading to lower-order leakage on the value of the accumulator bit, that is, on the conjunction of a subset of the bits of x. As a first step towards demonstrating that HPC4 gadgets fix concrete leakages that HPC3 gadgets can lead to in non-pipeline designs, we show in Appendix Athat the design of Figure 13 leads to exploitable leakage when instantiated with HPC3 gadgets, that vanish if we make the design pipeline or replace the HPC3 gadgets by HPC4 ones. 8 Conclusion In this paper, we investigated low-latency implementations of the Ascon cipher that ensure side-channel security in the presence of glitches and transitions. For this purpose, we introduced a new single-cycle gadget that can implement a secure AND gate in this setting, while existing solutions required at least two cycles. We then evaluated how to integrate this (and other relevant) gadgets in implementations of Ascon offering different tradeoffs between security and performance, which enable taking advantage of the interplay between mode-level and primitive-level countermeasures. We hope these investigations can better highlight the interesting features of lightweigth cryptographic algorithms like Ascon in order to provide high side-channel security levels at acceptable cost. We also expect these investigations to shed a light over the possibility offered by the Hardware Private Circuits to achieve low-latency with Ascon and other ciphers. As usual for such investigations, further improving performance figures remains an important scope for further research. In particular we believe that the cost of randomness can become a bottleneck for higher-order masked implementations. As a result, investigating how to boost these results is an important next step. Interestingly, and besides gains at the gadget level that could be obtained, design-specific optimizations enabling randomness re-use have already been introduced in the literature [ FPS17 , BDZ20 , FKS+22 ], and are therefore promising candidates for combination with HPC4 or improvements thereof. 5In the AE case, leakage-resilient tag verification can serve as alternative [BPPS17,DM21]. 626 Low-Latency Masked Gadgets with Application to Ascon Acknowledgments. Gaëtan Cassiers and François-Xavier Standaert are respectively post-doctoral researcher and senior research associate of the Belgian Fund for Scientific Research (FNRS-F.R.S.). This work has been funded in parts by European Union through the Horizon project 1010706275 (acronym REWIRE) and the ERC Advanced Grant 101096871 (BRIDGE). Views and opinions expressed are those of the authors only and do not necessarily reflect those of the European Union or the European Research Council. Neither the European Union nor the granting authority can be held responsible for them. References [ABC+23] Melissa Azouaoui, Olivier Bronchain, Gaëtan Cassiers, Clément Hoffmann, Yulia Kuzovkova, Joost Renes, Tobias Schneider, Markus Schönauer, FrançoisXavier Standaert, and Christine van Vredendaal. Protecting dilithium against leakage revisited sensitivity analysis and improved implementations. IACR Trans. Cryptogr. Hardw. Embed. Syst., 2023(4):58–79, 2023. [ABD+19] Roberto Avanzi, Joppe Bos, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, John M Schanck, Peter Schwabe, Gregor Seiler, and Damien Stehlé. Crystals-kyber algorithm specifications and supporting documentation. NIST PQC Round, 2(4):1–43, 2019. [ABP+17] Victor Arribas, Begül Bilgin, George Petrides, Svetla Nikova, and Vincent Rijmen. Rhythmic keccak: SCA security and low latency in HW. IACR Cryptol. ePrint Arch., page 1193, 2017. [ADL17] Tomer Ashur, Orr Dunkelman, and Atul Luykx. Boosting authenticated encryption robustness with minimal modifications. In CRYPTO (3), volume 10403 of Lecture Notes in Computer Science, pages 3–33. Springer, 2017. [BBC+19] Gilles Barthe, Sonia Belaïd, Gaëtan Cassiers, Pierre-Alain Fouque, Benjamin Grégoire, and François-Xavier Standaert. maskverif: Automated verification of higher-order masking in presence of physical defaults. In ESORICS (1), volume 11735 of Lecture Notes in Computer Science, pages 300–318. Springer, 2019. [BBC+20] Davide Bellizia, Olivier Bronchain, Gaëtan Cassiers, Vincent Grosso, Chun Guo, Charles Momin, Olivier Pereira, Thomas Peters, and François-Xavier Standaert. Mode-level vs. implementation-level physical security in symmetric cryptography - A practical guide through the leakage-resistance jungle. In CRYPTO (1), volume 12170 of Lecture Notes in Computer Science, pages 369–400. Springer, 2020. [BBD+15] Gilles Barthe, Sonia Belaïd, François Dupressoir, Pierre-Alain Fouque, Benjamin Grégoire, and Pierre-Yves Strub. Verified proofs of higher-order masking. In EUROCRYPT (1), volume 9056 of Lecture Notes in Computer Science, pages 457–485. Springer, 2015. [BBD+16] Gilles Barthe, Sonia Belaïd, François Dupressoir, Pierre-Alain Fouque, Benjamin Grégoire, Pierre-Yves Strub, and Rébecca Zucchini. Strong noninterference and type-directed higher-order masking. In CCS, pages 116–129. ACM, 2016. Gaëtan Cassiers1, François-Xavier Standaert1and Corentin Verhamme1627 [BBP+16] Sonia Belaïd, Fabrice Benhamouda, Alain Passelègue, Emmanuel Prouff, Adrian Thillard, and Damien Vergnaud. Randomness complexity of private circuits for multiplication. In EUROCRYPT (2), volume 9666 of Lecture Notes in Computer Science, pages 616–648. Springer, 2016. [BDMS22] Tim Beyne, Siemen Dhooghe, Amir Moradi, and Aein Rezaei Shahmirzadi. Cryptanalysis of efficient masked ciphers: Applications to low latency. IACR Trans. Cryptogr. Hardw. Embed. Syst., 2022(1):679–721, 2022. [BDZ20] Tim Beyne, Siemen Dhooghe, and Zhenda Zhang. Cryptanalysis of masked ciphers: A not so random idea. In ASIACRYPT (1), volume 12491 of Lecture Notes in Computer Science, pages 817–850. Springer, 2020. [BGI+18] Roderick Bloem, Hannes Groß, Rinat Iusupov, Bettina Könighofer, Stefan Mangard, and Johannes Winter. Formal verification of masked hardware implementations in the presence of glitches. In EUROCRYPT (2), volume 10821 of Lecture Notes in Computer Science, pages 321–353. Springer, 2018. [BKL+17] Daniel J. Bernstein, Stefan Kölbl, Stefan Lucks, Pedro Maat Costa Massolino, Florian Mendel, Kashif Nawaz, Tobias Schneider, Peter Schwabe, FrançoisXavier Standaert, Yosuke Todo, and Benoît Viguier. Gimli : A cross-platform permutation. In CHES, volume 10529 of Lecture Notes in Computer Science, pages 299–320. Springer, 2017. [BMD+20] Begül Bilgin, Lauren De Meyer, Sébastien Duval, Itamar Levi, and FrançoisXavier Standaert. Low AND depth and efficient inverses: a guide on s-boxes for low-latency masking. IACR Trans. Symmetric Cryptol., 2020(1):144–184, 2020. [BMPS21] Olivier Bronchain, Charles Momin, Thomas Peters, and François-Xavier Standaert. Improved leakage-resistant authenticated encryption based on hardware AES coprocessors. IACR Trans. Cryptogr. Hardw. Embed. Syst., 2021(3):641– 676, 2021. [BPPS17] Francesco Berti, Olivier Pereira, Thomas Peters, and François-Xavier Standaert. On leakage-resilient authenticated encryption with decryption leakages. IACR Trans. Symmetric Cryptol., 2017(3):271–293, 2017. [CGLS21] Gaëtan Cassiers, Benjamin Grégoire, Itamar Levi, and François-Xavier Standaert. Hardware private circuits: From trivial composition to full verification. IEEE Trans. Computers, 70(10):1677–1690, 2021. [CGM+23] Gaëtan Cassiers, Barbara Gigerl, Stefan Mangard, Charles Momin, and Rishub Nagpal. Compress: Generate small and fast masked pipelined circuits. Cryptology ePrint Archive, Paper 2023/1600, 2023. https://eprint.iacr.org/ 2023/1600. [CJRR99] Suresh Chari, Charanjit S. Jutla, Josyula R. Rao, and Pankaj Rohatgi. Towards sound approaches to counteract power-analysis attacks. In CRYPTO, volume 1666 of Lecture Notes in Computer Science, pages 398–412. Springer, 1999. [CMM+23] Ga"etan Cassiers, Lo"ıc Masure, Charles Momin, Thorben Moos, Amir Moradi, and François-Xavier Standaert. Randomness generation for secure hardware masking - unrolled trivium to the rescue. IACR Cryptol. ePrint Arch., page 1134, 2023.