Chameleon-Hashes with Dual Long-Term Trapdoors and Their Applications [chapter]

Stephan Krenn, Henrich C. Pöhls, Kai Samelin, Daniel Slamanig
<span title="">2018</span> <i title="Springer International Publishing"> <a target="_blank" rel="noopener" href="" style="color: black;">Lecture Notes in Computer Science</a> </i> &nbsp;
A chameleon-hash behaves likes a standard collision-resistant hash function for outsiders. If, however, a trapdoor is known, arbitrary collisions can be found. Chameleon-hashes with ephemeral trapdoors (CHET; Camenisch et al., PKC '17) allow prohibiting that the holder of the long-term trapdoor can find collisions by introducing a second, ephemeral, trapdoor. However, this ephemeral trapdoor is required to be chosen freshly for each hash. We extend these ideas and introduce the notion of
more &raquo; ... on-hashes with dual long-term trapdoors (CHDLTT). Here, the second trapdoor is not chosen freshly for each new hash; Rather, the hashing party can decide if it wants to generate a fresh second trapdoor or use an existing one. This primitive generalizes CHETs, extends their applicability and enables some appealing new use-cases, including three-party sanitizable signatures, group-level selectively revocable signatures and break-the-glass signatures. We present two provably secure constructions and an implementation which demonstrates that this extended primitive is efficient enough for use in practice. Motivation and Contribution. We introduce chameleon-hashes with dual long-term trapdoors (CHDLTT). In this primitive, the second trapdoor no longer needs to be freshly generated on every hash computation, but can be re-used in several hash computations. This has several advantages over CHETs as defined by Camenisch et al. [22] . For example, our definitions allow that the trapdoors can be generated in advance (and thus can, e.g., be registered at a PKI before usage), re-used multiple times (which adds flexibility and saves computational costs) and are inherently independent of any other hashing keys created. In other words, releasing the second trapdoor allows the holder of the long-term secret to find collisions for all hashes created using the corresponding second public hashing key that corresponds to the trapdoor. Thus, our new primitive strictly generalizes CHETs: using a fresh trapdoor for each generated hash within our extended definition of CHDLTT resembles the behavior of a CHET. We introduce a suitable framework, along with corresponding security definitions and two provably secure constructions. The first construction is based on standard collision-resistant chameleon-hashes, while the second one is based on the one-more RSA-Assumption. To demonstrate the usefulness of our new primitive, we show how one can construct three-party sanitizable signatures. In this new primitive, a signer-designated third party can decide if, and when, the sanitizer is able to sanitize the admissible parts of messages. This new primitive enables several new use-cases for sanitizable signatures scheme. For example, consider the following scenario, where "standard" sanitizable signatures [2] are not sufficient. Assume a supply chain, where the delivery person needs to claim that it delivered the goods as instructed by the sender, while also the recipient needs to vouch for the correct delivery at time of successful reception. In standard sanitizable signature schemes, either a fresh signature is generated at delivery, which is approved by the recipient, or vice versa. However, in this case, the sender has no control what is actually signed. Our extended primitives allows to tackle this problem: the sender can sign what has been commissioned, while the delivery person can approve that it has successfully delivered the goods, if, and only if, the recipient allows the delivery man to do this, i.e., by releasing an additional trapdoor. To some extend, this resembles "four-eyes"-signatures [12] , but in a more sophisticated manner, as in our case also damaged goods can be reported within the same report, e.g., using special blocks of the message. Additional application scenarios include group-level selectively revocable signatures and break-the-glass signatures. Revocable signatures have already been mentioned by Camenisch et al. [22] as a potential additional application scenario, while break-the-glass signatures are a new concept. Moreover, our evaluation shows that the primitive is practically efficient. Summarized, our work leads to some new interesting applications of chameleon-hashes, which may give rise to new use-cases which have not been considered yet. Related Work and State-of-the-Art. Chameleon-hashes were introduced by Krawczyk and Rabin [47], based on the work done by Brassard et al. [16] . Later, they have been ported to the identity-based setting, i.e., ID-based chameleon-hash functions, where the holder of some master secret key can extract new secret keys for new identities [4, 6, 56, 58]. However, most of the schemes presented suffer from the key-exposure problem [5, 27, 47]. Key-exposure means that seeing a single collision in the hash allows to find further collisions by extracting the corresponding trapdoor, i.e., the secret key. 4 This problem was addressed by the introduction of "key-exposure free" chameleon-hashes [5, 26, 27, 38, 39, 56], which prohibit extracting the secret key if a collision was seen. This also includes combinations of both techniques [29] . Such schemes allow for re-using secret key-material. However, the definition of collision-resistance is defined w.r.t. some additional label L. 5 This label L is used to define a "collision-domain", i.e., such hashes do not prohibit that once a collision is made public for a label L, an adversary cannot produce additional collisions w.r.t. that label L. We stress that our framework does not require such a label, i.e., it is collision-resistant in the "usual" sense. Brzuska et al. also proposed a formal framework for tag-based chameleon-hashes secure under random-tagging attacks, i.e., they 4 In the case of identity-based chameleon-hashes w.r.t. to some identity. 5 Also referred to as nonce or tag. Preliminaries Let us give our notation and assumptions first. Additional standard formal security definitions are given in App. A. Notation. λ ∈ N denotes our security parameter. All algorithms implicitly take 1 λ as an additional input. We write a ← A(x) if a is assigned to the output of algorithm A with input x. An algorithm is efficient if it runs in probabilistic polynomial time (ppt) in the length of its input. All algorithms are ppt, if not explicitly mentioned otherwise. Most algorithms may return a special error symbol ⊥ / ∈ {0, 1} * , denoting an exception. Returning output ends an algorithm. If S is a set, we write a ← S to denote that a is chosen uniformly at random from S. For a list we require that there is an injective, and efficiently reversible, encoding, mapping the list to {0, 1} * . In the definitions, we speak of a general message space M to be as generic as possible. For our instantiations, however, we let the message space M be {0, 1} * to reduce unhelpful boilerplate notation. A function ν : N → R ≥0 is negligible, if it vanishes faster than every inverse polynomial, i.e., ∀k ∈ N, ∃n 0 ∈ N such that ν(n) ≤ n −k , ∀n > n 0 . Moreover, we require that one can derive a public key from the private key. This is not explicitly checked. This can be achieved by appending the randomness used to generate the key pair to the secret key. The One-More-RSA-Assumption [9]. Let (n, e, d, p, q) ← RSA(1 λ ) be an RSA-key generator returning an RSA modulus n = pq, where p and q are random distinct primes, e > 1 an integer co-prime to ϕ(n), and d ≡ e −1 mod ϕ(n). The one-more-RSA-assumption associated to RSA is provided an inversion oracle I, which inverts any element x ∈ Z * n w.r.t. e, and a challenge oracle C, which at each call returns a random element y i ∈ Z * n . An adversary wins if, given n and e, it is able to invert more elements received by C than is makes calls to I. The corresponding assumption states that for every ppt adversary A there exists a negligible function ν such that: Pr [(n, p, q, e, d) ← RSA(1 λ ), X ← A(n, e) C(n),I(d,n,·) : more values returned by C are inverted than queries to I] ≤ ν(λ) Here, X is the set of inverted challenges. We require that e is larger than any possible n w.r.t. λ and that it is prime. Re-stating the assumption with this condition is straightforward. In this case, it is also required that e is drawn independently from p, q, or n (and d is then calculated from e, and not vice versa). This can, e.g., be achieved by demanding that e is drawn uniformly from [n + 1, . . . , 2n ] ∩ {p | p is prime}, where n is the largest RSA modulus possible w.r.t. to λ. The details are left to the concrete instantiation of RSA. Chameleon-Hashes. The given framework is the one by Camenisch et al. [22] . Definition 1. A chameleon-hash CH consists of five algorithms (PGen, KGen, Hash, Ver, Adap), such that: Definition 3 (Collision-Resistance). A chameleon-hash CH is collision-resistant, if for any ppt adversary A there exists a negligible function ν such that Pr[CollRes CH A (1 λ ) = 1] ≤ ν(λ). The corresponding experiment is depicted in Fig. 2. Uniqueness. Uniqueness requires that it is hard to come up with two different randomnesses for the same message m * such that the hashes are equal, for the same adversarially chosen pk * . Definition 4 (Uniqueness). A chameleon-hash CH is unique, if for any ppt adversary A there exists a negligible function ν such that Pr[Uniqueness CH A (1 λ ) = 1] ≤ ν(λ) The corresponding experiment is depicted in Figure 3 . Definition 5 (Secure Chameleon-Hashes). A chameleon-hash CH is secure, if it is correct, indistinguishable, and collision-resistant. It depends on the concrete use-case, if CH needs to be unique. 6 The randomness r is also sometimes called "check value" [3] .
<span class="external-identifiers"> <a target="_blank" rel="external noopener noreferrer" href="">doi:10.1007/978-3-319-89339-6_2</a> <a target="_blank" rel="external noopener" href="">fatcat:bvkvzn4cbzebxgtpdytjjdkg4a</a> </span>
<a target="_blank" rel="noopener" href="" title="fulltext PDF download" data-goatcounter-click="serp-fulltext" data-goatcounter-title="serp-fulltext"> <button class="ui simple right pointing dropdown compact black labeled icon button serp-button"> <i class="icon ia-icon"></i> Web Archive [PDF] <div class="menu fulltext-thumbnail"> <img src="" alt="fulltext thumbnail" loading="lazy"> </div> </button> </a> <a target="_blank" rel="external noopener noreferrer" href=""> <button class="ui left aligned compact blue labeled icon button serp-button"> <i class="external alternate icon"></i> </button> </a>