New approach to practical leakage-resilient public-key cryptography

Abstract We present a new approach to construct several leakage-resilient cryptographic primitives, including leakage-resilient public-key encryption (PKE) schemes, authenticated key exchange (AKE) protocols and low-latency key exchange (LLKE) protocols. To this end, we introduce a new primitive called leakage-resilient non-interactive key exchange (LR-NIKE) protocol. We introduce an appropriate security model for LR-NIKE protocols in the bounded memory leakage (BML) settings. We then show a secure construction of the LR-NIKE protocol in the BML setting that achieves an optimal leakage rate, i.e., 1 – o(1). Our construction of LR-NIKE requires a minimal use of a leak-free hardware component. We argue that the use of such a leak-free hardware component seems to be unavoidable in any construction of an LR-NIKE protocol, even in the BML setting. Finally, we show how to construct the aforementioned leakage-resilient primitives from such an LR-NIKE protocol as summarized below. All these primitives also achieve the same (optimal) leakage rate as the underlying LR-NIKE protocol. We show how to construct a leakage-resilient (LR) IND-CCA-2-secure PKE scheme in the BML model generically from a bounded LR-NIKE (BLR-NIKE) protocol. Our construction of LR-IND-CCA-2 secure PKE differs significantly from the state-of-the-art constructions of these primitives, which mainly use hash proof techniques to achieve leakage resilience. Moreover, our transformation preserves the leakage-rate of the underlying BLR-NIKE protocol. We introduce a new leakage model for AKE protocols, in the BML setting, and present a leakage-resilient AKE protocol construction from the LR-NIKE protocol. We introduce the first-ever leakage model for LLKE protocols in the BML setting and the first construction of such a leakage-resilient LLKE from the LR-NIKE protocol.


Introduction and related works
Traditional cryptographic primitives are provably analyzed in a black-box model, where the adversary has access to the primitive via restrictive and well-defined interfaces (oracles). However, this does not truly reflect the real-world scenario, where the adversary may obtain lots of unintended side-channel information about the cryptosystem from its implementation. This extra leakage of information is not accounted for in its analysis in the aforementioned black-box model of security. Leakage-resilient cryptography emerged as a theoretical foundation to address the issue of side-channel attacks. Here it is assumed that the adversary has access to side-channel information, which is modeled by allowing the adversary to specify arbitrary leakage functions (subject to some restrictions) and obtain leakage from the secret key of the system as dictated by these 2 | S. Chakraborty et al., New approach to practical leakage-resilient PKC functions. Note that some restrictions must be imposed on the class of allowable leakage functions as otherwise an adversary can simply read off the entire secret key from memory. Depending upon these restrictions, many theoretical models of leakage have emerged in the recent literature [2,6,9,14,16,30].
In this work, we focus mainly on the bounded-memory leakage model [2,6]. In this model, the adversary chooses arbitrary polynomial-time computable leakage functions f and receives f(sk), where sk is the secret key. The only restriction is that the sum of output length of all these leakage functions that the adversary can ever obtain is bounded by some parameter λ, which is smaller than the size of sk. Other notable models of leakage include the "only computation leaks information" (OCLI) model, continual memory leakage model, auxiliary input leakage model, etc. We briefly survey these models in Appendix B.
Ever since the ground-breaking work of Diffie and Hellman (DH) [13], authenticated key exchange (AKE) protocols arose as an important cryptographic primitive. The DH key exchange protocol can actually be viewed as a non-interactive key exchange (NIKE) protocol, where the parties can establish a shared key among themselves without any interaction, provided the public keys of all the parties are pre-distributed and they agree on some (common) global public parameters. NIKE is very useful in any bandwidth-critical, power-critical, resource-critical systems such as embedded devices, wireless and sensor networks, where the communication must be at its minimum. Despite its real-world applications, NIKE has mostly been overlooked until recently [19]. Freire et al. [19] proposed formal security models for NIKE and efficient constructions of NIKE in these models. Although the NIKE constructions of [19] are secure in the traditional (non-leakage) setting, the security of them may completely break down in the presence of leakage. In fact, we demonstrate that the pairing-based construction of NIKE shown in [19] is insecure, even if the adversary could obtain only a single bit of leakage from the secret key of a party. Therefore, it is really important to thoroughly study on the leakage resiliency of NIKE. We note that much research has been carried out on analyzing leakage resiliency of interactive key exchange protocols [3][4][5]11], but the leakage resiliency of NIKE remains largely unstudied. We note that Morita et al. [31] studied the security of NIKE protocols in the face of related key attacks (RKA) and show various implications and separation results (in the RKA setting) among the security notions of NIKE put forward by Freire et al. [19]. Morita et al. [31] have considered relatedkey attacks on NIKE and showed that there is a separation among the security notions. We can see that the equivalences between the different NIKE models of Freire et al. [19] easily carry forward to the leakage setting as well. Therefore, such separation does not hold in the leakage setting. We refer the interested readers to Morita et al. [31] and Freire et al. [19] for the detailed exposition.
As one of the central applications of leakage-resilient NIKE (LR-NIKE), we show how to construct a leakage-resilient IND-CCA-2-secure PKE scheme generically from LR-NIKE (in the bounded-memory leakage setting). All the previous constructions of leakage-resilient IND-CCA-2 (LR-IND-CCA-2) secure PKE schemes rely solely on hash proof techniques to achieve leakage resiliency. However, the generic approach of constructing a leakage-resilient CCA secure PKE scheme solely using hash proof systems (HPS) is inherently limited to a leakage rate below 1 2 as pointed out by Dodis et al. [15]. The leakage rate of the state-of-the-art constructions of a LR-IND-CCA-2-secure PKE scheme was later improved in the subsequent works of Qin et al. [35,36], which achieved leakage rates of 1 2 − o(1) and 1 − o(1), respectively. They could achieve a leakage rate of 1 2 − o(1) by using HPS and one-time lossy filters (OTLF)¹ and the optimal rate of 1 − o(1) by cleverly instantiating the underlying primitives, namely HPS and OTLF. However, the complexity assumption they make for their construction is rather non-standard, namely a refined subgroup indistinguishability (RSI) assumption over composite order groups. The parameters of their construction are also large due to the use of composite-order groups.
We deviate from this HPS-based approach of constructing LR-IND-CCA-2-secure PKE schemes and show that this connection is not inherent. To this end, we develop a new primitive called leakage-resilient noninteractive key exchange (NIKE). Our construction of leakage-resilient NIKE relies solely on a leakage-resilient chameleon hash function (which in turn relies only on a strong collision-resistant hash function) and only a constant number (to be precise, only 3) of pairing operations. We then show a very simple and generic construction of LR-IND-CCA-2-secure PKE schemes achieving the optimal leakage rate of 1 − o(1) based solely on the assumption that the leakage-resilient NIKE exists.
We also show the applicability of leakage-resilient NIKE to construct leakage-resilient authenticated key exchange (AKE) protocols and leakage-resilient low-latency key exchange (LLKE) protocols (in the boundedmemory leakage setting). All the previous constructions of leakage-resilient AKE protocols [4,11] either implicitly rely on HPS (by using leakage-resilient PKE as their building block) or explicitly by using the properties of HPS. Our generic construction of leakage-resilient AKE gives an alternate way to construct AKE protocols, different from the previous constructions of leakage-resilient AKE protocols, achieving the optimal leakage rate of 1 − o (1). Low-latency key exchange (LLKE) is one of the most practical key exchange protocols that permits the transmission of cryptographically protected data, without prior key exchange, while providing perfect forward secrecy (PFS). This concept was discussed in Google's QUIC² protocol. Further, a low-latency mode is currently under discussion for inclusion in TLS version 1.3. Although the first formal model of LLKE was studied by Hale et al. [23], leakage resiliency of LLKE remains unstudied until present. Being a candidate for TLS 1.3, it is important to explore the leakage resiliency of LLKE protocols as side-channel attacks widely exist.

Our contributions
The main contributions are abridged as follows.

Leakage-resilient NIKE
As our first major contribution, we study the leakage resiliency of NIKE protocols. We present a leakage security model for NIKE protocols, defining the notion of leakage-resilient non-interactive key exchange. We point out a subtle point in defining leakage-resilient NIKE protocols as discussed below and show that care must taken while defining it. Finally, we show how to construct a secure NIKE protocol.
Our model: Our model of leakage-resilient NIKE adopts and generalizes the CKS-heavy model of NIKE proposed by Freire et al. [19] in the setting of leakage. Firstly, we notice that defining the security of NIKE protocols in the setting of leakage requires more care than defining the security model for NIKE protocols in the non-leakage setting. Note that the shared key of a party in a two-party NIKE protocol is simply a deterministic function of its own secret key and the public key of the other party. However, in the setting of leakage, there is a simple attack on any LR-NIKE protocol as follows: the adversary can simply encode the (description) of the shared-key derivation function as the leakage function, with the public key of the other party hard-coded in the function. Hence, using this, it can directly leak from the shared key. To prevent this trivial attack, we must impose some meaningful restrictions. One plausible solution to circumvent the above attack could be to restrict the class of allowable leakage functions. In particular, one may assume that the leakage functions are not allowed to access the public parameters of the system (and hence the public keys of the parties) while leaking from the secret key of one party. However, this seems to be an unnatural restriction on the leakage functions since the public parameters (and in particular the public keys of all parties) are known to all the parties, and hence to the adversary also. To this end, we propose an alternative model for LR-NIKE protocols that avoids the above impossibility result. In particular, we assume that all parties participating in a NIKE protocol are equipped with a leak-free hardware component which can be used to shield a small part of their public keys. The leakage functions can access the public keys of all the parties, except the compo-4 | S. Chakraborty et al., New approach to practical leakage-resilient PKC nents stored in the leak-free hardware. Note that the leak-free hardware should be used in a minimal way in any LR-NIKE protocol³. Now we informally define our security model for LR-NIKE protocols.
Our model for LR-NIKE assumes that all parties participating in the protocol are equipped with a leakfree hardware component. This hardware is used to store a small part of their public keys, hence effectively shielding these parts from the view of the adversary. The specification of which components are stored in the hardware is protocol-specific. However, we stress that the usage of the leak-free hardware should be minimal. Our security model for LR-NIKE protocols is a very strong model allowing the adversary to register arbitrary public keys into the system, corrupt honest parties to obtain their secret keys, issue extract queries to obtain shared keys between two honest parties and also between one honest party and another corrupt party. Besides this, we also allow the adversary to obtain additional (bounded) leakage from both the parties involved in the Test/challenge query. We also introduce the notion of validity of a test query reminiscent of the notion of freshness of a test session for (interactive) key exchange protocols. Finally, in the (valid) test query between two honest parties, the adversary has to distinguish the shared key from a random key.
Our construction: The starting point of our construction is the NIKE scheme of Freire et al. [19]. However, we show that the above scheme is insecure in the setting of leakage, even if a single bit of the secret key is allowed to leak. The main step where the construction breaks down is related to the exponentiation operation. In other words, if exponentiation is performed normally as in the original protocol, it may be completely insecure in the presence of leakage. A common countermeasure against this uses masking technique, where the secret key of the system is secret-shared using a multiplicative secret sharing scheme and the exponentiation is done step-wise using each of these shares. However, these masking schemes do not achieve the optimal 1 − o(1) leakage-rate and also require additional restrictions (assumptions) on the class of allowable leakage functions for arguing security. In particular, all these masking schemes are proven secure in the only computation leaks information (OCLI) axiom of Micali and Reyzin [30] or under the split-state assumption [24,27,40]. The OCLI axiom postulates that the leakage only happens from the memory parts that are touched during the actual computation(s), and the rest of the memory portions not touched by computation are not prone to leakage. In the split-state leakage model, it is assumed that the secret key is split into several disjoint parts and the adversary is allowed to obtain leakage independently from each of these parts. However, both these models do not address leakage from the entire memory, which is the case for the bounded memory leakage model. So, a major challenge in our construction is to come up with a leakage-resilient exponentiation operation achieving a leakage rate of 1 − o (1) in the global memory leakage model. Our first idea is to use the techniques of [1,6,33] to perform leakage-resilient exponentiation. In particular, let be a group of prime order p, and let g 1 , . . . , g n be random elements of the group. Then the vector x = (x 1 , . . . , x n ) ∈ (ℤ * p ) n is said to be a discrete log representation of some element y ∈ with respect to g 1 , . . . , g n , if y = ∏ n i=1 g x i i . To incorporate this in our construction of NIKE, the elements g 1 , . . . , g n can be included in the public parameters params, the public key of a party can be set to y, and the secret key can be the discrete log representation x of y.
In [1,6,33], it is also shown that, as long as the leakage on each representation is bounded by (1 − 2 n )|x|, the adversary cannot come up with another discrete log representation x of y. So this achieves the leakage rate of 1 − o(1). However, it turns out that it becomes surprisingly difficult to incorporate this change in the construction of Freire et al. [19]. The main difficulty stems from the use of multiple generators and also the special structure of the public key.
To this end, we use the idea of the twisted-pair PRF trick [20], but carefully adapted to deal with leakage. The main idea behind the twisted-pair PRF trick is that it involves two PRFs F and F with reversing keys. The output of the twisting function is simply the output of the two PRFs that are combined together in special way. The guarantee is that the output of the twisting function is computationally indistinguishable from a uniform value over the same range. For our construction of a leakage-resilient twisted-pair PRF trick, we add strong randomness extractors as pre-processors to this original twisting technique [20]. The guarantee is that the output of our leakage-resilient twisted-pair PRF function is computationally indistinguishable from a uniform value over the same range, even if the adversary knows the key of one PRF in full and obtains bounded leakage from the key of the other PRF. For our construction of NIKE in the bounded leakage model, the strong randomness extractor (when appropriately parameterized) takes care of the (bounded) leakage, and then we can extract randomness from the secret key of the NIKE and use the extracted key as the key in one of the PRFs. The output of the leakage-resilient twisting function is then used to do secure exponentiation in the presence of leakage. By appropriately parameterizing the extractor, we obtain the optimum leakage rate of 1 − o (1). Combined with a bounded leakage-resilient CHF tolerating a leakage rate of 1 − o(1), we can achieve a leakage-resilient NIKE in the bounded-memory leakage model with overall leakage rate of 1 − o (1).
However, the main drawback of our leakage-resilient NIKE construction is that it requires a leak-free hardware assumption. However, as argued before, such an assumption is not merely an artifact of our protocol, but is likely to be required for constructing any LR-NIKE protocol. Since we allow the leakage function to access all the public parameters of the system (and hence the public keys of parties), the adversary can directly leak from the shared key of the parties by encoding the shared key derivation function as the leakage function. Our protocol requires a leak-free component to store the seed of the extractor. This is required because the view of the adversary in our construction should be independent of the seed since, otherwise, the adversary may leak from the extracted value and the uniformity guarantee of the extractor does not hold in this case. Hence we cannot include the seed in the public key. On the other hand, to compute the shared key, each party needs to have access to the random seed. Hence we require that the seed is stored in a leak-free hardware component. We also note that, since extractors are information theoretic gadgets, reusability of the seed is not permitted. Hence each party needs to store a short random seed corresponding to every other party in the leak-free hardware for establishing session keys with them. Minimizing this leak-free hardware assumption is an interesting and challenging problem we leave open. A leak-free hardware component assumption was also used in many prior works in leakage-resilient cryptography [18,22,25], although in the context of continual memory leakage. In particular, in [25], it is assumed that the leak-free component can produce random encryptions of fixed messages. In [22], it is assumed that there is a linear number of such leak-free components and each component is capable of sampling from a fixed polynomial-time computable distribution. In [18], it is assumed that the leak-free component can sample two vectors from the underlying field such that their inner product is zero. In contrast, in our construction, we do not require the leak-free hardware to perform any expensive computation. We only require it to store several seeds of the extractor, which are typically short random strings.
Comparison with Chen et al. [11,12]: It is instructive to compare our construction of BLR-NIKE with the leakage-resilient AKE protocols of Chen et al. [11,12]. Chen et al. [11,12] proposed constructions of AKE protocols secure against "after-the-fact" bounded-memory [11] (resp. auxiliary input [12]) leakage attacks. Our main idea of the BLR-NIKE protocols shares some technical similarities with [11,12]. Namely, the main idea of both these works is an "extract-then-PRF" technique, where a randomness extractor is applied on the long-term secret key (in case of [11,12] also on the ephemeral secret key) and then two PRFs with reversing keys are applied to the extracted values (twisted PRF trick). Our NIKE protocol uses the framework of Freire et al. [19] and uses the "extract-then-PRF" technique to tackle key leakage attacks. However, in this work, we consider before-the-fact leakage attacks, in contrast to [11,12] which considered after-the-fact leakage, however, at the cost of restricting the leakage model further to avoid the impossibility result related to afterthe-fact leakage.

Leakage-resilient CCA-2-secure PKE
As one of the central applications of leakage-resilient NIKE (LR-NIKE), we show how to construct leakageresilient IND-CCA-2 (LR-IND-CCA-2) secure PKE generically from LR-NIKE in the bounded-memory leakage model. This yields a new approach to construct LR-IND-CCA-2-secure PKE schemes, departing completely from the hash-proof frameworks used in prior works. Our construction is practical and also achieves the optimal leakage rate of 1 − o(1). Qin and Liu [35] n 2 (n 2 + n + 2) (n 2 + 2n) (n 2 + n) 2n 2 (2n 2 + n) NA NA NA Qin and Liu [36] (n 2 + n + 1) (3n + 2) Our construction: Our generic transformation from an LR-NIKE to an LR-IND-CCA-2-secure PKE scheme essentially follows and adapts the ideas of Freire et al. [19] in the setting of leakage. The main idea behind the transformation is as follows: the public-secret key pair of the LR-IND-CCA-2-secure PKE scheme is the same as the public-secret key pair of the underlying LR-NIKE protocol. While encrypting, another publicsecret key pair of the NIKE is sampled independently, and the shared key generation algorithm of the NIKE is run among the two key pairs yielding a shared key. This key is used as the encapsulation key of the underlying IND-CCA-2-secure key encapsulation mechanism (KEM), and the ciphertext is set to be the new sampled public key. Decryption is straightforward, and the decryptor can recover the same shared key by running the shared key generation algorithm with the original secret key and the new sampled public key. Now, from IND-CCA-2-KEM, one can easily get full-fledged IND-CCA-2-secure PKE using standard hybrid encryption techniques. Our transformation preserves the leakage rate in the sense that if the starting point of our construction is LR-NIKE with a leakage rate of 1 − o(1), then the LR-CCA-2-secure PKE constructed from it also enjoys the same leakage rate.
In Table 1, we show the comparison of our scheme with the state-of-the-art constructions of LR-IND-CCA secure PKE schemes in terms of both computational and communication complexity. We obtain these complexity figures by instantiating all of the compared schemes with the state-of-the-art constructions of the required underlying primitives. As we can see, the number of group elements involved in our ciphertext is much less than the number of group elements involved in the ciphertexts of the other schemes. With regard to the number of exponentiations and multiplication operations also, our scheme is more efficient compared to others, hence improving the computational complexity of the state-of-the-art LR-IND-CCA secure PKE schemes by a significant margin. Note that we do require a constant number of pairing operations (to be precise only 3) in the encryption side and also in the decryption side. According to Benhamouda et al. [7], pairing is roughly three times slower than computing an exponentiation. Therefore, each encryption and decryption cost is roughly nine times of an exponentiation. Since we can achieve the optimum leakage rate (albeit using a leakfree hardware assumption), this additional computation cost is reasonable. In the table, n ∈ ℕ is usually the number of generators required for the construction. Also, [36] works over composite order groups of the form = τ 1 × τ 2 . Here T c denotes the tag space in the encryption scheme of [36], and {0, 1} s denotes the seed space of a strong randomness extractor. Lastly, we want to stress that, although our scheme is more efficient than that of Qin et al. [35,36] in terms of computational cost and communication complexity and also achieves an optimal leakage rate, our scheme is not superior to them because of the use of a leak-free hardware component. The leak-free hardware is clearly a strong assumption.  Here B/C stands for either bounded or continuous memory leakage; BFL/AFL denotes the resilience of the AKE protocols to before-the-fact/after-the-fact leakage attacks. The shorthands DDH, HPS, CR, π-PRF and Ext stand for the decisional Diffie-Hellman problem, hash proof systems, collision-resistant hash function, pairwise-independent PRF families and strong extractors, respectively. CPLA-2 (resp. CCLA-2) secure PKE denotes an adaptively chosen plaintext (resp. ciphertext) after-the-fact leakage secure public-key cryptosystem. ε-PG-IND refers to the pair-generation indistinguishable PKE scheme; ODH and KDF refer to the oracle Diffie-Hellman and secure key derivation functions, respectively. BLR-CKS-heavy stands for bounded leakage-resilient "Cash-Kiltz-Shoup"-heavy model (BLR analogue of the CKS-heavy model).

Leakage-resilient AKE
We show how to obtain a generic construction of a leakage-resilient authenticated key exchange (LR-AKE) protocol starting from a leakage-resilient NIKE protocol. We formulate a new security model for LR-AKE protocols, which we call bounded-memory before-the-fact leakage eCK (BBFL-eCK) model. We then show a generic construction of BBFL-eCK-secure AKE protocol using LR-NIKE in the bounded-memory leakage setting.
Our model: Our security model for LR-AKE is a strong security model which addresses (bounded) leakage from the entire memory, which is stronger than the "only computation leaks information" axiom [30]. We present an eCK-style [28] security model, suitably adjusted to the leakage setting.
Our construction: We give the generic construction of leakage-resilient AKE from leakage-resilient NIKE in the bounded-memory leakage model. We adapt the construction of Bergsma et al. [8] to the setting of leakage. In particular, Bergsma et al. [8] showed a construction of AKE protocols from a standard NIKE protocol and an existentially unforgeable signature scheme. We replace the standard NIKE with our leakage-resilient NIKE and the existentially unforgeable signature scheme with a signature scheme that is existentially unforgeable under chosen message and leakage attacks [26]. We then show that the constructed AKE protocol is secure in our BBFL-eCK security model. The leakage rate of our construction is 1 − o(1) under an appropriate choice of parameters. We refer the reader to Table 2 for a more detailed comparison of leakage-resilient AKE protocols.

Leakage-resilient LLKE
We show an extremely important practical application of leakage-resilient NIKE protocols. We study the leakage resiliency of low-latency key exchange (LLKE) protocols. In this paper, we give a suitable leakage security model for LLKE protocols which we call the bounded-memory leakage LLKE-ma (BL-LLKE-ma) model, where "ma" stands for mutual authentication. We then present a generic construction of leakage-resilient LLKE (LR-LLKE) construction based on our LR-NIKE protocol in the bounded-memory leakage setting.
Our model: The security of (standard) LLKE protocols has been recently analyzed by Hale et al. [23] under mutual authentication of the client as well as the server. We give a leakage analogue of their security model. Our model allows the adversary to activate arbitrary protocol sessions between the clients and servers. Besides, the adversary can obtain the temporary or the main keys of a session of both the clients as well as the server, obtain the long-term secret key of clients and servers and also obtain bounded leakage from both the client and the server involved in the Test query. Finally, in the test query (satisfying some freshness/ validity conditions), the adversary has to guess the requested key from a random key.
Our construction: Adopting the construction of Hale et al. [23], we show a generic construction of leakageresilient LLKE protocol from a leakage-resilient NIKE protocol. In particular, we require an LR-NIKE scheme and a UF-CMLA secure signature scheme. Plugging them appropriately in our context, we obtain the construction of a leakage-resilient LLKE protocol. Moreover, the leakage rate enjoyed by our LLKE protocol is also optimal, i.e., 1 − o(1).

Alternative thought
It is possible to compare our LR-NIKE protocol (in the bounded-memory leakage model) with an alternative simpler construction, which is essentially an adaptation of the idea which we made explicit only for the LR-CCA-secure PKE scheme. Essentially, the idea is as follows: sample a random string r, and use a (seeded) randomness extractor to extract another the key generation function. The seed s of the extractor is stored in the leak-free hardware component. The intuition behind the security is that, since the leakage from r is bounded and the seed s is kept outside the view of the adversary, the extracted value r should look random to the adversary (the parameters need to be appropriately set to argue this). While we have made this explicit only for PKE, the above simple idea also works for achieving leakage resilience of NIKE protocols starting from any NIKE protocol in the CKS-heavy model. In fact, our construction of NIKE is exactly along this line: we start with the NIKE protocol of Freire et al. [19] and show the above NIKE protocol can be made (bounded) leakage-resilient by using the above trick. The reason we choose to give a concrete NIKE protocol is that the protocol of Freire et al. [19] is the only existing NIKE protocol secure in the CKS-heavy model (the base model we consider in our paper as well) in the standard model. Hence we start with the protocol of Freire et al. [19] and explicitly show the above idea to bootstrap its security in the bounded leakage setting.
For other primitives like AKE and LLKE, a similar idea works, and we can construct leakage-resilient versions of these primitives in a stand-alone manner using the above idea (given a leak-free hardware assumption). However, the focus of the paper is to present LR-NIKE as a unified paradigm for constructing other leakage-resilient primitives like PKE, AKE and LLKE. In particular, a construction of continuous leakageresilient NIKE will directly translate into a construction of continuous leakage-resilient PKE, AKE, LLKE via our transformations (which would otherwise not be possible using the above simpler transformations). Also, any improvement in the construction of NIKE will directly impact the efficiency of the corresponding PKE, AKE and LLKE schemes.

Notations
. . , a}. If x is a string, we denote |x| as the length of x. When x is chosen randomly from a set X, we write x $ ← X. When A is an algorithm, we write y $ ← A(x) to denote a run of A on input x and output y; if A is randomized, then y is a random variable and A(x; r) denotes a run of A on input x and randomness r. We denote the security parameter throughout by κ. An algorithm A is probabilistic polynomial-time (PPT) if A is randomized and, for any input x, r ∈ {0, 1} * , the computation of A(x; r) terminates in at most poly(|x|) steps. Let be a group of prime order p such that log 2 (p) ≥ κ. Let g be a generator of . Then, for a (column/row) vector C = (C 1 , . . . , C n ) ∈ ℤ n p , we denote by g C the vector C = (g C 1 , . . . , g C n ). Furthermore, for a vector D = (D 1 , . . . , D n ) ∈ ℤ n p , we denote by C D the group element We say two random variables X and Y are ε-close statistically if the statistical distance between them is at most ε, and this is denoted by X ≈ ε Y. On the other hand, if X and Y are computationally indistinguishable, we write X ≈ c Y. We refer to Appendix A.1 for the definitions of min-entropy, average conditional min-entropy, randomness extractors and basic results related to them.

Underlying primitives for our constructions
For our construction of NIKE in the bounded-memory leakage setting, we require a bounded leakage-resilient chameleon hash function (BLR-CHF). Leakage-resilient chameleon hash functions (LR-CHF) postulate that it is hard to find collisions, even when the adversary learns bounded leakage from the secret key/trapdoor. We refer the reader to Appendix A.2 for the formal definition of LR-CHF. We also need standard pseudo-random function (PRF) for this construction (please refer to Appendix A.3). A function F is an (ε prf , s prf , q prf )-secure PRF if no adversary of size s prf can distinguish F (instantiated with a random key) from a uniformly random function, except with negligible probability ε prf .
For our construction of leakage-resilient AKE and leakage-resilient LLKE protocols, we also need an existentially unforgeable signature secure against chosen message and leakage attacks (UF-CMLA). We refer the reader to Appendix A.4 for the formal definition. In all these definitions, the leakage functions can be arbitrarily and adaptively chosen by the adversary, with the only restriction that the output size of those functions are bounded by some leakage parameter.

Assumptions in a bilinear group
In this paper, we consider type-2 pairings over appropriate elliptic curve groups. Let G 2 be a type-2 pairing parameter generation algorithm. It takes as input the security parameter 1 κ and outputs such that p is a prime, ( 1 , 2 , T ) are a description of multiplicative cyclic groups of the same order p, g 1 , g 2 are generators of 1 and 2 , respectively, e : 1 × 2 → T is a non-degenerate efficiently computable bilinear map, ψ is an efficiently computable isomorphism ψ : 2 → 1 and g 1 = ψ(g 2 ).
Decisional bilinear assumption over type-2 pairings (DBDH-2): Let gk = ( 1 , 2 , T , g 1 , g 2 , p, e, ψ) be the output of the parameter generation algorithm G 2 as above. We consider the following version of the DBDH-2 problem introduced by Galindo [21] and also used in [19]. Formally, we say that the DBDH-2 assumption holds for type-2 pairings if the advantage of the adversary A DBDH-2 denoted by Adv dbdh-2 where the probability is taken over the random choices of the algorithm G 2 and the internal coin tosses of the algorithm A.

Leakage-resilient non-interactive key exchange
In this section, we present the syntax of leakage-resilient non-interactive key exchange (LR-NIKE) protocols. We denote by PK, SK and SHK the space of public keys, secret keys and shared keys of LR-NIKE, respectively. When we write pk i for the i-th public key, we mean that pk i is associated with the user with identifier ID i ∈ IDS, where IDS denotes the identity space⁴. Formally, an LR-NIKE scheme, LR-NIKE, consists of a tuple of algorithms (NIKEcommon_setup, NIKEgen, NIKEkey) with the functionalities specified below.
The setup algorithm takes as input the security parameter κ and the leakage bound λ(κ) that can be tolerated by the NIKE scheme and outputs a set of global parameters params of the system. We sometimes drop κ and write λ instead of λ(κ) when κ is clear from context. (ii) NIKEgen(1 κ , params): The key generation algorithm is probabilistic and can be executed independently by all the users. It takes as input the security parameter κ and params and outputs a public/secret key pair (pk, sk) ∈ PK × SK. (iii) NIKEkey(pk i , sk j ): The shared key generation algorithm takes the public key of user ID i , namely pk i , and the secret key of user ID j , namely sk j , and outputs a shared key shk ij ∈ SHK for the two keys or a failure symbol ⊥ if i = j, i.e., if sk j is the secret key corresponding to pk i . The correctness requirement states that, for any two pairs (pk i , sk i ) and (pk j , sk j ), the shared keys computed by them should be identical.

Bounded leakage-resilient non-interactive key exchange (BLR-CKS-heavy) security model
In this section, we present the formal security model for leakage-resilient non-interactive key exchange (LR-NIKE). Before defining our security model for LR-NIKE protocols, we present an impossibility result related to LR-NIKE protocols in Section 4.1.1. In particular, we show that if the leakage function is an arbitrary polynomial-time computable function having access to the public parameters, we cannot hope to construct a secure LR-NIKE protocol, even in the bounded memory leakage model. In Section 4.1.2, we show how to circumvent this impossibility result by enforcing some restrictions on the class of allowable leakage functions in our BLR-CKS-heavy security model for NIKE.

Impossibility of LR-NIKE protocols
In this section, we present an impossibility result of constructing the LR-NIKE protocol, even in the bounded leakage model. Then we suitably adapt our security model to circumvent this impossibility result. Let us assume that the NIKE protocol is run between two users, say, Alice and Bob. The key pairs of Alice and Bob are (pk A , sk A ) and (pk B , sk B ), respectively. In the leakage setting, the adversary may ask bounded leakage from the secret keys of both Alice and Bob. Note that the shared key between Alice and Bob is a deterministic function of their own secret keys and the public key of the other party, namely, for Alice (for Bob), the shared key shk AB is derived as NIKEkey(pk B , sk A ) (as NIKEkey(pk A , sk B )). Now the adversary can set the leakage function for Alice as L( ⋅ ) = L pk B ( ⋅ ) = NIKEkey(pk B , ⋅ ), i.e. the adversary can specify the leakage function as the shared key derivation function NIKEkey with the public key of the other party hard-coded in it. This allows the adversary to directly leak from the shared key shk AB established between Alice and Bob. If the adversary can leak sufficiently many bits of shk AB , then, with very high probability, the adversary can distinguish the shk AB from a random key.
The above attack demonstrates that if we allow the leakage function to be arbitrary polynomial-time computable functions with access to all the public parameters (and hence to the public keys of all the parties) of the system, it is impossible to have a secure instantiation of an LR-NIKE protocol. Hence we need to enforce some meaningful restrictions on the leakage functions. In particular, one may assume that the leakage functions are not allowed to access the public parameters of the system. This can be enforced by having the adversary specify the set of leakage functions before receiving the public parameters, the so-called "non-adaptive" leakage model. However, this is necessarily a much more restrictive model than the adaptive leakage model, where the leakage may depend on the parameters on the system. To circumvent the impossibility result in the adaptive leakage model, we incorporate some assumptions in our security model for LR-NIKE. In particular, we assume that every party participating in a NIKE protocol is equipped with a leakfree hardware component which can be used to store a very small part of their public key. The leakage function can access the public keys of all the parties, except the components stored in the leak-free hardware. This essentially provides a way to shield some part of the public key from the view of the adversary. The information that is stored in the leak-free hardware is implementation-specific. However, we stress that the leak-free hardware should be used in a minimal way in any LR-NIKE protocol⁵. Also, note that if we store the entire public key in the leak-free hardware, then our model is essentially equivalent to the non-adaptive leakage model. Hence our security model for LR-NIKE can be seen as a convex combination of the non-adaptive and adaptive leakage model, depending on the information that is stored in the leak-free hardware.
Lastly, we note that the above impossibility results do not carry forward to the setting of (interactive) AKE protocols. This is because the shared key between two parties in an AKE protocol does not only depend on the long-term keys of the parties, but also depends on the ephemeral secret and public keys. Hence, in this case, the leakage functions may be allowed to access the public keys of all the parties.

BLR-CKS-heavy security model for LR-NIKE
We model every party (including the adversary) as a probabilistic polynomial-time Turing machine (PPTM). In addition, we assume that all the legitimate parties involved in the protocol have access to an oracle tape, each per party. When required, the parties can enter into a query phase and can look up the response on its corresponding oracle tape. After obtaining the response, the parties can continue with the execution of the protocol.⁶ Moreover, we assume that the adversary cannot read the contents of the oracle tape. In reality, the oracle tape models the leak-free hardware device available to each party. Equipped with this, we next present our BLR-CKS-heavy model for NIKE.
Our security model of LR-NIKE can be seen as generalization of the CKS-heavy security model introduced by Freire et al. [19] to appropriately model key leakage attacks. We assume that the adversary is not allowed to register the same public key more than once. In practice, this can easily be ensured by requiring the certification authority (CA) to check for consistency whenever an individual attempt to register a public key in the system. So, in the leakage-free scenario, this setting was also considered in the work of Freire et al. [19], which they called the Simplified(S)-NIKE. Our model allows the adversary to register arbitrary public keys into the system, provided they are distinct from each other and from the public keys of the honestly registered parties. The adversary can also issue Extract queries to learn the private keys corresponding to the honestly generated public keys. The adversary can also learn the shared key between two honestly generated parties (via HonestReveal query) as long as both of them are not involved in the challenge/Test query. We also allow the adversary to learn the shared key between an honest party and a corrupt party (via CorruptReveal query). Apart from the above queries, the BLR-CKS-heavy model allows the adversary to obtain a bounded amount of leakage of the secret/private keys of the parties. Finally, in the Test query, the adversary has to distinguish the real shared key between two honest parties from a random shared key. To prevent trivial wins, we enforce some natural restrictions on the Test query which we call the validity conditions. We also note that, once the test query is asked by the adversary, he is not allowed to make further leakage queries on the corresponding parties involved in the test query (modeling before-the-fact leakage).

Remark 4.1 (Extract query vs. Leakage queries).
By issuing the Extract query, the adversary can learn the secret key of a party entirely. Separately, by issuing leakage queries the adversary gets a bounded amount of leakage from the secret key. It may seem paradoxical to consider both Extract as well as Leakage queries at the same time. However, there are good reasons to consider both.
A non-leakage version of the BLR-CKS-heavy model allows the adversary to corrupt the honest parties to obtain the corresponding secret keys. However, it disallows the adversary to corrupt any of the parties involved in the Test query. This is a natural restriction since corrupting any of the parties involved in the test session will also allow the adversary to reconstruct the shared key of the test session and hence win 12 | S. Chakraborty et al., New approach to practical leakage-resilient PKC the security game with certainty. But note that, in our BLR-CKS-heavy model, the adversary can also obtain bounded leakage from the secret keys of the parties involved in the test session in addition to corrupting other (non-test) honest parties in the system. Hence the BLR-CKS-heavy model allows the adversary to obtain more information than a non-leakage version of BLR-CKS-heavy model, namely the CKS-heavy model [19], and hence is necessarily stronger than the CKS-heavy model.

Adversarial powers
Our BLR-CKS-heavy security model is stated in terms of a security game between a challenger C and an adversary A. The adversary A is modeled as a PPTM algorithm. We denote by Π U,V the protocol run between principal U, with intended principal V. Initially, the challenger C runs the NIKEcommon_setup algorithm to output the set of public parameters params, and gives params to A. The challenger C also chooses a random bit b in the beginning of the security game and answers all the legitimate queries of A until A outputs a bit b . The adversary A is allowed to ask the following queries. (i) RegisterHonest(1 κ , params): This query allows the adversary to register honest parties in the system.
The challenger runs the NIKEgen algorithm to generate a key pair (pk U , sk U ) and records the tuple (honest, pk U , sk U ). It then returns the public key pk U to A. We refer to the parties registered via this query as honest parties. (ii) RegisterCorrupt(pk U ): This query allows the adversary to register arbitrary corrupt parties in the system.
Here A supplies a public key pk U . The challenger records the tuple (corrupt, pk U , ⊥). We demand that all the public keys involved in this query are distinct from one another and from the honestly generated public keys from above. The parties registered via this query are referred to as corrupt. (iii) Extract(pk U ): In this query, the adversary A supplies the public key pk U of an honest party. The challenger looks up the corresponding tuple (honest, pk U , sk U ) and returns the secret key sk U to A. (iv) Reveal(pk U , pk V ): This query can be categorized into two types -HonestReveal and CorruptReveal queries. Here the adversary supplies a pair of public keys pk U and pk V . In the HonestReveal query, both pk U and pk V are honestly registered, i.e., both of them correspond to honest parties; whereas in the CorruptReveal query, one of the public keys is registered as honest while the other is registered as corrupt. The challenger runs the NIKEkey algorithm using the secret key of the honest party (in case of the HonestReveal query, using the secret key of any one of the parties) and the public key of the other party, and returns the result to A. (v) Leakage: In the BLR-CKS-heavy security model, the total amount of leakage from the secret key of the underlying cryptographic primitives is bounded by the leakage parameter λ = λ(κ). Here the adversary A supplies the description of an arbitrary polynomial-time computable function f i ∈ F and a public key pk.
The challenger computes f i (sk), where sk is the secret key corresponding to pk, and returns the output to A. The class F = {f i } i of leakage functions is defined as Secondly, the functions f i cannot take as input the values f(pk), where the value f(pk) is stored in a leakfree hardware component, and f is a function of the public key pk.⁷ The adversary A can specify multiple such leakage functions as long as the leakage bound is not violated, i.e., ∑ i |f i (sk)| ≤ λ(κ), and f i ∈ F. Note that A can obtain λ bits of information/leakage from the secret key from each of the honest parties, including those involved in the Test queries. (vi) Test(pk U , pk V ): Here A supplies two distinct public keys pk U and pk V that were both registered as honest.
If pk U = pk V , the challenger aborts and returns ⊥. Otherwise, it uses the bit b to answer the query. If b = 0, the challenger runs the NIKEkey algorithm using the public key of one party, say pk U , and the private key of the other party sk V and returns the result to A. If b = 1, the challenger samples a random shared key from SHK and returns that to A.
A's queries may be made adaptively and are arbitrary in number. However, to prevent trivial wins, the adversary should not be allowed to make certain queries to the parties involved in the Test query. We model this by requiring the Test query to be valid. We next give the definition of validity in our BLR-CKS-heavy model (see Definition 4.2).

Definition 4.2 (λ-BLR-CKS-heavy validity).
We say that the Test query Π U,V between two parties U and V with public-secret key pairs (pk U , sk U ) and (pk V , sk V ), respectively, is valid in the BLR-CKS-heavy model if the following conditions hold.
(i) The adversary A is not allowed to ask Extract(pk U ) or Extract(pk V ) queries.
(ii) The adversary A is not allowed to ask HonestReveal(pk U , pk V ) or HonestReveal(pk V , pk U ) queries.
(iii) The total output length of all the leakage queries by A to each party involved in the Test query, i.e., U and V, is at most λ(κ), i.e., ∑ i |f i (sk U )| ≤ λ(κ) and ∑ i |f i (sk V )| ≤ λ(κ), and we require that f i ∈ F, where F is as defined above.  Let q H , q C , q E , q HR and q CR denote the number of RegisterHonest, RegisterCorrupt, Extract, HonestReveal and CorruptReveal queries, respectively. A NIKE protocol Π is said to be BLR-CKS-heavy secure if there is no PPT algorithm A that can win the above BLR-CKS-heavy security game with non-negligible advantage. The advantage of an adversary A is defined as

Security game and security definition
Remark 4.5. We remark that our BLR-CKS-heavy security model for NIKE can be generalized in a straightforward manner to incorporate continuous memory leakage (CML) attacks. However, we do not give our security model for NIKE in the CML setting since we mainly focus on the construction of BLR-NIKE in this work. We note that a recent work [10] already solved the open problem of constructing LR-NIKE in the CML setting. However, they assume additional restrictions on the leakage model, namely a split-state model (where the secret key is split into multiple parts and it is assumed that the adversary can leak from both these parts, but in an independent manner) and also does not achieve the optimal leakage rate (i. e. 1 − o(1)). We leave the construction of LR-NIKE in the CML setting in the non-split state model achieving optimal leakage rate as an exciting open problem.

Constructions of leakage-resilient non-interactive key exchange
In this section, we show our construction of leakage-resilient NIKE in the bounded-memory leakage model. We show that the pairing-based NIKE protocol of Freire et al. [19] (in the standard model), which is secure in the non-leakage setting, is in fact insecure in the bounded memory leakage model, even if the adversary obtains a single bit of leakage on the secret key of the parties. This is illustrated in Appendix C. Table 3 shows our construction of NIKE in the bounded-memory leakage model. The starting point of our construction is the NIKE protocol of [19]. Let G 2 be a type-2 pairing parameter generation algorithm, i.e., it outputs gk = ( 1 , 2 , T , g 1 , g 2 , p, e, ψ). Let ChamH hk : {0, 1} * × R cham → ℤ p be a (bounded) leakageresilient chameleon hash function tolerating leakage bound up to λ(κ) (denoted as λ-LR-CHF) indexed with the evaluation/hashing key hk, and R cham denotes the randomness space of the hash function. Also, let

Protocol BLR-NIKE: Construction of NIKE in the bounded-memory leakage model
and (ε prf , s prf , q prf ) secure PRF families, and let Ext : ℤ p × {0, 1} s → {0, 1} ℓ(κ) be an average-case (v, ε)-extractor, with v ≪ log p and s = ω(log κ). Namely, it has log p bits of input, ω(log κ)-bit seed s and ℓ(κ)-bit outputs, and for a random seed and input with v bits of min-entropy, the output is ε-away from a uniform ℓ(κ)-bit string. We can set the parameters appropriately to achieve this.
Setting the parameters of the extractor: For our construction, the seed s of the extractor Ext is stored in the leak-free hardware component. If the length of the seed s is O(log κ), the adversary can enumerate over the entire seed space itself, and the adversary can simply ask for leakage functions on the private key with enumeration of all possible seeds. This necessitates the length of s to be at least ω(log κ). The classical result of [34] shows that, for every n, k, ε, there exist (k, ε)-extractors that use a seed of length d = log(n − k) + 2 log( 1 ε ) + O(1) and output m = k + d − 2 log( 1 ε ) bits. In our construction, n = log p (since the input of Ext is from ℤ p ), k = n − λ = log p − λ (since a leakage of λ bits can reduce the entropy of the source by at most λ bits). Hence the seed is of the length s = log(λ) + 2 log( 1 ε ) + O (1). By appropriately setting the value of p, λ and ε, one can show that s ≥ ω(log κ).
On the leak-free hardware assumption: As already stated in Section 4.1.2, we consider an additional assumption that each party involved in our LR-NIKE protocol has access to a leak-free secure hardware component. In our LR-NIKE construction, each party needs to store a short random seed (which is part of the public key of that party) corresponding to every other party with whom a shared key will be established. The above assumption seems to be necessary for our protocol since, otherwise, the adversary could leak from the extracted value itself by knowing the seed. However, as discussed in Section 4.1.1, the leak-free hardware assumption seems to be necessary for the construction for any secure LR-NIKE protocol, unless one sacrifices the leakage model further (non-adaptive leakage). Theorem 4.6. Let ChamH hk be a family of bounded leakage-resilient chameleon hash function (BLR-CHF). Let F and F be (ε prf , s prf , q prf ) and (ε prf , s prf , q prf ) secure PRFs. Let Ext be a (v, ε)-strong average case randomness extractor with seed length at least ω(log κ), and let p be the order of the underlying groups 1 , 2 and T . Then the above NIKE protocol BLR-NIKE is BLR-CKS-heavy-secure assuming the intractability of the DBDH-2 assumption with respect to the parameter generator G 2 . In particular, let A be an adversary against the NIKE protocol BLR-NIKE in the BLR-CKS-heavy security model making q H the number of RegisterHonest user queries. Then, using it, we can construct an adversary A DBDH-2 against the DBDH-2 problem such that Proof. The proof of this theorem will proceed via the game hopping technique [38]: define a sequence of games, and relate the adversary's advantage of distinguishing each game from the previous game to the advantage of breaking one of the underlying cryptographic primitives. Let Adv δ (A) denote the advantage of the adversary A in Game δ. Game 2. This game is identical to the previous game, except that the challenger changes the way how the output of the extractor is computed. In particular, instead of computingx the challenger chooses a uniformly randomx A ,x B ← {0, 1} ℓ(κ) . Game 0 and Game 1 are indistinguishable by the property of the strong average case randomness extractor. Suppose that the adversary obtains at most λ = λ(κ) bits of leakage from the secret keys x A and x B of parties A and B, respectively. Since Ext can work with inputs that have min-entropy v ≪ log p, even given the bounded leakage of λ bits, we have where U ℓ(κ) denotes the uniform distribution over {0, 1} ℓ(κ) . Recall that, in our construction, the seeds s A and s B are stored in the leak-free hardware component (i.e., s A and s B are stored in the oracle tape of party ID A and ID B , respectively), and hence are outside the view of the adversary. Thus it is possible to replace the output the extractor with a uniformly random value in this game. This is the only place where we require the leak-free assumption in our proof. |Adv Game 2 (A) − Adv Game 1 (A)| ≤ 2ε.
Game 3. This game is identical to the previous game, except that the challenger changes the way how the PRFs are computed. In particular, instead of computing where RF is random function with the same range as F. If A can distinguish the difference between Game 2 and Game 3, then A can be used as a subroutine to construct a distinguisher D between the PRF F : {0, 1} ℓ(κ) × ℤ p → ℤ p and a random function RF. |Adv Game 3 (A) − Adv Game 2 (A)| ≤ ε prf + ε prf .
Game 4. This game is identical to the previous game, except that the challenger now samples x A and x B randomly. In particular, instead of computing Note that x A and x B are identically distributed in both Game 3 and Game 4, and hence both these games are identical from the view of an adversary.

Adv Game 4 (A) = Adv Game 3 (A).
Game 5. In this game, the challenger changes the way in which it answers RegisterCorrupt queries. In particular, let ID A and ID B be identities of two honest parties involved in the Test query with public keys (X A , Z A , r A , r A , s A ) and (X B , Z B , r B , r B , s B ), respectively. Let ID D be the identity of the party with public key (X D , Z D , r D , r D ) that is subject to a RegisterCorrupt query. If the challenger aborts. Note that if the above happens, then the challenger has successfully found a collision of the chameleon hash function. By the difference lemma [37], we have |Adv Game 5 (A) − Adv Game 4 (A)| ≤ Adv coll A,ChamH (κ). Game 6. In this game, the DBDH-2 adversary A DBDH-2 receives as input (g 2 , g a 2 , g b 2 , g c 1 , T), and its objective is to determine if T = e(g 1 , g 2 ) sbc or a random element from T , where g 1 and g 2 are generators of the group 1 and 2 , respectively, and a, b, c are random elements from ℤ p . We now describe how A DBDH-2 sets up the environment for A NIKE and simulates all its queries properly.
Let us define a polynomial p(t) = p 0 + p 1 t + p 2 t 2 of degree 2 over ℤ p such that t A and t B are the roots of p(t), i.e., p(t A ) = 0 and p(t B ) = 0. Also, let q(t) = q 0 + q 1 t + q 2 t 2 be a random polynomial of degree 2 over ℤ p . Then A DBDH-2 sets α = (g c 1 ) p 0 g q 0 1 , β = (g c 1 ) p 1 g q 1 1 , γ = (g c 1 ) p 2 g q 2 1 and δ = g c 1 (g c 1 was obtained as input of the hard problem instance). Note that, since p i , q i ← ℤ p are randomly chosen, the values of α, β and γ are also random. Also, note that αβ t γ t 2 = (g 1 ) p 1 (t) g q(t) Then A DBDH-2 simulates all the queries of A NIKE as follows. uses the trapdoor ck of the chameleon hash to produce r A ∈ R cham such that Cham.Eval(g a 2 ‖ID A ; r A ) = Cham.Eval(m 1 ; r 1 ). Note that, by the random trapdoor collision property of the chameleon hash function, r A is uniformly distributed over R cham and also independent of r 1 . Similarly, when ID = ID B , A DBDH-2 uses the trapdoor ck to produce r B ∈ R cham such that Cham.Eval(g b 2 ‖ID B ; r B ) = Cham.Eval(m 2 ; r 2 ). The value r B is also uniformly distributed over R cham and also independent of r 2 . A DBDH-2 then sets pk A = (ψ(g a 2 ) q(t A ) , g a 2 , r A , r A ) and pk B = (ψ(g b 2 ) q(t B ) , g B 2 , r B , r B ), where r A , r B ← ℤ p . Note that these are correct public keys since p(t A ) = p(t B ) = 0.
• RegisterCorrupt: Here A DBDH-2 receives as input a public key pk and an identity string ID from A NIKE . If to produce the shared key shk ID,ID . Note that A DBDH-2 can do this since it knows the secret key sk ID of the party ID . Then A DBDH-2 gives shk ID,ID to A NIKE .
Here the challenger A DBDH-2 runs NIKE.key(pk ID , sk ID ) to produce the shared key shk ID,ID . Note that A DBDH-2 can do this since it knows the secret key sk ID of the party ID . Then A DBDH-2 gives shk ID,ID to A NIKE .
In this case, the challenger A DBDH-2 runs NIKE.key(pk ID , sk ID ) (it can use sk ID also) to produce the shared key shk ID,ID . Then A DBDH-2 gives shk ID,ID to A NIKE . • CorruptReveal: When A NIKE supplies two identities ID and ID , where ID was registered as corrupt and ID was registered as honest, .key(pk ID , sk ID ) to obtain shk ID,ID and returns it to A NIKE . However, if ID ∈ {ID A , ID B }, A DBDH-2 checks whether the public key pk ID equals (X ID , Z ID , r ID , r ID ) by checking the pairing. This makes sure that pk ID is of the form . From this the value, g cd 1 can be computed as Note that the value 1/p(t ID ) is well defined since p(t ID ) ̸ = 0 mod p. Also, note that t ID ̸ = t A , t B since we have already eliminated the hash collisions. Assume w.l.o.g. that ID = ID A . So, writing the public key of ID A as (Y A , Z A , r A , r A ), the shared key between ID A and ID is given by shk ID A ,ID = e(g cd 1 , Z A ). • Leakage queries: The adversary A NIKE may specify arbitrary polynomial-time computable functions f i to leak from the secret keys x A and x B . The challenger A DBDH-2 forwards the functions f i to its leakage oracle and forwards the answers to A NIKE . • Test query: Here A DBDH-2 returns T.
This completes the description of simulation by A DBDH-2 . If A NIKE can distinguish between real and random key in Game 4, then this is equivalent to solving the DBDH-2 problem. To see this, note that, for user ID A , we have Z A = g a 2 and X A = ψ(Z A ) q(t A ) , and for user ID B , we have Z B = g b 2 and X B = ψ(Z B ) q(t B ) . Hence shk ID A ,ID B = e((g c 1 ) b , Z A ) = e((g c 1 ) a , Z B ) = e(g 1 , g 2 ) abc . Since the simulation done by A DBDH-2 is perfect, we have Adv Game 6 (A) = Adv Game 5 (A).
Game 7. In this game, the challenger A DBDH-2 chooses T randomly from the target group T . Since T is now completely independent of the challenge bit, we have Pr(Succ Game6 ) = 1 2 . Game 5 and Game 6 are identical unless adversary A DBDH-2 can distinguish e(g 1 , g 2 ) abc from a random element. So we have By combining all the above expression from Game 0 to Game 7, we have the following. We use G i to denote Game i . Adv BLR-CKS-heavy

Thus we have
Adv BLR-CKS-heavy

Leakage tolerance of protocol BLR-NIKE
The order of the groups 1 , 2 and T is p. Note that, although the secret key in our protocol BLR-NIKE may appear to be a single field element, in the actual instantiation of the protocol, the secret key is a tuple of n + 1 field elements. This is because the secret key of the concrete instantiation of BLR-CHF of Wang and Tanaka [39] consists of n field elements which also corresponds to the number of generators in the construction of [39]. The leakage tolerance of BLR-CHF is λ = ((n − 1) log(p) − ω(log κ)) as shown in [39]. The size of the secret key of the BLR-CHF is L = n log p. So, for sufficiently large n, the leakage rate η = λ L of BLR-CHF approaches 1 − o (1). We also consider a very good randomness extractor that can work with inputs that have min-entropy v ≪ log p and produces outputs whose distance from uniform ℓ(κ)-bit strings is ε < 2 −ℓ(κ) . The size of the secret key x A (respectively x B ) of our NIKE construction is log p (apart from the size of the secret key of λ -LR-CHF, i.e., n log p). So the leakage tolerated from x A (respectively x B ) is at least log p − v ≈ log p. Hence the overall leakage tolerated by our construction is λ ≈ ((n − 1) log(p) − ω(log κ)) + log p ≈ n log(p) − ω(log κ). The overall size of the secret key of our construction is L = (n + 1) log p. So the overall leakage rate of our construction is η = λ L = 1 − o(1) for sufficiently large n.

Constructions of various cryptographic primitives from leakage-resilient NIKE
Now we show many potential applications of leakage-resilient NIKE.

Leakage-resilient adaptive chosen ciphertext secure PKE
We now present our construction of an LR-IND-CCA-2-secure PKE scheme from a BLR-CKS-heavy-secure LR-NIKE scheme. Actually, we show how to construct an LR-IND-CCA-2-secure key encapsulation mechanism (KEM) given such a NIKE. Before proceeding with the construction, we give the LR-IND-CCA-2 security model for KEMs.

Leakage-resilient chosen-ciphertext security for KEM
We then return 1, else return 0
Then it runs NIKEkey(pk, sk ) to produce the shared key shk. It then sets the encapsulated key K = shk and the ciphertext C = pk . (iv) KEM.Decap(sk KEM , C): This algorithm parses the ciphertext C as pk and the secret key sk KEM as sk. It then runs NIKEkey(pk , sk) and obtains the result.  Table 4.

Generic construction of leakage-resilient KEM
We Proof. Let A KEM be an adversary against the BLR-IND-CCA-2-secure KEM Γ. We now show how to use A KEM to construct another adversary A NIKE against LR-NIKE, thereby contradicting its BLR-CKS-heavy security. A NIKE simulates the environment to A KEM in the following way.
• KEM.Setup: On input of the public parameters params, A NIKE sets the public parameters pub of the KEM scheme as params.
• KEM.Gen: A NIKE makes two RegisterHonest queries, receiving as input two honestly registered public keys pk 1 and pk 2 . It then sets pk KEM = pk 1 and sk KEM = ⊥. • KEM.Encap(pk): To simulate the challenge phase, A NIKE makes a Test(pk 1 , pk 2 ) query. It receives as reply a shared key K which is either the real key, i.e., K = NIKE.key(pk 1 , sk 2 ), or a random shared K ← SHK. It then sets the encapsulated key K * = K and C * = pk 2 .
• Leakage queries: When A KEM queries with leakage functions f , the challenger A NIKE forwards f to the leakage oracle O λ sk 1 ( ⋅ ) and receives as response f(sk 1 ). It then returns f(sk 1 ) to A KEM . • Decapsulation queries: A KEM makes decapsulation queries to A NIKE with ciphertexts C. A NIKE parses C as pk , and since C ̸ = C * , we have pk ̸ = pk 2 . If pk = pk 1 , A NIKE outputs ⊥. This is consistent with the rejection rule of the KEM Γ and also LR-NIKE. Else, A NIKE makes a RegisterCorrupt query on pk . Here we assume that all of A KEM 's decapsulation queries are distinct without loss of generality, and hence all of the RegisterHonest queries are distinct. A NIKE then makes a CorruptReveal(pk 1 , pk ) query to get a shared key K ∈ SHK or a symbol ⊥. It then returns K to A KEM . This completes the description of A NIKE 's simulation. From the description, it is clear that the above simulation is perfect. Note that if K * is the real shared key, i.e., it is the output of the NIKE.key algorithm, then it is properly simulating the Encap algorithm in the Exp BLR-IND-CCA-2 Γ,A (κ, λ) security experiment; else if K * is chosen randomly, it also properly simulates the fact that it is chosen randomly in the experiment. Finally, when A KEM outputs a bit b as its guess for b in the experiment, A NIKE also outputs the same bit b . So the advantage of A NIKE in breaking the BLR-CKS-heavy security of LR-NIKE is exactly the same as the advantage of A KEM in breaking the BLR-IND-CCA-2 security of the KEM scheme Γ. Also note that the number of Register-Corrupt and CorruptReveal queries made by A NIKE is the same as the number of decapsulation queries asked by A KEM . This completes the proof of the above theorem.  Ext(r , s), where s is the random seed of the extractor Ext. Store the seed s in the leak-free hardware component. Then run pk = Gen(1 κ , r) to obtain the public key pk. Set the secret key sk = r . The above scheme Γ achieves BLR-IND-CCA-2 security as long as the string r is sufficiently long and the seed s is kept out of the view of the adversary. The encapsulation and the decapsulation functions remain unchanged from the underlying KEM scheme π. Although this simple solution works, we stress the objective of our work is to show the applications of LR-NIKE as a central unifying to construct many leakage-resilient primitives. We thank an anonymous reviewer of the journal Design, Codes and Cryptography for suggesting the above construction.

Leakage-resilient authenticated key exchange
The work of Bergsma et al. [8] shows a generic construction of an eCK-secure AKE protocol using an UF-CMA-secure signature scheme, CKS-light-secure NIKE scheme and a pseudo-random function as underlying primitives.
In this paper, we present a construction of a leakage-resilient NIKE protocol, which is secure in the CKS-heavy model, under bounded-memory leakage, i.e. BLR-CKS-heavy-secure NIKE protocol (Table 3). Since the CKS-heavy security implies the CKS-light security, our leakage-resilient NIKE protocol can work as a bounded-memory leakage-resilient CKS-light-secure NIKE protocol. Further, in the literature, we can find UF-CMLA-secure signature schemes [26], which are UF-CMA-secure signature schemes under the bounded-memory leakage model. Thus we have the necessary primitives to transform our leakage-resilient NIKE to a leakage-resilient AKE following the NIKE to AKE transformation of Bergsma et al. [8] in the bounded-memory leakage model.
There are numerous leakage versions of the eCK model, under the OCLI axiom [3][4][5] and the memory leakage model [11]. Further, they address after-the-fact leakage. With our new BLR-CKS-heavy-secure NIKE protocol, following the Bergsma et al. [8] transformation, we can achieve leakage-resilient AKE in an eCKstyle model • under memory leakage (stronger than the OCLI axiom), • addressing before-the-fact leakage (weaker than after-the-fact leakage).

Bounded-memory before-the-fact leakage eCK model
We present a suitable security model to analyze the leakage resiliency of AKE protocols, considering the aforementioned points, i.e., in an eCK-style security model [28], addressing before-the-fact, bounded-memory leakage.
Let κ be the security parameter. Let U = {U 1 , . . . , U n } be a set of n parties. We use the term principal to identify a party involved in a protocol instance. Each party U i , where i ∈ [1, N P ], has a pair of long-term public and secret keys, (pk U i , sk U i ). The term session is used to identify a protocol instance at a principal. Each principal may have multiple sessions, and they may run concurrently. The oracle Π s U,V represents the s-th session at the owner principal U, with intended partner principal V. The principal which sends the first protocol message of a session is the initiator of the session, and the principal which responds to the first protocol message is the responder of the session. (v) exactly one of U and V is the initiator, and the other is the responder. The protocol is said to be correct if two partner oracles compute identical session keys.

Modeling leakage:
We consider the bounded-memory leakage setting for modeling the leakage. As before, the adversary is allowed to issue arbitrary efficiently computable leakage functions f i and obtain the leakage f i (sk) of the secret key sk, before the session key is established. As mentioned above, the constraint is ∑ i=1 |f i (sk)| ≤ λ, where λ is the leakage parameter.

Adversarial powers:
• Send(U, V, s, m) query: The oracle Π s U,V computes the next protocol message according to the protocol specification and sends it to the adversary. A can also use this query to activate a new protocol instance with blank m.
(v) after Π s U,V is activated, no leakage is allowed from U and V.

Definition 5.4 (BBFL-eCK security).
A protocol π is said to be BBFL-eCK-secure if there is no PPT adversary A that can win the BBFL-eCK security game with non-negligible advantage. The advantage of an adversary A is defined as Adv BBFL-eCK π,A (κ) = |2 Pr(Succ A ) − 1|.

Constructing BBFL-eCK-secure key exchange protocols
In Table 5, we show the generic leakage-resilient variant of the Bergsma et al. [8] AKE protocol. We replace the CKS-light-secure NIKE with a BLR-CKS-heavy-secure NIKE, and the UF-CMA-secure signature scheme with a UF-CMLA-secure signature scheme in the bounded-memory leakage model, to come up with the generic BBFL-eCK-secure AKE protocol. In this protocol, the final shared key is obtained by xor-ing the intermediate keys. Since the adversary learns the leakage only from the long-term secret parameters, it is not necessary to use leakage-resilient PRFs for the construction of LR-AKE, following NIKE to AKE transformation of Bergsma et al.
Let LR-NIKE = (NIKEcommon_setup, NIKEgen, NIKEkey) be the underlying BLR-CKS-heavy-secure NIKE protocol. Let LR-SIG = (SIGkg, SIGsign, SIGvfy) be the underlying UF-CMLA-secure signature scheme, and let PRF be a secure pseudo-random function. Since the generic construction of the AKE protocol remains unchanged with respect to Bergsma et al. [8], except the replacement of the leakage-resilient advancements of the underlying primitives, in the bounded-memory leakage setting, the security of the resulting AKE still preserves the eCK-style with the advancements of leakage resiliency in the bounded-memory leakage setting. Therefore, the security theorem and the flow of the security proof is similar to [8, Appendix A, Theorem 1] and its proof. Proof sketch. To prove Theorem 5.5, we need to consider four types of attackers.
• An A1-type attacker never asks the EphemeralKeyReveal query for the test session. If there exists a partner to the test session, it will also never ask the EphemeralKeyReveal query for the partner session. • An A2-type attacker never asks the EphemeralKeyReveal query for the test session. If there exists a partner to the test session, it also never asks the Corrupt query for the owner of the partner session.
• An A3-type attacker never asks the Corrupt query to the owner of the test session. If there exists a partner to the test session, it also never asks the EphemeralKeyReveal query to the partner session.
• An A4-type attacker never asks the Corrupt query to the owner of the test session. If there exists a partner to the test session, it also never asks the Corrupt query to the owner of the partner session. Each legitimate attacker according to the freshness definition falls into at least on of these categories.
In the LR-AKE protocol, the session key is computed as The main intuition behind this construction is that we need to reduce the indistinguishability of the shared key of LR-AKE to the indistinguishability of LR-NIKE. In this simulation, we can easily simulate the leakage by giving the adversary A the leakage obtained from the underlying leakage-resilient NIKE challenger and the signature scheme challenger. In the security experiment against the leakage-resilient NIKE, the NIKEadversary gets two challenge public keys from the leakage-resilient NIKE challenger. In the reduction, we need to embed them into the view of the adversary A, in a way that we can embed the leakage-resilient NIKEchallenge key into k while successfully answering all the legitimate Corrupt and EphemeralKeyReveal queries. An A1-type attacker never asks EphemeralKeyReveal queries to the test session and the partner to the test session. Thus it is possible to embed the public keys from the leakage-resilient NIKE challenger as the ephemeral public keys of the test session. Then use the challenge key from the leakage-resilient NIKE challenger as k tmp,tmp .
For the case of an A2-type attacker, embed the public keys from the leakage-resilient NIKE challenger, one as the ephemeral public key and the other one as the long-term public key of the test session. Then use the challenge key as k tmp,nike . Since this embedding involves a long-term secret of one party of the test session, we need to use an additional PRF, and this long-term secret is used in many protocol executions involving the corresponding party. Similarly, A3 and A4-type attackers can be handled by embedding the leakage-resilient NIKE challenger's public and challenge keys accordingly.
Thus the four attackers correspond to all possible combinations of Corrupt and EphemeralKeyReveal queries that are allowed in our BBFL-eCK security model. Remark 5.6. Our construction of an BBFL-eCK secure AKE protocol is obtained by replacing the building blocks (i.e., NIKE and one-time signature schemes) in Bergsma et al.'s framework [8] with a (bounded) leakage-resilient NIKE and a (bounded) leakage-resilient signature scheme. However, such a straightforward replacement of the underlying primitives with their corresponding leakage-resilient counterparts may encounter a subtle technical problem: the adversary can use the leakage oracle to break the authentication mechanism in the "test" session (which corresponds to breaking the UF-CMLA security of the signature scheme), or it can encode the (description of the) session key derivation function in the leakage function to leak from the session key. However, it is to be noted that, in our BBFL-eCK security model, the adversary is not allowed to query the leakage oracle during or after the test session. This is because we consider the setting of "before-the-fact" leakage in our current work. Hence the above impossibility result can be avoided in our setting.

Leakage tolerance of the generic LR-AKE protocol
This generic protocol can tolerate the leakage according to the leakage tolerance of the underlying leakageresilient NIKE and the leakage-resilient signature scheme. Our LR-NIKE can tolerate 1 − o(1) leakage, and the UF-CMLA signature scheme of Katz et al. [26] can tolerate n − n ε leakage, for an n-bit key and 1 > ε > 0, which approaches 1 − o(1) leakage rate for sufficiently large n and small enough ε. Thus the corresponding instantiation can tolerate an overall leakage rate of 1 − o(1).

Leakage-resilient low-latency key exchange
Low-latency key exchange (LLKE) can be considered as one of the important practical usages of NIKE protocols, which permits the transmission of cryptographically protected data, without prior key exchange, while providing perfect forward secrecy (PFS). Leakage resiliency of LLKE remains unstudied.

Bounded-memory leakage LLKE-ma model
We refer to the security model under mutual authentication of Hale et al. [23,Section 5] as LLKE-ma model. In this work, we introduce a bounded-memory leakage model on top of the LLKE-ma model (we use the notation BL-LLKE-ma to identify our model whenever necessary).
Let d be the number of clients and ℓ the number of servers. Each client is represented by a collection of n oracles C i,1 , . . . , C i,n , and each server is represented by a collection of k oracles S j,1 , . . . , S j,k . Each oracle represents an instance of the protocol. Each principal has a long-term key pair (sk i , pk i ). Let κ be the security parameter and λ the leakage parameter. Each oracle

Adversarial powers:
• Send(C i,s /S j,t , m): The adversary sends the message m to the requested oracle, the oracle processes m according to the protocol specification, and the response is returned to the adversary. • Reveal(C i,s /S j,t , tmp/main): This query returns the key of the given stage if it has been already computed, or ⊥ otherwise.
• Corrupt(i/j): This query returns the long-term secret key of the server or the client accordingly. If Corrupt(j/i) is the τ-th query issued by the adversary, we say a party is τ-corrupted. For the parties that are not corrupted, we define τ := ∞.
• Test(C i,s /S j,t , tmp/main): This query is used to test a key. If the variable for the requested key is not empty, the challenger chooses b $ ← {0, 1}, and if b = 0, then the requested key is returned, else a random key is returned. Otherwise, ⊥ is returned.
BL-LLKE-ma security game: The adversary interacts with the challenger by issuing any combination of Send(), Corrupt(), Reveal() and Leak() queries. At some point, the adversary issues a Test() query to an oracle that holds the conditions in Definition 5.7. Then the adversary may continue asking the Send(), Corrupt(), Reveal() and Leak() queries, without violating the conditions of Definition 5.7, and finally outputs answer bit b for the challenge. A wins if b = b. Let Succ A denote the event that the adversary A wins the above security game. Definition 5.7 (Leakage-resilient key security (under mutual authentication)). A protocol π is said to be BL-LLKE-ma-secure if there is no PPT adversary A that can win the BL-LLKE-ma security game with non-negligible advantage, while holding the following conditions.
• Before activation of the test session on C i , for all Leakage(i, f i ) queries, ∑ i=1 |f i (sk i )| ≤ λ, and before activation of the test session on S j , for all Leakage(j, f i ) queries, ∑ i=1 |f i (sk j )| ≤ λ.
• After activation of the Test session on C i , no leakage is allowed from sk i (same as to the case of S j ).

Generic construction of BL-LLKE-ma-secure LLKE from NIKE
In the work of Hale et al., they have used a CKS-light-secure NIKE scheme NIKE and a UF-CMA-secure signature scheme SIG. We simply replace those primitives with their respective leakage-resilient versions.
Let LR-NIKE = (NIKEcommon_setup, NIKEgen, NIKEkey) be a BLR-CKS-heavy-secure NIKE scheme, and let LR-SIG = (SIGkg, SIGsign, SIGvfy) be a UF-CMLA-secure signature scheme. Then we construct a LLKE protocol  Proof sketch. We distinguish between four different attackers: • an A1-type attacker asks the Test query to a client oracle and the temporary key; • an A2-type attacker asks the Test query to a client oracle and the main key; • an A3-type attacker asks the Test query to a server oracle and the temporary key; • an A4-type attacker asks the Test query to a client oracle and the main key.
The four different attackers correspond to all possible combinations of queries that are allowed in our BK-LLKE-ma security model. The four distinct lines of the equation in Theorem 5.8 corresponds to each of above cases, respectively. We can easily simulate the leakage by giving the adversary A the leakage obtained from the underlying leakage-resilient NIKE challenger and the signature scheme challenger. Apart from that, the simulation is the same as that of Hale et al. [23].

Leakage tolerance of the generic LR-LLKE protocol
This generic protocol can tolerate the leakage according to the leakage tolerance of the underlying leakageresilient NIKE and the leakage-resilient signature scheme. Our LR-NIKE can tolerate 1 − o(1) leakage, and the UF-CMLA signature scheme of Katz et al. [26] can tolerate n − n ε leakage, for an n-bit key and 1 > ε > 0, which approaches 1 − o(1) leakage rate for sufficiently large n and small enough ε. Thus the corresponding instantiation can tolerate an overall leakage rate of 1 − o(1).

Conclusion and future works
Our work provides a new direction for constructing several leakage-resilient cryptographic primitives, such as leakage-resilient PKE schemes, AKE protocols and LLKE protocols, using leakage-resilient NIKE protocols as the main building block. Our construction of LR-NIKE in the bounded leakage setting achieves an optimal leakage rate, i.e., 1 − o (1), and the resulting leakage-resilient constructions from that also preserve the same leakage rate, upon the appropriate choice of parameters. Our work also opens up leakage-resilient LLKE protocols, and we hope there is much work to be done on this. We leave open the following main problems: • construction of leakage-resilient NIKE in the (1 − o (1) This measures the worst-case predictability of X by an adversary that may observe a correlated variable Z.
The following bound on average min-entropy was proved by Dodis et al. [17].

A.2 Leakage-resilient (LR) chameleon hash functions
In this section, we give the definition of LR chameleon hash functions (CHF) in the bounded memory leakage model following [39].

LR-CHF in bounded leakage model:
Informally, a chameleon hash function (CHF) is a collision-resistant hash function, the only difference being that it is easy to find collision given a trapdoor. Without knowing the trapdoor, it is hard to find any collision. Leakage-resilient chameleon hash functions (LR-CHF) postulate that it is hard to find collisions, even when the adversary learns bounded leakage/information about the secret key. Formally, an λ-LR-CHF ChamH : D × R cham → I, where D is the domain, R cham the randomness space and I the range, consists of the algorithms (Cham.KeyGen, Cham.Eval, Cham.TCF).
(i) Cham. KeyGen(1 κ , λ): The key generation algorithm takes as input 1 κ and the leakage bound λ as parameters and outputs an evaluation key along with a trapdoor (hk, ck). The public key hk defines a chameleon hash function, denoted ChamH hk ( ⋅ , ⋅ ). (ii) Cham.Eval(hk, m, r): The hash function evaluation algorithm that takes as input hk, a message m ∈ D and a randomizer r ∈ R cham , outputs a hash value h = ChamH hk (m, r).
(iii) Cham.TCF(ck, (m, r), m ): The trapdoor collision finder algorithm takes as the trapdoor ck, a messagerandomizer pair (m, r), an additional message m , and outputs a value r ∈ R cham such that ChamH hk (m, r) = ChamH hk (m , r ).
A λ-LR-CHF must satisfy the following three properties.
• Random trapdoor collisions: The random trapdoor collision property is satisfied if, for a trapdoor ck, an arbitrary message pair (m, m ) and a randomizer r, we have that r = Cham.TCF(ck, (m, r), m ) has uniform probability distribution on the randomness space R cham . • LR-collision resistance: The LR collision-resistance property is satisfied if, for any PPT adversary A, the following advantage in negligible: where O κ,λ ck is the leakage oracle to which A can adaptively query to learn at most λ bits of information about the trapdoor ck.

A.3 Pseudo-random functions
F : Σ k × Σ m → Σ n is a (ε prf , s prf , q prf ) secure pseudo-random function (PRF) if no adversary of size s prf can distinguish F (instantiated with a random key) from a uniformly random function, i.e., for any A of size s prf making q prf oracle queries, we have

A.4 UF-CMLA-secure signature schemes
We review the definition of UF-CMLA security according to Katz et al. [26]. The leakage function f i is an adversary chosen efficiently computable adaptive leakage function, which leaks f i (sk) from a secret key sk.
We say the signature scheme LR-SIG is UF-CMLA-secure if Adv UF-CMLA LR-SIG,B sig (κ) is negligible.
Katz et al. [26] constructed a UFCMLA-secure signature scheme in bounded leakage model in which n = 1. It contains signing and verification operations based on NIZK proofs, where the signature can be generated with a cost of two exponentiations and verified with a cost of four exponentiations (with a simple NIZK proof).

B Leakage-resilient cryptography and leakage models
During the past two decades, side-channel attacks have arisen as a popular method of attacking cryptographic systems. In order to abstractly model the side-channel attacks and analyze the security of cryptographic primitives against them, cryptographers have proposed the notion of leakage-resilient cryptography, introducing various leakage models [2,6,29,30].
In the work of Micali and Reyzin [30], a general framework was introduced to model the leakage that occurs during computation with secret parameters, which is widely known as the only computation leaks information (OCLI) axiom. They mentioned that the leakage only occurs from the secret memory portions which are actively involved in computations. The leakage amount is bounded per computation, though the adversary is allowed to obtain the leakage from many computations. Therefore, the overall leakage amount is unbounded. Since this assumption enforces that the leakage only occurs due to computations, this does not cover the attacks that happen due to the leakage from the memory such as malware attacks, cold-boot attacks, etc.
Inspired by the cold-boot attacks, Akavia et al. [2] constructed a general framework to model bounded leakage attacks, which is widely known as bounded-memory leakage model. The adversary chooses an arbitrary polynomial-time leakage function f and sends it to the leakage oracle. The leakage oracle returns f(sk) to the adversary, where sk is the secret key. The only restriction here is that the sum of output lengths of all the leakage functions that an adversary can obtain is bounded by some parameter λ, which is smaller than the size of sk. This leakage model does not address the continuous leakage from the memory, which can often happen due to attacks such as malware attacks.
Previous works of Zvika et al. [9] and Dodis et al. [14] presented a continual-memory leakage model, in which it is assumed that the leakage happens from the entire secret memory. The other characteristics of this model are the same as the OCLI model. This leakage model is stronger than the OCLI model because here the adversary can obtain the leakage from the entire memory regardless of computations.
Differently, Dodis et al. [16] introduced a leakage model where the adversary is allowed to obtain the leakage as any computationally uninvertible function of the secret key as auxiliary input. That model eliminates the concept of leakage parameter, but enforces the hardness parameter instead.

C Vulnerability of the NIKE protocol of [19] in the bounded-leakage setting
In this section, we show that the NIKE protocol of Freire et al. [19] from pairings in the standard model is completely insecure, even if the adversary is given only a single bit of leakage on the secret key. The attack exploits the fact that the adversary can ask any arbitrary leakage function as long as the output of the function is length-shrinking in its input size. In particular, the secret key of a party in the NIKE protocol in Freire et al. [19] is a field element, i.e., x ∈ ℤ p , and one of the components of the public key is Z = g x . The shared key between two parties ID i and ID j has the structure e(S x i , Z j ), where S is a public element, Z j = g x j and x i and x j are the secret keys of parties ID i and ID j , respectively. Now, given the public key, the adversary can encode the function that leaks the hardcore bit of the discrete logarithm of Z. In other words, he can specify the leakage function in such a way that it leaks exactly the most significant bit (MSB) of x. Note that the MSB of x is actually the hardcore bit of the discrete logarithm function. So, with a single bit of leakage, the adversary can recover x completely, and hence he can distinguish the shared secret key from a random key with probability 1 and win the indistinguishability game. In fact, here, with only a single bit of leakage, the adversary can perform a key recovery attack, which is stronger than the attack on the indistinguishability game.
Funding: Janaka would like to acknowledge the university research grant URG/2018/19/E of the University of Peradeniya, Sri Lanka. The authors would like to acknowledge the support of the Indian Institute of Technology Madras and the University of Peradeniya for this collaborative work.