A Closer Look at Multiple Forking: Leveraging (In)Dependence for a Tighter Bound

Abstract

Boldyreva, Palacio and Warinschi introduced a multiple forking game as an extension of general forking. The notion of (multiple) forking is a useful abstraction from the actual simulation of cryptographic scheme to the adversary in a security reduction, and is achieved through the intermediary of a so-called wrapper algorithm. Multiple forking has turned out to be a useful tool in the security argument of several cryptographic protocols. However, a reduction employing multiple forking incurs a significant degradation of $\text {O}(q^{2n})$, where $q$ denotes the upper bound on the underlying random oracle calls and $n$, the number of forkings. In this work we take a closer look at the reasons for the degradation with a tighter security bound in mind. We nail down the exact set of conditions for success in the multiple forking game. A careful analysis of the cryptographic schemes and corresponding security reduction employing multiple forking leads to the formulation of ‘dependence’ and ‘independence’ conditions pertaining to the output of the wrapper in different rounds. Based on the (in)dependence conditions we propose a general framework of multiple forking and a General Multiple Forking Lemma. Leveraging (in)dependence to the full allows us to improve the degradation factor in the multiple forking game by a factor of $\text {O}({q^n})$. By implication, the cost of a single forking involving two random oracles (augmented forking) matches that involving a single random oracle (elementary forking). Finally, we study the effect of these observations on the concrete security of existing schemes employing multiple forking. We conclude that by careful design of the protocol (and the wrapper in the security reduction) it is possible to harness our observations to the full extent.

Appendices

Appendix: (Original) Multiple-Forking Algorithm

We reproduce the multiple-forking game of Boldyreva et al. [3] with some notational changes, followed by the lemma statement.

Multiple-Forking Game Fix and a set such that . Let be a randomised algorithm that on input a string $x$ and elements returns a triple $(I, J,\sigma )$ consisting of two integers $0\le J<I \le q$ and a string $\sigma$. Let $n\ge 1$ be an odd integer. The forking game associated to and $n$ is defined as Algorithm 5 below.

The success condition The success of multiple forking game is determined by the set of conditions where

(21)

To be precise, the multiple forking game is successful in the event that all of the conditions in are satisfied, i.e.,

(22)

The probability of this event, which is denoted by , is bounded by the lemma given below.

Lemma 7

((Original) Multiple-Forking Lemma [3]) Let be a randomised algorithm that takes no input and returns a string. Let

then

(23)

Harnessing (In)Dependence

1.1 Multiple-Forking with Index Independence

Lemma 8

(Multiple-Forking Lemma with Index Independence) Let be a probability distribution on a set . Let

then

(24)

Proof

The analysis, especially its logical flow, is quite similar to the original analysis in [3]. Since no dependence is assumed we can carry out the analysis without directly using the logical wrapper. We stick to the conventions adopted in Sect. 3.2. For a fixed string , let

Recall the condition-set from Table 3. For ease of notation, we further break the event (resp. ) into two subevents and (resp. and ) as follows:

(25)

With the probabilities calculated over the randomness used in the forking game, it follows that where

The first step in calculating the probability is to separate the core subevents out of the event . This is accomplished as follows.

(26)

It can be shown that the second part of (26) equals by following the analysis in (19), whereas the first part constitutes the core event, and is denoted by . The event corresponding to is closely related to the event given in (7). The next step is to show that

(27)

The intermediate steps to achieving it follow.

(28)

In the above expression, denotes the event . Let’s focus on the probability part of (28) (conditioned on ).

(29)

At this point, we define a series of random variables , for each , and as follows.

captures a single invocation of the wrapper but with the internal randomness $\rho _w$ and the random coins fixed. Using , and taking expectation over uniform distribution on its domain, (29) can be rewritten as

(30)

Next, we define a random variable , for each , by setting

Hence, on representing (30) in terms of the random variable , we get

Substituting the above expression, further, in (28) yields

That completes the analysis of the core event and establishes our initial claim in (27). On combining the two parts of the equation (26), we get

With expectation taken over ,

hence, proving the lemma. On assuming , one gets .

1.2 Multiple-Forking with Index Dependence

Lemma 9

(Multiple-Forking Lemma with Index Dependence) Let be a probability distribution on a set . Let

On the assumption that $J$ is $\eta$-dependent on $I$,

(31)

Proof

For a fixed string , let

Recall the condition-set from Table 3—we separate the event into the core and non-core events given below.

(32)

With the probability calculated over the randomness of the general forking game, it follows that , where

We use three claims: Claim 1 (which we re-use from Sect. 3.2), Claim 5 and Claim 6 to achieve this. In order to establish Claim 5 and Claim 6 we define a random variable , for each and , as

Briefly, our aim is to bound in terms of (Claim 5) and bound in terms of (Claim 6).

Claim 5

Proof

We separate out the subevents of the event as shown below.

(33)

We denote the first part of (33) by and the second part by and analyse them separately.

(34)

In the above expression, denotes the event . Using the random variable , (34) can be rewritten as

(35)

Using a similar line of approach (as in (34) and (35)), it is possible to establish that

(36)

Substituting the value of from (35) and from (36) in (33), yields the bound in Claim 5.

What remains is to relate Claim 1 and Claim 5

Claim 6

Proof

From the definition of the random variable , it follows that

Therefore , which by definition is .

On putting all the three claims together, we get

Finally, taking the expectation over , yields

establishing Lemma 9. We conclude with the comment that on assuming , one gets .

Constructions

1.1 The Boldyreva–Palacio–Warinschi Proxy Signature Scheme

Let denote the Schnorr signature scheme. The Triple-Schnorr proxy signature scheme consists of the algorithms , each of which is defined in Fig. 7.

Fig. 7

The BPW Proxy Signature Scheme (We use in place of $\omega$ (used in [3]) to maintain uniformity of notation)

Remark 4

Self-delegation can be achieved by invoking the interactive algorithm on a second key-pair of the designator, in place of the key-pair of the proxy signer. For example, a user $i$ with an alternative key-pair can delegate itself by invoking

1.2 Galindo Garcia IBS: Original and Modified

Fig. 8

The (Original) Galindo-Garcia IBS

Fig. 9

The modified Galindo-Garcia IBS

The construction in Fig. 9 is the same as in Fig. 8 except for the structure of the hash functions—we have introduced a binding between and (through where ). Note that the binding that we introduced is more refined than the one suggested in Sect. 4.3.1 (i.e., where ) (see Fig. 9).

Security Arguments

1.1 Modified Galindo-Garcia IBS

Theorem 1

Let be an -adversary against the modified GG-IBS. If and are modelled as random oracles, we can construct either

• (i) Algorithm which -breaks the DLP, where or

• (ii) Algorithm which -breaks the DLP, where .

Here and denote the upper bound on the number of extract and signature queries, respectively, that can make; and denote the upper bound on the number of queries to the -oracle and -oracle respectively.

Proof

(sketch) is successful if it produces a valid non-trivial forgery $\hat{\sigma } =(\hat{b}, \hat{R}, \hat{A})$ on . Consider the following complementary events in the case that is successful.

• : makes at least one signature query on and $\hat{R}$ was returned by the simulator as part of the output to a signature query on .

• : Either does not make any signature queries on or $\hat{R}$ was never returned by the simulator as part of the output to a signature query on .

In the event we give a reduction , whereas in the event , we give . Apart from the need of a wrapper, is similar to the reduction given in [5]. , on the other hand, employs the forking game (with Lemma 3), in place of . Hence, we confine the security argument to the details of reduction .

1.1.1 Reduction

Let be the given DLP instance. The reduction involves invoking the forking game on the wrapper as shown in Algorithm 6. As a result, it obtains a set of four congruences in four unknowns and solves for $\alpha$. It can be verified that indeed returns the correct solution to the DLP instance (see full version of [5] for details).

1.1.2 The Wrapper

Suppose that and . Wrapper takes as input the master public key and , and returns a triple $(I,J,\sigma )$ where $J$ and $I$ are integers that refer to the target and query respectively and $\sigma$ is the side-output. In order to track the index of the current random oracle query, maintains a counter $\ell$, initially set to 1. It also maintains a table (resp. ) to manage the random oracle (resp. ). initiates the simulation of the protocol environment by passing as the challenge master public key to the adversary . The queries by are handled as per the following specifications.

• (a) -oracle Query. contains tuples of the form . Here, is the query to the -oracle with $c$ being the corresponding output. The index of the oracle call is stored in the $\ell$-field. Finally, the $y$-field stores either (a component of) the secret key for , or a ‘’ in case the field is invalid. A fresh -oracle query is handled as follows: i) return as the output; and ii) add to and increment $\ell$ by one.

• (b) -oracle Query. contains tuples of the form . Here, $(m,A,c)$ is the query to the -oracle with $d$ being the corresponding output. The index of the oracle call is stored in the $\ell$-field. A fresh -oracle query is handled as follows: i) return as the output; and ii) add to and increment $\ell$ by one.

• c) Signature and Extract Queries. Since the master secret key $\alpha$ is unknown to , it has to carefully program the -oracle in order to generate the user secret key . The signature queries, on the other hand, are answered by first generating the (as in the extract query), followed by invoking .

  • Extract query. :

    • (i) If there exists a tuple in such that returns as the secret key.

    • (ii) Otherwise, chooses , sets and $R:=(g^\alpha )^{-c}g^y$. It then adds ¹¹ to and increments $\ell$ by one (an implicit -oracle call). Finally, it returns as the secret key.

  • Signature query. :

    • (i) If there exists a tuple in such that , then . now uses the knowledge of to run and returns the signature.

    • (ii) Otherwise, generates the as in step (ii) of Extract query and runs to return the signature.

The Output At the end of the game, a successful adversary outputs a valid forgery on . Let be the tuple in that corresponds to the target -query. Similarly, let be the tuple in that corresponds to the target -query. returns $(\ell _i, \ell _j, (\hat{b}, c_j, d_i))$ as its own output. Note that the side-output $\sigma$ consists of $(\hat{b}, c_j, d_i)$.

Analysis Since there is no abort involved in the simulation of the protocol, we may conclude that the accepting probability of is the same as the advantage of the adversary, i.e.. The probability of success of the reduction is computed by using Lemma 3 with , and $n=3$. Hence, we have .

1.2 Chow-Ma-Weng Zero Knowledge Protocol

1.2.1 Reduction

Let be the given DLP instance. The reduction involves invoking the forking game on the wrapper as shown in Algorithm 7. As a result, it obtains a set of six congruences in six unknowns and solves for .

1.2.2 The Wrapper

Suppose that and . takes as input the public parameters and , and returns a triple $(I,J,\sigma )$ where $J$ and $I$ are integers that refer to the target query and challenge-commitment round respectively and $\sigma$ is the side-output. In order to track the index of the current query, maintains a counter $\ell$, initially set to 1. It also maintains a table (resp. ) to manage the random oracle (resp. , for simulated challenges). initiates the simulation of the protocol environment by passing as the challenge public parameter to the adversary . The queries by are handled as per the following specifications.

• a) -oracle Query. contains tuples of the form . Here, $(y_1,y_2)$ is the query to the -oracle with $z$ being the corresponding response. The index of the oracle call is stored in the $\ell$-field. A fresh -oracle query is handled as follows: i) return as the output; and ii) add to and increment $\ell$ by one.

• b) Challenge . contains tuples of the form . Here, $v$ is a commitment made by with $c$ being the corresponding challenge. The index of the commitment is stored in the $\ell$-field. A commitment is handled as follows: i) return as the challenge; and ii) add to and increment $\ell$ by one.

The Output At the end of the game, a successful adversary outputs $(\hat{s}, (\hat{y}_1,\hat{y}_2))$ such that but the verification holds. Let be the tuple in that corresponds to the target -oracle query—that is . Similarly, let be the tuple in that corresponds to the target challenge. returns $(\ell _i, \ell _j, (z_i,c_j,\hat{s}))$ as its own output.