Triplex: an Eﬃcient and One-Pass Leakage-Resistant Mode of Operation

. This paper introduces and analyzes Triplex , a leakage-resistant mode of operation based on Tweakable Block Ciphers (TBCs) with 2 n -bit tweaks. Triplex enjoys beyond-birthday ciphertext integrity in the presence of encryption and decryption leakage in a liberal model where all intermediate computations are leaked in full and only two TBC calls operating a long-term secret are protected with implementation-level countermeasures. It provides beyond-birthday conﬁdentiality guarantees without leakage, and standard conﬁdentiality guarantees with leakage for a single-pass mode embedding a re-keying process for the bulk of its computations (i.e., birthday conﬁdentiality with encryption leakage under a bounded leakage assumption). Triplex improves leakage-resistant modes of operation relying on TBCs with n -bit tweaks when instantiated with large-tweak TBCs like Deoxys-TBC (a CAESAR competition laureate) or Skinny (used by the Romulus ﬁnalist of the NIST lightweight crypto competition). Its security guarantees are maintained in the multi-user setting.


Introduction
Protecting cryptographic implementations against side-channel attacks is a tedious process and generally leads to significant performance overheads [MOP07]. Research to design modes of operation with good properties against leakage has therefore gained interest over the last decade. One popular approach for this purpose is to leverage so-called "leveled implementations", in which security is obtained by combining the minimum use of a highly protected component while the rest of the computations only requires frugal protections [PSV15]. As surveyed by Bellizia et al., this approach has led to different authenticated encryption schemes, which can be viewed as different tradeoffs between mode-level and implementation-level protection mechanisms [BBC + 20].
Starting with the top of the hierarchy established in [GPPS19], ISAP [DEM + 17, DEM + 20] and TEDT [BGP + 20] are two-pass modes of operation that guarantee both Ciphertext Integrity with Misuse-resistance and Leakage in encryption and decryption (CIML2) and CCA security with misuse-resilience and Leakage in encryption and decryption (CCAmL2). Relaxing the confidentiality with decryption leakage requirement, Ascon [DEMS21] and Spook [BBB + 20] are one-pass algorithms that guarantee CIML2 and CCAmL1, and follow the blueprint of the TETSponge mode of operation [GPPS20]. Such leakage-resistant designs have also been recognized as relevant for lightweight cryptography: ISAP and Ascon are both finalists in the ongoing NIST competition 1 , one of the modes proposed by the Romulus finalist relies on an adaptation of TEDT (that takes advantage of its 2n-bit tweaks) [IKMP20] and Spook was a Round-2 candidate.
Looking at their internal components, ISAP, Ascon and Spook are sponge-based designs, building on the good leakage properties of the Duplex construction [DM19]. By contrast, only TEDT is based on a Tweakable Block Cipher (TBC). As for one-pass modes relying on TBCs, the only existing options are the TET scheme given in the appendices of [BGP + 20], which aims at CIML2 and CCAmL1 guarantees like Ascon and Spook, and the AET-LR scheme in [GKP], which only targets CIML2 (ignoring confidentiality with leakage).
In this paper, we focus on the challenge of designing a more efficient leakage-resistant mode of operation that provides similar guarantees as Ascon and Spook, but is based on TBCs. For this purpose, we follow the recent trend of leveraging TBCs with large tweaks, which it is the case for Romulus, but also for Deoxys-TBC-384 [JNPS21]. As discussed by List [Lis21], large-tweak TBCs are handy to improve the bounds and efficiency of TEDT (while also simplifying the analysis). We therefore leverage such a primitive to design a new mode of operation, coined Triplex, that additionally improves the rate of the TET construction. Namely, while TET requires two TBC calls (with n-bit tweaks) to encrypt and authenticate n bits of message, Triplex can encrypt and authenticate 2n bits with three TBC calls (with 2n-bit tweaks). 2 Concretely, Triplex enjoys: • n − log 2 (n) bits of confidentiality without leakage in the nonce misuse-resilient setting [ADL17]. That is, the confidentiality of messages under unique nonces holds as long as the total query complexity of the adversary does not exceed 2 n /n, even when other messages are compromised due to nonce misuse.
• n − log 2 (n) bits of CIML2 in the unbounded leakage model. That is, the integrity guarantees hold as long as the query complexity of the adversary does not exceed 2 n /n, even with nonce misuse and full leakage of the unprotected components.
Furthermore, these security guarantees do not vanish in the multi-user setting: Triplex still provides n − log 2 (n) bits of confidentiality and integrity in this context.
Besides its excellent features for leakage-resistance, we believe Triplex is also an interesting candidate to feed the comparison between Sponge-based and TBC-based designs in general [Pey20]. In particular, its improved rate makes it similar to TETSponge, Ascon & Spook regarding this metric. We initiate a comparative discussion of these ciphers by analyzing prototype hardware implementations in the last section of the paper.
Cautionary note. The confidentiality and the integrity of Triplex are analyzed in the ideal TBC model. This is a common trait of most formal analyzes in the multi-user regime. In this setting, we are concerned with how local computation (captured by the number of ideal TBC queries) affects security. The classical assumption on TBC (i.e., TPRP security) is not helpful for this estimation and will induce a security loss due to the black-box replacement. Thus, the bounds exclude generic attacks with local computations that just call the primitive. Besides, in the unbounded leakage model (for CIML2), the internal values (including ephemeral keys) are leaked and the standard model becomes vacuous.
Related works. With the goal to take advantage of efficient AES co-processors that are frequently available in embedded devices, the retrofitting mode of [USS + 20] and the LR-BC mode of [BMPS21] only rely on n-bit block cipher calls. These modes are in general less efficient than TBC-based modes due to this additional constraint, but they can lead to excellent performance in practice when these co-processors are indeed available.
Structure of the paper. After providing the necessary background in Section 2, we give the high-level ideas behind Triplex and its full specification in Section 3. Sections 4 and 5 provide the confidentiality analysis without leakage and the integrity analysis with leakage of Triplex. In the confidentiality section, we also provide a short discussion of its confidentiality with leakage, which we do not detail due to place constraints and its strong similarity with the analysis of other leakage-resistant modes leveraging re-keying. We end the paper with some hardware implementation results in Section 6.

Preliminaries
Notation. Let ε denote the empty string. Let {0, 1} * be the set of all finite bit strings including the empty string ε. For a finite set S, let x $ ← − S denote the uniform sampling from S assigning a value to x. Let |x| denote the length of the string x. Let x[i : j] denote the substring from the i-th bit to the j-th bit (inclusive) of x. Concatenation of strings x and y is written as x y or simply xy. If A is an algorithm, let y ← A(x 1 , . . . ; r) denote running A with randomness r on inputs x 1 , . . . and assigning the output to y. Let Tweakable block cipher [LRW11]. A block cipher E : K × M → M is a family of permutations, where E K (·) = E(K, ·) is a permutation over M. A tweakable block cipher E : K × T × M → M (with a slight abuse of notation E) is a family of permutations over M, indexed by two functionally distinct parameters: a key K ∈ K that is secret and used to provide the security, and a tweak t ∈ T that is public and used to provide variability. We write E K (t, ·) = E(K, t, ·), a permutation over M.
Nonce-based authenticated encryption [Rog02]. An AE scheme Π is a triplet of algorithms (K, E, D), where K is the key-generation algorithm, E the encryption algorithm and D the decryption algorithm. The key-generation algorithm K samples a key K uniformly at random from the key space. The encryption algorithm E takes as input a key K, a nonce N , an Associated Data (AD) A, a message M , and returns a ciphertext and tag C tag ← E K (N, A, M ). The decryption algorithm D takes as input a key K, a nonce N , an AD A, a ciphertext and tag C tag, and returns either a message M or a symbol ⊥ indicating invalidity. For correctness, we assume that if C tag ← E K (N, A, M ) then M ← D K (N, A, C tag). In this paper, the tag is always of fixed length.
Privacy security. We define the privacy security with respect to nonce-misuse resilience as introduced in [ADL17]. The privacy security game G priv Π is detailed in Figure 1. We consider the security in the multi-user setting. For queries to the same user, the adversary may repeat the nonce in the first encryption oracle Enc 1 , but the nonce in the second encryption oracle should be unique and fresh. For queries to different users, the adversary may repeat the nonce in both oracles. With access to oracles Prim, Enc 1 and Enc 2 , the goal of the adversary is to distinguish the second encryption oracle of an AE scheme from a random function. Formally, given an adversary A, we define Adv priv Π (A) = 2Pr G priv Π (A) − 1 as the advantage of the adversary against the privacy security of an AE scheme Π in the nonce misuse-resilience setting, with G priv Π (A) the abbreviation of G priv Π (A) = true.
Authenticity security. We consider the authenticity security in the leakage setting, and follow the notion of Ciphertext Integrity with Misuse-resistance and encryption and Figure 1: Game G priv Π : multi-user privacy security of an AE Π with nonce-misuse resilience. decryption Leakage (CIML2) by Berti et al. [BPPS17]. In the leakage environment, the adversary not only has access to encryption oracle E and decryption oracle D, but also to their corresponding leakage functions L E and L D . Here we consider it in the multi-user setting. Given an adversary A, we define as the advantage of the adversary against the CIML2 security of an AE scheme Π, where game G CIML2 Π is illustrated in Fig. 2 and G CIML2 Π (A) is the abbreviation that G CIML2 Π (A) = true. The adversary is given encryption and decryption oracles, which both contain the corresponding leakage function. She can repeat nonces in encryption and decryption queries. She may also make a decryption query (i, N, A, C tag) even if (i, N, A, C tag) has appeared in previous encryption queries. This kind of decryption query lets her obtain additional leakage during decryption. The goal of the adversary is to output a valid and new tuple (i, N, A, C tag) that passes the decryption oracle of the real AE scheme, while in the ideal world she will always receive a rejection symbol ⊥.
Hirose's Compression Function [Hir06]. Triplex makes use of Hirose's compression function (based on TBCs) to handle the message and associated data. We next recall the definition of this compression function. It is also represented in Figure 3.  where θ 1 is a non-zero constant.
Some useful Lemmas. We introduce some lemmas that will be useful in our analyzes. Lemma 1. [HT17,Lemma 15] Suppose that we throw u balls uniformly at random into 2 n bins. Then, with probability at most 2 −n , there exists some bin of more than max{4n, 4u/2 n } balls.
Lemma 2. [BHT18,Lemma 10] Suppose that we throw u balls into 2 n bins and, conditioning on the result of prior throws, the probability that each ball falls into any particular bin is at most 2 n−1 . Fix 0 < < 1, and let u ≤ 2 (1− )n−1 . Then with probabilty at most 2 −n/2 , there exists some bin of more than 1.5/ balls.
The collision probability of Hirose's Double-block-length hash function based on a TBC is formalized by the following lemma.

Specifications of Triplex
In this section, we give the full details of Triplex. Triplex is a one-pass AE mode based on TBCs with large tweaks. To achieve so-called Grade-2 leakage security (i.e., a combination of CCAmL1 for confidentiality and CIML2 for integrity), we combine an ephemeral key evolution process based on a compression function as in [BMPS21] with strengthened Key Derivation Function (KDF) and Tag Generation Function (TGF). On the one hand, the ephemeral key evolution allows iteratively processing each block of message with a fresh key, which is reminiscent of other designs conferring confidentiality guarantees in the presence of encryption leakage [BBC + 20]. On the other hand, the compression function is used to progressively absorb the blocks to make the computation more and more dependent on the already processed blocks, leading to a kind of digest that can then be authenticated using a fixed-length Leakage-Resilient Message Authentication Code (LR-MAC).
In the following, we explain the intuition behind the design of Triplex and discuss the difference with sponge-based designs before providing the full specifications. The security analysis is postponed to the next sections.

Design Blueprint
Triplex follows the general 3-step blueprint suggested in [BBC + 20] for Grade-2 designs. In the initialization step, we generate a random 2n-bit state (h 1 , k 1 ) from a key derivation function KDF K (P, N ), where k 1 is an ephemeral encryption key. P is a random key that can be public. It confers more security in the multi-user setting as in Spook [BBB + 20] and TEDT [BGP + 20], since in order to implement key-collision attack, the adversary needs to find a collision for both secret key K and public key P among many users. As detailed later, the KDF requires only a single call to the protected TBC. Next, the bulk of the computation is instantiated as a one-time encryption of M 1 · · · M where, at each successive processing of a message block M i , the corresponding ciphertext block C i is created and absorbed, and the state is refreshed. We then also absorb the Associated Data (AD) resulting in a final state (h f , k f ). Eventually, in the finalization step, we use an LR-MAC for the TGF to authenticate (h f , k f ) and creating a tag using only a second protected TBC call. That means that the linear number of TBC calls in the message (and AD) processing part can remain unprotected, leading to performance benefits.
We now give more details about the intermediate step.
To improve the rate of our AEAD, we start from the Hirose compression function Hir implemented with two calls to the TBC with large tweaks (see Section 2, Figure 3). This allows absorbing 2n-bit blocks of message per iteration, plugged as the tweak of both TBC calls. By iterating, we get a hash function with 2n-bit state (h i+1 , k i+1 ), no matter the size of the tweak. Our goal is to turn this hash function into a one-time encryption of the 2n-bit block of message by making a single additional call to the underlying TBC, thus processing 2n bits with only 3 unprotected TBC calls. The reason why a single additional call is enough is because we can already encrypt the first n bits of the block by XORing it with the random half state h i . We use the other half state k i as an ephemeral key to encrypt the last n bits of the message block (by XORing it with the output of the additional TBC call). We absorb the resulting 2n-bit ciphertext block in the compression function from (h i , k i ). Since the key k i is used thrice per iteration, we use two constants θ 1 , θ 2 to enforce all the plaintext-inputs h i , h i ⊕ θ 1 , h i ⊕ θ 2 of the TBC to be distinct. This key-input and these 3 plaintext-inputs are thus deterministic in the current state (h i , k i ), and remain out of the direct control of the adversary.
In Figure 4, we depict the encryption of M 1 . . . M 4 with associated data A 1 A 2 , where (h 1 , k 1 ) is the initial state. The 3 TBC calls per 2n-block of message can easily be parsed from the picture. For each processing of message block, the 2 (vertical) TBC calls in black represent Hir. In red, the additional TBC call corresponds to our plug-in that turns Hir into a block encryption. The final state is (h 4 , k 4 ) in this case.
We now picture Triplex's initialization step (which derives the initial state) as well as the finalization step (which generates the tag from the final state) in Figure 5. For the KDF in Figure 5(A), we first use the key K, the public key P and the nonce N to set up an IV (h 0 , k 0 ) for the compression function, where h 0 = 0 n and k 0 is the TBC output. The preimage resistance of the half state h i -value as the image of a single-length compression function ensures that no internal state can collide with (h 0 , k 0 ) because otherwise h i = 0 n . To avoid initial-state-collisions between encryption and decryption, we simply apply Hir once with the nonce and the public key: we make the unprotected call Hir(h 0 , k 0 , N P ). This very first call to Hir inside KDF forces the initial state (h 1 , k 1 ) to diverge for distinct pairs (N, P ) even if some collision on k 0 occurs. For the TGF in Figure 5(B), we borrow the recent LR-MAC due to [BGPS21] which already leverages double-size tweak to get an elegant and simple beyond-birthday authentication mechanism. For checking the validity of the tag in decryption, this LR-MAC relies on the invertibility of the TBC in order to avoid leaking any information on the right tag given any adversarially chosen invalid   ciphertexts, as formalized in [BPPS17]. The verification thus simply checks whether the inversion gives back the constant 0 n , and otherwise the computed n-bit string is random and independent of the valid tag. As a result, even this part can leak in full.
We can reuse the same key K in both initialization and finalization. Since the first protected TBC call involves the tweak P 0 n , the n-bit 0-string serves as separation. Indeed, in the second protected TBC call, it is very unlikely that the final state (h l+v+1 , k l+v+1 ) is such that k l+v+1 = 0 n for the same preimage reason given above.
Note that it is easy to separate the computation of the unprotected TBCs with the protected ones, which will be handy in our security analysese. While many unprotected TBC calls use N P as tweaks with P = 0 n , with very high probability these computations cannot collide with the first protected TBC. In the same spirit, while the plaintext-input of the protected TBC call in TGF is 0 n , no internal unprotected TBC calls is going to have the same input, except with very low (negligible) probability. The only exception is actually with h 0 in KDF, which will be handled in the proofs.
Regarding the difference between Triplex and sponge-based designs, although security goals may be similar (CCAmL1 + CIML2), the underlying primitives and security proofs are quite different. Triplex is built on top of a TBC and uses Hirose hash to absorb data, has different KDF, TGF and message processing parts as detailed above, and innovatively uses a third TBC to encrypt messages, leading to a better rate than TET. While the state (h i , k i ) is also used to encrypt 2n-bit block of message, the Hirose compression function actually absorbs h i , k i and the resulting 2n-bit encrypted block. Somehow, and unlike sponge-based designs, our state can be seen as cleverly playing both the roles of the rate and the capacity in the Duplex mode: while the state is used as one-time encryption key (partially thanks to our third TBC call), and thus as a "rate," it is also absorbed without any adversarial manipulation, and can also be considered as a "capacity." Therefore, even if h i can be deduced from the encryption of a known plaintext it still plays a fundamental role in the high collision resistance of the compression function together with k i . For confidentiality, only the ephemeral key k i should remain secret to produce the next secret state (h i+1 , k i+1 ). We elaborate further on the comparison with the rate and the capacity in sponge -based designs in Appendix C.
For the security analysis, we cannot generically rely on the collision resistance of Hirose's hash function in the hope to deal independently with our additional third TBC call for confidentiality. This would have made the proof simpler at a first sight but the third TBC call uses the same key k i of the internal two TBC calls of the Hirose compression function at each iteration. Moreover, exploiting the best of the re-keying mechanism in the proof would become more complex. On the positive side, studying security "from scratch" at the fine-grained TBC level allows us to derive precise and higher security bounds.

Formal Description
The code description and figure are illustrated in Figure 6 and Figure 7. The concrete parameters for Triplex are given in Table 1.
Padding Method. The padding function first appends a single 1 and then the smallest number of 0s to the plaintext M such that the length of the padded plaintext is a multiple of 2n bits (since in each iteration, it can handle a 2n-bit string). The resulting padded plaintext is parsed into 2 blocks of n bits where = |M |/2n , namely where |M [i]| = n. The same padding function is applied to parse the associated data A into 2v blocks of n bits where v = |A|/2n , namely except if the associated data A is empty. In this case, no padding is required and no associated data is processed. Formally, for any M ∈ {0, 1} * and A ∈ {0, 1} * ,

Confidentiality Analysis of Triplex
In this section, we give the privacy analysis for Triplex in the nonce-misuse resilience setting. We also explain how the techniques of [BGP + 20, GPPS20] can easily be applied to Triplex to derive its CCAmL1 security at the end of the section. Nonce-misuse resilience. We next show that Triplex provides beyond-birthday privacy security in the nonce-misuse resilience setting (see the experiment in Figure 1).
Theorem 1. For any adversary A against u users that makes at most q encryptiones queries, p ideal TBC queries, with the total number of primitive calls among these q encryption queries being at most σ, we have where c 1 = max{4n, 4u/2 n } and assuming that q ≤ 2 n−1 , σ ≤ 2 n−3 and p + σ ≤ 2 n−1 .
Figure 7: Triplex's full encryption details. The first 3 TBC calls on the left represents KDF producing the initial state (h1, k1). The last TBC call on the right represents TGF producing the tag. Only the TBC calls colored in gray at the extremities are protected.
Discussion and overview of the proof. Theorem 1 implies that Triplex provides confidentiality security as long as the total number of primitive calls σ and the total number of ideal TBC queries p (also known as the offline queries) does not exceed 2 n /n, and the number of users u can be as large as 2 n .
The proof is based on the observation that Triplex is indistinguishable from a random scheme as long as there are no full collisions among the 2n-bit state value (h i , k i ). Due to freshness of the nonce in the second encryption oracle, this state value collides with probability approximately σ 2 /2 2n . Regarding (key,tweak) collisions between direct calls to TBC and KDF, these happen with probability around c 1 p/2 n for some constant c 1 since multiplicities of the public keys P i can be bounded by Lemma 1. For collisions between direct calls to the TBC and internal TBC calls among Triplex, the influence on the bound is not significant since the maximum number of state values with the same h i can be bounded by Lemma 2. Regarding (key, tweak) collisions between direct calls to TBC and TGF, these happen with probability about p/2 n since there is no full collision among the final 2n-bit state value (h +v+1 , h +v+1 ). Regarding key collisions among many users, these happen with probability about u 2 /2 2n with the help of public key P i . More details can be found in the formal proof. Note that our security analysis (including the integrity analysis in Section 5) can be modified syntactically to cover the case when Triplex processes associated data (AD) before message M . The proof idea is exactly the same.
Proof. Recall that in the security game as illustrated in Figure 1, the adversary is granted access to three oracles, namely the first encrytion oracle, the second encryption oracle and the ideal TBC oracle. The first encryption oracle and the ideal TBC oracle behave exactly the same in both the real and ideal worlds. Hence our goal is to prove that it is hard for the adversary to distinguish the outputs of the second encryption oracle in the real world from those outputs in the ideal world, except with a negligble probability.
Formally, from the interaction with its oracles, the adversary can obtain: • Ideal TBC queries. For each query Prim(J, T, (x, +)) with answer y, we associate it with an entry (prim, J, T, x, y, +). Similarly, for each query Prim(J, T, (y, −)) with answer x, we associate it with an entry (prim, J, T, x, y, −). .
We associate the query with an entry (enc 1 , i, N, A, M, C tag). We also use the entry (inter, J, T, x, y) to record the underlying primitive calls during the computation of this query, which are used for the analysis and hidden from the adversary's view.
• Queries to the second encryption oracle. For each query Enc 2 (i, N, A, M ) with answer C tag, similarly to the case of the first encryption oracle, we associate it with an entry (enc 2 , i, N, A, M, C tag), and use the entry (inter, J, T, x, y) to record the underlying primitive calls during the computation of this query. Note that the only difference between queries to the first encryption oracle and second encryption oracle is that the nonce in the former ones may repeat while the nonce in the latter ones should be unique and different from those of the former ones.
We next define some bad events in the real world, and argue that the outputs in the real world are the same as random strings when none of these bad events happen. Denote as parent(h a . We say the flag bad 1 is set to true if at least one of the following bad conditions is triggered: (1) There exits two users i and j (i = j) such that K i = K j and P i = P j .
(2) The same P i repeats at least c 1 times among u users.
(3) There exists an ideal TBC query (prim, J, T, x, y, * ) such that J = K i and T = P i 0 n for some user i.
(4) There exists an internal primitive call (inter, J, T, x, y) such that J = K i and T = P i 0 n for some user i.  We briefly comment on the intuition behind these bad conditions.
Condition (1) is to avoid key collisions among u users. Condition (2) is to put a threshold on the maximal repeated times of a public P i among u users, which helps to analyze other bad conditions. Conditions (3) and (4) are to guarantee that the inputs (including the secret key and tweak) of the first TBC remain different from that of the ideal TBC queries or underlying primitive calls, thus preserving the randomness of the output. Condition (5) is to ensure that even when (N, A, M ) may repeat between two users, the initial value (k 0 , N P ) of the hash function remains different, thus avoiding trivial collisions for the hash function between two users. Condition (6) is to avoid the input collision between the first TBC and last TBC, that is if k a i, a+va+1 = 0 n , then the tweaks of these two TBCs are always distinct. Condition (7) is to ensure that for each encryption query , tag a i is always a n-bit random string since the (key,tweak) pair of ( In Lemma 4 and Lemma 5 we will bound these two terms by u 2 + 16(σ + p) 2 2 2n+1 + 3c 1 (σ + p) + q + 3np + nσ + 3σ + 3p + 1 2 n + 2 2 n/2 , which completes the proof.
Lemma 4. Assume that the adversary makes at most q encryption queries, p ideal TBC queries, with the total number of primitive calls among these q encryption queries being at most σ. Then we have where c 1 = max{4n, 4u/2 n }.
Proof. We now analze the probability that the flag bad 1 is set to be true. Let event i be the event that the i-th condition is triggered. We consider each event in turn.
For event event 1 , since both K i and P i (1 ≤ i ≤ u) are chosen uniformly at random from the set {0, 1} n , the probability that K i = K j and P i = P j is exactly 1/2 2n . Summing over at most u 2 /2 pairs of (i, j), Next, we analyze event event 2 . In this case, each P i is public and chosen uniformly at random from the set {0, 1} n . Let c 1 = max{4n, 4u/2 n }. Then by using the balls-into-bins result from Lemma 1, Pr [ event 2 ] ≤ 1 2 n . We then analyze event event 3 . Conditioned on ¬event 2 , each P i repeats at most c 1 times among all users. Hence for each ideal TBC query (prim, J, T, x, y, * ), there are at most c 1 users such that P i 0 n = T . The probability that J = K i for any of these c 1 users is 1/2 n since K i is uniformly and randomly distributed in the set {0, 1} n . Summing over at most p ideal TBC queries, Pr [ event 3 ] ≤ c 1 p 2 n . The analysis of event 4 is similar to that of event 3 . Summing over at most σ primitive calls, We then analyze event event 5 . For each N a i P i , there is only one corresponding N b j P j such that N b j P j = N a i P i . On the other hand, conditioned on ¬event 1 , if P i = P j , then K i = K j must hold. Thus, the probability that E Ki (P i 0 n , N a i ) = E Kj (P j 0 n , N b j ) is 1/2 n since these two TBCs use different keys. Summing over at most q queries, Moving to event event 6 , if this event happens, it implies that the n-bit output of the Davies-Meyer construction of the Hir compression function equals 0 n . The Davies-Meyer construction cannot be inverted and each of its outputs is uniformly distributed in a set of size at least 2 n − σ − p. Summing over at most σ + p TBC calls and internal primitive calls, we get Pr [ event 6 ] ≤ σ + p 2 n − σ − p ≤ 2σ + 2p 2 n by assuming σ + p ≤ 2 n−1 . We next consider event event 7 . For each ideal TBC entry (prim, J, T, x, y, * ) or internal primitive call (inter, J, T, x, y), conditioned on ¬event 2 , there are at most c 1 encryption queries (enc 2 , i, N Among these queries, the value k a i,0 is chosen uniformly at random from a set of size at least 2 n − q. Hence the probability that k a i,0 = J is at most 1/(2 n − q). Summing over a total of p + σ ideal TBC queries and interal primitive calls, by assuming q ≤ 2 n−1 . Next, we analyze event event 8 . If this event happens, then it implies that the adversary found a collision on the hash function by using at most σ + p TBC queries. Hence, from Lemma 3: For the event event 9 , we rely on the biased balls-into-bins result of Lemma 2. Note that conditioned on ¬event 8 , for b − 1 ≥ 1, each h a i,b−1 k a i,b−1 is fresh, and thus each internal output k a i,b is uniformaly distributed in a set of size at least 2 n − σ − p. Hence the proability that k a i,b equals to some particular value is at most 1/(2 n − σ − p) ≤ 1/2 n−1 by assuming σ + p ≤ 2 n−1 . The argument for h a i,b is similar. Let c 2 = n. Then from Lemma 2 and assuming σ ≤ 2 n−3 , Pr [ event 9 ] ≤ 2 2 n/2 . Next, we analyze event event 10 . Note that conditioned on ¬event 9 , for each ideal TBC query (prim, J, T, x, y, * ), there are at most n values h a i,b such that h a i,b = T . The probability that J = k a i,b for any of these h a i,b k a i,b is at most 1/(2 n − σ − p). Summing over at most p ideal TBC queries, On the other hand, the probability that K i = J is 1/2 n since K i is a ranom n-bit string. Summing over totally σ + p internal primitive calls and ideal TBC queries, we get Wrapping up, the probability that the flag bad 1 is set to be true is at most u 2 + 16(σ + p) 2 2 2n+1 + 3c 1 (p + σ) + q + 2np + 3σ + 3p + 1 2 n + 2 2 n/2 , which concludes the proof.
Lemma 5. Assume that the adversary makes at most q encryption queries, p ideal TBC queries, with the total number of primitive calls among these q encryption queries being at most σ. Then CCAmL1. Here we only present heuristic analysis for the confidentiality with leakage since the proof is standard and follows from previous analyzes for leakage-resistant modes of operations [GPPS20, BMPS21, GPPS19, BGP + 20] without technical novelty. The formal definition of CCAmL1 security is given in Appendix B. As a heuristic argument, it is easy to see that ignoring decryption leakages and assuming fresh nonces, every message block is encrypted with a fresh key up to the birthday bound. Note that h i and k i are outputs of single-length compression functions. So at high-level, and using the simplified assumptions of [BBC + 20], the security of our mode reduces to the SPA security of a single (freshly keyed) iteration encrypting a 2n-bit block of message. 3 A bit more formally, to prove the CCAmL1 security of our mode, which stands for CCA security with misuse-resilience and leakage-resistance [GPPS19], we can rely on the hard-to-invert leakage assumption, which follows [YSPY10] and was used in [BGP + 20] for TEDT. In the CCAmL1 game, the adversary is not granted access to a leaking decryption oracle but only to a black-box decryption (and the above black-box analysis of misuseresilience already covers such queries). We briefly sketch the leakage function in encryption and challenge queries. For a fresh nonce in encryption, we can argue that the initial state (h 1 , k 1 ) ∈ {0, 1} 2n is random (see Figure 5(A)). That is because, up to the birthday bound, all the k 0 's computed from the protected TBC are distinct, secret and random. 4 Then, the same holds for all the initial states (h 1 , k 1 ) since there are only two calls to E k0 in Hir, and their leakage thus remains quite limited. For any repeated nonce in encryption, an adversary could easily mount a DPA on the initial state by using many 2n-bit block of message M 1 M 2 . 5 However, the initial state related to any nonce-respecting query (as required for the computation of challenge ciphertexts) remains independent and secret.
We now argue why any internal state remains sufficiently hidden in any challenge encryption query and why the security follows. Let (h i , k i ) be the current state and M 2i−1 M 2i the 2n-bit block of message that is being processed in the computation of a challenge ciphertext. The ephemeral random key k i is only used thrice in this iteration with distinct plaintext-inputs h i , h i ⊕θ 1 , h i ⊕θ 2 (see Figure 4). Since k i will not be used anywhere else (up to the birthday bound), the 3 TBC calls should not leak enough information about the refreshed state (h i+1 , k i+1 ) which will then be random and will remain secret (at least, until this point). Therefore, the secrecy and the randomness of an internal state propagates to the next one. Moreover, the final state and the TGF computation are independent of the message processing since the last TBC call (see Figure 5(B)) is protected and the long term key then remains secret. The CCAmL1 security thus reduces to the leakage of the one-time XOR computation of Up to the fact that h i is also involved in E ki (C 2i−1 C 2i , h i ⊕ θ 1 ) and E ki (C 2i−1 C 2i , h i ), these XORs are the minimal amount of encrypting manipulations one can hope. Since the involvement of h i in E ki is internal and out of the adversary's control (in the challenge ciphertext computations), it is reasonable to assume that very little informative leakage comes out. In the hard-to-invert leakage model, we can iterate the argument until the final state as the leakage between the iterations are independent.

Integrity Analysis of Triplex
In this section, we present the authenticity analysis of Triplex in the leakage setting.
CIML2 Security of Triplex. We will analyze the CIML2 security of Triplex in the unbounded leakage model [BPPS17, BKP + 18]. In this model, the leakage functions expose all the internal states to the adversary during the computation of unprotected building blocks, while the key of strongly protected components remains secret from the adversary and only their inputs and outputs are leaked. Concretely, in Triplex, the first and the last TBCs used for the KDF and TGF have to be strongly protected thanks to implementationlevel countermeasures, while the rest of TBC calls (used for the bulk of the computation) do not require any protection to ensure integrity.
Theorem 2. For any adversary A against u users that makes at most q encryption and decryption queries, p ideal TBC queries, with the total number of primitive calls of these encryption and decryption queries being at most σ, we have by assuming σ + p ≤ 2 n−1 and c = max{4n, 4u/2 n }.
Discussion and overview of the proof. Theorem 2 can be interpreted that Triplex provides integrity security as long as the total number of primitive calls σ does not exceed 2 n /n and the total number of ideal TBC queries p does not exceed 2 n /n, and the number of users can be as large as 2 n . The proof is based on the fact that as long as the final 2n-bit state value (h +v+1 , k +v+1 ) is fresh, then it is hard for the adversary to predict the output of Triplex. For queries to the same user i, since each input tuple (N, A, M ) is unique, these collisions can be reduced to the collision probability of Hirose's Double-block-length hash function that is captured by Lemma 3. For queries to different users, although the tuple (N, A, M ) may repeat, the key pair (K i , P i ) is unlikely to collide and thus avoids trivial collisions. Regarding (key, tweak) collisions between direct calls to TBC and KDF, these happen with probability about cp/2 n for some threshold c since multiplicities of P i can be bounded by Lemma 1. Regarding (key, tweak) collisions between direct calls to TBC and TGF, these happen with probability about p/2 n since each final state value (h +v+1 , k +v+1 ) is unique. The formal proof is more detailed.
Proof. From the interaction with its oracles, the adversary obtains responses from the TBC oracle, encryption oracle and decryption oracle, formally leading to: • Ideal TBC queries. For each query Prim(J, T, (x, +)) with answer y, we associate it with an entry (prim, J, T, x, y, +). Similarly, for each query Prim(J, T, (y, −)) with answer x, we associate it with an entry (prim, J, T, x, y, −).
Define h = (h 0 , . . . , h +v+1 ) and k = (k 0 , . . . , k +v+1 ). Since we are working in the unbounded leakage model, except the key K of the first and final TBC call, all the values of h and k are leaked to the adversary. Hence, we associate the query with an entry (enc, i, N, A, M, T tag, h, k). Note that the adversary is able to know the underlying primitive calls from this entry. We use (leak, J, T, x, y) to record each of these underlying primitive calls. That is, the tuple (leak, J, T, x, y) covers: -(leak, k 0 , N P i , 0 n , h 1 ) and (leak, k 0 , N P i , θ 1 , k 1 ⊕ θ 1 ) during initialization; during the message processing phase; , h +j ⊕ θ 1 , k +j+1 ⊕ h +j ⊕ θ 1 ) during the AD processing phase.
Remark. In the CIML2 game, the adversary is allowed to make a decryption query even this query has appeared in previous encryption phase. The intuition is that the adversary may obtain some additional leakage information via this kind of repeated decryption queries. However, in the unbounded leakage setting, all the internal values are already leaked to the adversary in encryption queries. Therefore, we ignore such trivial decryption queries in the following treatment.
. We associate this query with an entry (dec, i, N, A, M, C tag, h, k, x). We use (leak, J, T, x, y) to record the underlying primitive calls that the adversary can learn from this entry.
We say that the adversary forges successfully if any of its decryption queries passes the decryption oracle, namely the returning message M is not a false symbol ⊥. We now proceed to prove that the probability that the adversary forges successfully is negligible.
To this end, we will first define some bad conditions. A flag bad is set to be true if at least one of the following conditions is triggered: (1) There exits two users i and j (i = j) such that K i = K j and P i = P j .
(2) The same P i repeats at least c times among u users.
(3) There exists an ideal TBC query (prim, J, T, x, y, * ) such that J = K i and T = P i 0 n for some user i.
(4) There exists a leaked primitive call (leak, J, T, x, y) such that J = K i and T = P i 0 n for some user i.
(5) There exists two queries ( , there exists some previous encryption query (enc, j, N , j, N (11) There exists an ideal TBC query (prim, J, T, x, y, * ) such that J = K i and T = h a i, a +va+1 k a a +va+1 for some decryption query (dec, i, N, A, M, C tag, h, k, x).
(12) There exists a leaked primitive query (leak, J, T, x, y) such that J = K i and T = h +v+1 k +v+1 for some decryption query (dec, i, N, A, M, C tag, h, k, x).
We briefly discuss the intuition behind these bad conditions. Condition (1) is to avoid key collisions among u users. Condition (2) is to put a theshold on the maximal repeated times of a public P i among u users, which is helpful to anlayze other bad conditions. Conditions (3) and (4) are to guarantee that the inputs (including the secret key and tweak) of the first TBC remain different from that of the ideal TBC queries or underlying primitive calls, thus preserving the randomness of output. Condition (5) is to ensure that even when (N, A, M ) may be repeated between two users, the initial values of the hash function remains different, thus avoiding trivial collision for the hash function between two queries. Condition (6) is to avoid the input collision between the first and last TBC calls. That is, if k a i, a +va+1 = 0 n , then the tweaks of these two TBCs are always distinct. Conditions (7)-(10) are to ensure that for each decryption query k a i, a +va+1 is different from that of other encryption or decryption queries. Conditions (11) and (12) are to ensure that for each decryption query (dec, i, , either the key K i or the tweak h a i, a +va+1 k a i, a +va+1 is fresh from that of ideal TBC queries and underlying primitive calls. It can be seen in the following that by excluding these bad conditions, the analysis of the adversary forging successfully apppears to be transparent.
First observe that (1) A bound on the probability that bad is set is given in Lemma 6.
We then analyze the chance that A forges given that bad is not set to be true. Such a forgery requires that . We distinguish several cases according to the type of decryption query (dec, i, Hence the probability that this query is a valid forgery is 0. , tag a i ) = 0 n with probability at most 1/(2 n − q) since conditioned on ¬bad, the value x a i is randomly picked up from a set of size at least 2 n − q.
• If neither of above two cases happens, then due to bad not happening, either K i or h a i, a +va+1 k a i, a +va+1 is fresh, and thus the probability that E −1 Ki (h a i, a +va+1 k a i, a+va+1 , tag a i ) = 0 n is exactly 1/2 n . Therefore, summing over at most q decryption queries, the probability that A forges conditioned on ¬bad is worth by assuming q ≤ 2 n−1 . Equation 1 and the bound of Lemma 6 complete the proof.

Lemma 6. Assume that the adversary makes at most q construction queries (including both the encryption queries and decryption queries), p ideal TBC queries, and the total number of primitive calls of these encryption and decryption queries is at most σ. Then
where the threshold c = max{4n, 4u/2 n }.
Proof. We now bound the chance that the flag bad is set to be true. Denote by event i the event when the i-th condition is triggered. We analyze each event in turn. For event event 1 , since both K i and P i (1 ≤ i ≤ u) are chosen uniformly at random from the set {0, 1} n , the probability that K i = K j and P i = P j is exactly 1/2 2n . Summing over at most u 2 /2 pairs of (i, j), Next, we analyze the event event 2 . In this case, each P i is public and chosen uniformly at random from the set {0, 1} n . Let c = max{4n, 4u/2 n }. Then by using the balls-into-bins result from Lemma 1, Pr [ event 2 ] ≤ 1 2 n . We then analyze the event event 3 . Conditioned on ¬event 2 , each P i repeats at most c times among all users. Hence for each ideal TBC query (prim, J, T, x, y, * ), there are at most c users such that P i 0 n = T . The probability that J = K i for any of these c users is 1/2 n since K i is uniformly and randomly distributed in the set {0, 1} n . Summing over at most p ideal TBC queries, Pr [ event 3 ] ≤ cp 2 n . The analysis of event 4 is similar to that of event 3 . Summing over at most σ primitive calls, We then analyze event event 5 . For each N a i P i , there is only one corresponding N b j P j such that N b j P j = N a i P i . On the other hand, conditioned on ¬event 1 , if P i = P j , then K i = K j must hold. Thus the probability that E Ki (P i 0 n , N a i ) = E Kj (P j 0 n , N b j ) is 1/2 n since these two TBCs use different keys. Summing over at most q queries, Moving to event event 6 , if this event happens, it implies that the n-bit output of Davies-Meyer construction of the Hir compression function equals to 0 n . The Davies-Meyer construction cannot be inverted, and each of its outputs is uniformly distributed in a set of size at least 2 n − σ − p. Summing over at most σ + p TBC calls and internal primitive calls, we get by assuming σ + p ≤ 2 n−1 . Next, we analyze the events from event 7 to event 10 . If any of these four events happens, it means that the adversary can find a collision on the hash function H via at most σ + p ideal TBC queries. Hence, from Lemma 3 we get Next, we analyze the event event 11 . Note that conditioned on that there is not collision on the hash function H, for each ideal TBC query (prim, J, T, x, y, * ), there is at most one decryption query (dec, i, such that h a i, a +va+1 k a i, a +va+1 = T , and the probability that J = K i is 1/2 n since K i is a random n-bit string. Summing over at most p ideal TBC queries, we get The analysis of event event 12 is similar to that of event 11 , and summing over at most σ primitive calls we get Pr [ event 12 ] ≤ σ 2 n . Wrapping up, the probability that the flag is set to be bad is at most which concludes the proof.

Implementation Results
As mentioned in introduction, the natural competitors of Triplex are TET when it comes to TBC-based modes and Ascon & Spook when it comes to Sponge-based ones. Since the improvement of the rate over TET is clear, we use this last section to initiate a comparative discussion of the implementation features of leakage-resilient modes of operation based on TBCs and permutations. For this purpose, we introduce a leveled implementation of Triplex in hardware with Skinny-384+ as TBC [BJK + 16, Kha22]. We compare this implementation with a leveled implementation of Ascon [DEMS21]. For both ciphers, the implementation is made of a masked and an unmasked implementation of the primitive (Skinny-384+ and the Ascon permutation), targeting resistance against DPA and SPA, respectively. The primitive implementations are integrated in top-level mode implementations (containing the datapath of the mode and the control FSM). This architecture has been chosen for its simplicity and, as described below, our implementations of the primitives are also designed for simplicity. As any prototype implementations, they could be further optimized, but we do not expect such optimizations to change our main conclusions.
The implementation of Skinny is round-based (instantiating 32 S-boxes), and takes one cycle per round for the the non-masked implementation, while it takes 6 cycles per round for the masked implementation. Each masked S-box implementation contains two instances of the HPC2 masked AND gadget [CGLS21]. The implementations of the Ascon permutation are more serialized and based on an 80-bit S-box pipeline datapath (instantiating 16 S-boxes). The unmasked implementation therefore takes 4 cycles per round, while the masked implementation requires 6 cycles per round. In order to make the advantages of leakage-resistant modes of operation explicit, we add the results for Romulus-N [IKMP20], which uses the same long-term key in all its call to the Skinny-384+ TBC and therefore requires a uniformly masked implementation.
In Figure 8A, we show the number of cycles required for encrypting messages of various length. For short messages, the encryption time is dominated by the KDF and TGF. This duration is longer for Triplex than for Ascon, mainly due to the larger number of rounds in Skinny (the Hirose part in the KDF only takes less than 15 % of the KDF/TGF cycles). For longer messages, Ascon takes 24 cycles to encrypt a 64 bit message block, while Triplex takes 3 × 40 cycles to encrypt 256 bits of message. Overall, Ascon has a slightly better throughput despite a more serial architecture (80-bit vs. 128-bit). But  these results are admittedly quite sensitive to the security margins taken by designers. 6 Eventually, the different slope of Romulus-N's performance curve confirms an interest of leveled implementations from the performance (throughput) viewpoint. The implementations have been synthesized for a 65 nm CMOS commercial technology. In Figure 8B, we can see that the area of these implementations is dominated by the masked primitives (confirming the limited overheads of the leveled approach when high physical security levels are required). 7 So compared to Romulus-N, Triplex has a slightly higher area cost due to the need for both a masked and an unmasked cipher implementations. But this overhead shrinks relatively with a growing number of shares in the masking scheme, and is rewarded with a significantly better performance for messages larger than as little as 48 bytes. Moreover, we observe that the masked Skinny and Ascon have similar areas for small number of shares, while the area of Ascon grows faster than the one of Skinny-384+ as the number shares increases, due to the larger number of AND gates to mask: 80 for the 80-bit Ascon architecture (since it uses 5-bit S-boxes with 5 AND gates), 32 for the 128-bit Skinny-384+ architecture (using 16 serial S-boxes with 2 AND gates). We note that these values could be reduced with a more serialized masked implementation, at the cost of a higher KDF and TGF latency (amortized for long messages).
In both cases the unmasked primitives have a low area. So reducing their serialization would bring a significant throughput increase at the cost of limited area increase.
This study shows that the performances of optimized implementations of modes like Triplex heavily depend on the characteristics of its underlying TBC. Overall, Triplex instantiated with Skinny can achieve performance comparable to a sponge like Ascon, with variations depending on the implementation architectural tradeoff targeted.
Source code is available at https://github.com/uclcrypto/aead_modes_leveled_hw. 6 The best-known cryptanalysis result against Skinny reaches only 27 rounds out of 40, and is a related-tweakey impossible differential [LGS17,SMB18]. 7 The cost of the mode corresponds to the additional control logic / state machine, registers and multiplexers needed to implement the mode over the masked (and possibly unmasked) primitives.

Conclusion
As a conclusion, we provide a summary of state-of-the-art leakage-resistant constructions in Table 2, which contains the operational parameters of different published modes. We note that the quantitative bounds of their leakage security are similar: CIML2 is beyond birthday for all candidates and CCAmL1 and CCAmL2 can only be birthday secure given current techniques in the model of Guo et al. [GPPS19]. All schemes require two protected TBC calls for this purpose, excepted TEDT2 that needs 3. 8 We note that the Romulus-T mode is very similar to TEDT implemented with a TBC with 2n-bit tweaks. The first pass relies on PSV-encryption [PSV15] with a tweak schedule à la Romulus. The second pass in an hash-then-MAC based on Hirose's compression function with a large tweak like ours, and with a final TGF as in TEDT. It requires 6 TBC calls to process 2n bits of message. It is not designed for multi-user security but a direct adaptation would lead to multi-user security up to the birthday bound.
One additional advantage of Triplex over TET is that does not require the related tweakey security of the TBC (due to the fact that the state (h i , k i ) is such that h i ⊕ k i = M i−1 ⊕ C i−i in TET). Furthermore, Triplex does not need to invert unprotected TBC calls in decryption. As mentioned in introduction, Triplex also makes TBC-based designs more comparable to Sponge-based ones in terms of rate and state size.
Quite naturally, this table casts as main open problem the quest of further improved modes, whether being from the performance (e.g., rate) viewpoint, the simplicity of the underlying primitive or the weakness of the underlying (physical) assumptions.

B Definition of CCAmL1 Security
In this section, we recall the notion of CCAmL1 security (Chosen-Ciphertext Attacks security with misuse-resilience and Leakage) [GPPS19] in the multi-user setting. In this model, the adversary is granted the access to encryption oracle with leakage and decryption oracle, and aims at attacking the confidentiality of several messages encrypted under unique and fresh nonces. The advantage of the adversary is formalized by the left-or-right paradigm, namely for any two different messages M 0 and M 1 of equal length, the probability that the adversary can distinguish the encryption of these two messages is negligible. The selection of this paradigm is due to the conceptual difficulty to define the leakage of idealized objects in the real-or-random game. The CCAmL1 security game is illustrated in Figure 9. In this game, for queries to the same user, the adversary may repeat the nonce in the first leaking encryption oracle LEnc 1 , but the nonce in the second leaking encryption oracle LEnc 2 should be unique and fresh. For queries to different users, the adversary may repeat the nonce in both oracles. The adversary also has access to the decryption oracle Dec, but cannot forward queries from the second encryption oracle to Dec since this will result in trivial win. Given an adversary A, define

C More State Comparison with Sponges
Among the existing one-pass sponge-based designs, [BMPS21] highlights that Ascon and Spook achieve Grade-2 leakage security (i.e., CCAmL1 + CIML2), where the integrity holds in the unbounded leakage model. Like Triplex, that means that as long as the KDF and TGF functions are well-protected it is still infeasible to forge a ciphertext even if the full state leaks. Up to the generation of the initial state, this is not surprising since the design reduces to a hash-then-MAC in the CIML2 experiment, and the bulk of the computation which processes the message is a Duplex-like hash function in both modes.
To formally prove CIML2, the permutations must be modeled as ideal objects, as if the underlying permutation considered in the mode was uniformly picked among all the permutations of the appropriate size. This size is the size of the state which is usually denoted by b and decomposed into the rate part of r bits and the capacity part of c bits, so that b = r + c. Let S be a state, so the output of a permutation call. The input of the next permutation call is thus of the form S ⊕ (M ⊕ 0 c ), where the processed message block has size |M | = r. Therefore, even if the adversary knows the full state S in the unbounded leakage model, she has no direct control on the capacity that is being processed through the several permutation calls. She can only explicitly choose the rate of the next permutation input but not the capacity. Consequently, the bit size c plays an important role in the CIML2 security bound since it is easy to see that state collision can be generically reached from 2 c/2 ideal permutation queries. Indeed, once the adversary finds a collision on the c-bit state, she can easily choose the next message blocks to equalize the rate part she fully controls to get the same states. As a result, we must have c ≥ 2n if we target n-bit security for CIML2, and the TETSponge mode shows that taking c = 2n gives n − log n bits of security in the single-user setting, and n − 2 log n bits of security in the multi-user setting with appropriate KDF and TGF functions. With respect to Triplex based on TBC with n-bit keys and outputs, these sponge-based designs must satisfy c = 2n to have a similar CIML2 security. We eventually insist that the state leaks in full and that this security result cannot rely on the fact the the capacity remains secret. Actually, the capacity is known in the unbounded leakage setting. For the same reason, we can interpret (h, k) in Triplex as being used also as a capacity.
To prove confidentiality, we can of course not rely on the unbounded leakage setting. However, to generate the next random state it is enough that a sufficient number of bits of the capacity remain secret. For instance, the secrecy of the last n-bit of the capacity might be enough even if c > n. With n bit of secret in the state, the output of the next permutation call is kept random and hidden and the ephemeral encryption process with re-keying can be safely iterated. To make a comparison with Triplex, only the n-bit k in the state (h, k) needs to be secret to iterate the process block by block. Obviously, neither the rate of sponge-based modes nor h of Triplex of challenge ciphertexts should leak as otherwise distinghuishing becomes easy. But given the ciphertext returned as an answer to an encryption query for a chosen message, it is easy to deduce these values.