Delegating a Product of Group Exponentiations with Application to Signature Schemes (Submission to Special NutMiC 2019 Issue of JMC)

Our Contributions

In this paper we show that a product of many fixed-base exponentiations, over a cyclic group with certain properties, can be privately and securely delegated to a single, possibly malicious, server, by keeping the client’s online number of modular multiplications only slightly larger than that for delegating a single exponentiation. Our result holds for a general class of cyclic groups with efficient operation and inverse, and efficiently verifiable proofs of membership. Although not all cyclic groups are known to satisfy these properties, we show that this class includes cyclic groups often used in cryptography (i.e., the prime order multiplicative subgroup of ℤ_p, for primes p of a special form, and the analogue additive group based on elliptic curves). Fixing the first of these two groups for efficiency evaluation, a product of m exponentiations in ℤ_p with σ-bit exponents can be delegated by a client that only uses less than 2λ+m+4 modular multiplications in the online phase, if the probability of not detecting an incorrect result is bounded by 2^−λ. This improves upon non-delegated computation, which would require up to 2mσ+m−1 modular multiplications, when exponentiation is performed via a square and multiply algorithm, as well as upon direct and repeated use of the delegation of a single exponentiation from [21], where the client would use up to 2mλ+4m modular multiplication in the online phase.

We use this result to delegate the first cryptographic schemes: the well-known digital signature schemes by El-Gamal [27], Schnorr [41] and Okamoto [39] over the prime-order subgroup in ℤ_p, as well as their variants based on elliptic curves. Previously, only primitive operations like group exponentiations or inverses were delegated, and no complete cryptosystem was delegated to a single, possibly malicious, server. As an example of the efficiency achieved here, Okamoto’s scheme normally requiring a verification of 3 exponentiations with 2048-bit exponents can now be delegated by a client that only uses 1 exponentiation to a random and short (e.g., 128-bit) exponent.

In the process, we formally define delegation of digital signature schemes, including changes to both the participant and the security model. First, we enrich the participant model of signature schemes, including a signer and a verifier, with a server who can assist both. Thus, both signer and verifier will be thought of as clients when interacting with the delegation server. Next, we generalize the standard unforgeability requirement to also hold in the presence of 2 additional classes of attacks introduced by the delegated computation paradigm: (1) eavesdropping of the communication between the server and the two clients (i.e., signer and the verifier), as well as (2) querying the server oracles, possibly done by the adversary after being able to perform a signer or verifier impersonation. We also provide a conversion theorem showing that a non-delegated signature scheme can be converted into a delegated signature scheme using a suitable delegation protocol for a desired primitive operation (e.g., single exponentiation, product of exponentiations, etc.). Establishing this result calls for the use of an alternative, and not weaker, simulation-based, definition of privacy in delegation protocols (many previous works targeted an indistinguishability-based definitions of privacy but can be seen to satisfy this definition as well).

Related Work

The first formal model for secure delegation protocols was presented in [31]. There, a secure delegation protocol is formally defined as essentially a secure function evaluation [45] of the client’s function delegated to the server. Follow-up models from [29] and [13, 21] define separate requirements of correctness, (input) privacy and (result) security. There, the privacy requirement is defined in the sense of the adversary’s indistinguishability of two different inputs from the client, even after corrupting the server; and the security requirement is defined in the sense of the adversary’s inability to convince the client of an incorrect function output, even after corrupting the server. In our paper, we use a simulation-based definition of input privacy, which can be shown to imply the indistinguishability-based definition in [13, 21].

We can partition all other (single-server) secure delegation protocols we are aware of in 3 main classes, depending on whether they delegate (a) exponentiation in a specific group; (b) other specific computations (e.g., linear algebra); or (c) an arbitrary polynomial-time function.

With respect to (a), protocols were proposed for a single exponentiation in specific groups related to discrete logarithm or factoring problems (see, e.g., [14, 21, 31] and references therein). These protocols delegate exponentiation in settings where the client is assumed to be powerful enough to run a moderate number of group multiplications, but not enough to evaluate the delegated exponentiation function. There are also many protocols in the literature for the delegation of a single exponentiation, not targeting or achieving all our requirements (see, e.g., [15, 24, 34, 43]). In our model, protocols for the delegation of exponentiation in general groups were proposed in [13, 19], and protocols to delegate multiple exponentiations in specific groups were proposed in [20].

With respect to (b), protocols for linear algebra and/or scientific computation were proposed in, e.g., [2, 3, 8, 28, 35]. These protocols delegate various linear algebra operations in settings where the client is assumed to be powerful enough to run other linear algebra operations of lower time complexity, but not enough to evaluate the delegated linear algebra function.

With respect to (c), [29] proposed a protocol using garbled circuits [45] and fully homomorphic encryption [30]. This protocol delegates functions in settings where the client is powerful enough to run encryption and decryption algorithms of a fully homomorphic encryption scheme, but not enough to homomorphically evaluate a circuit that computes decryption steps in the garbling scheme for the function. Different protocols, not using garbled circuits, were later proposed in [16]. These protocols delegate functions in settings where the client is assumed to be powerful enough to run encryption and decryption algorithms of a fully homomorphic encryption scheme, but not enough to homomorphically evaluate the delegated function.

Group notations and definitions

Let (G, *) be a group, let σ be its computational security parameter, and let L denote the length of the binary representation of elements in G. Typically, in cryptographic applications we set L as about equal to σ. We also assume that (G, *) is cyclic, has order q, and we fix m of its distinct generators as g₁, …, g_m. By y=g1x1⋯gmxm=∏i=1mgixi we denote the product of m (fixed-base) exponentiations (in G). Let ℤ_q = {0, 1, …, q − 1}, and let F_g1,…,gm,q : (ℤ_q × … × ℤ_q) → G denote the function that maps to each (x₁, …, x_m) ∈ ℤ_q × … × ℤ_q the product of m (fixed-base) exponentiations (in G). By desc(F_g1,…,gm,q) we denote a conventional description of the function F_g1,…,gm,q that includes its semantic meaning as well as generators g₁, …, g_m, order q and the efficient algorithms computing multiplication and inverses in G.

By t_exp(ℓ) we denote a parameter denoting the number of multiplications in G used to compute an exponentiation (in G) of a group value to an arbitrary ℓ-bit exponent. By t_m,exp(ℓ) we denote a parameter denoting the number of multiplications in G used to compute m exponentiations (in G) of the same group value to m arbitrary ℓ-bit exponents. By t_prod,m,exp(ℓ) we denote the max number of group multiplications used to compute a product of m exponentiations of (possibly different) group elements to m arbitrary ℓ-bit exponents.

We define an efficiently verifiable membership protocol for G as a one-message protocol, denoted as the pair (mProve, mVerify) of algorithms, satisfying

1. completeness: for any w ∈ G, mVerify(w, mProve(w)) = 1;

2. soundness: for any w ∉ G, and any mProve′,

      mVerify(w, mProve′(w)) = 0;

3. efficient verifiability: the number of multiplications in G, denoted as t_mVerify(σ), executed by mVerify is o(t_exp(σ));

4. efficient provability: the number of multiplications t_mProve(σ) in G executed by mProve is not significantly larger than t_exp(σ).

We say that a group is efficient if its description is short (i.e., has length polynomial in σ), its associated operation and the inverse operation are efficient (i.e., they can be executed in time polynomial in σ), and it has an efficiently verifiable membership protocol. Note that for essentially all cyclic groups frequently used in cryptography, the description is short and both the associated operation and inverse operation can be run in time polynomial in σ. The only non-trivial property to establish is whether the group has an efficiently verifiable membership protocol. We now show two examples that are often used in cryptography and that do have efficiently verifiable membership protocols. In the rest of the paper we present our results for any arbitrary efficient cyclic group (using, for notation simplicity, a multiplicative notation for its operation).

The completeness and soundness properties of this protocol are easily seen to hold. The efficient provability follows by noting that mProve only performs 1 exponentiation mod p. The efficient verifiability property follows by noting that mVerify requires one exponentiation mod p to the k-th power. We note that mVerify is very efficient in the case when k is small (e.g., k = ), which is a typical group setting in cryptographic protocols based on discrete logarithms. In the rest of the paper, we assume this specific group when we evaluate the performance of our protocol(s).

The completeness, soundness, efficient provability properties of this protocol are easily seen to hold. The efficient verifiability property follows by noting that mVerify performs only 4 multiplications mod p.

Basic notations

The expression y ← T denotes the probabilistic process of randomly and independently choosing y from set T. The expression y ← A(x₁, x₂, …) denotes the (possibly probabilistic) process of running algorithm A on input x₁, x₂, … and any necessary random coins, and obtaining y as output. The expression (z_A, z_B, tr) ← (A(x₁, x₂, …), B(y₁, y₂, …)) denotes the (possibly probabilistic) process of running an interactive protocol between A, taking as input x₁, x₂, … and any necessary random coins, and B, taking as input y₁, y₂, … and any necessary random coins, where z_A, z_B are A and B’s final outputs, respectively, at the end of this protocol’s execution, and tr denotes the tuple of messages exchanged between A and B. We denote a distribution D as D = {R₁; …; R_n : x}, where R₁, …, R_n is a sequence of random processes and x denotes a variable set as a result of their sequential execution.

System scenario, entities, and protocol

We consider a system with a single client, denoted as C, and a single server, denoted as S. As a client’s computational resources are expected to be more limited than a server’s ones, C is interested in delegating the computation of specific functions to S. We assume that the communication link between C and S is private or not subject to confidentiality, integrity, or replay attacks, and note that such attacks can be separately addressed using communication security techniques from any applied cryptography textbook (see, e.g., [36]). As in all previous work in the area, we consider a model with an offline phase, where, say, exponentiations to random exponents can be precomputed and made somehow available onto C’s device. This model has been justified in several ways, all appealing to different application settings. In the presence of a trusted party, such as a deploying entity setting up C’s device, the trusted party can simply perform the precomputed exponentiations and store them on C’s device. If no trusted party is available, in the presence of a pre-processing phase where C’s device does not have significant computation constraints, C can itself perform the precomputed exponentiations and store them on its own device.

Let σ denote the computational security parameter (i.e., the parameter derived from hardness considerations on the underlying computational problem), and let λ denote the statistical security parameter (i.e., a parameter such that events with probability 2^−λ are extremely rare). Both parameters are expressed in unary notation (i.e., 1^σ, 1^λ).

Let F : Dom(F) → CoDom(F) be a function, where Dom(F) denotes F’s domain, CoDom(F) denotes F’s co-domain, and desc(F) denotes F’s description. Assuming desc(F) is known to both C and S, and input x is known only to C, we define a client-server protocol for the delegated computation of F in the presence of an offline phase as a 2-party, 2-phase, communication protocol between C and S, denoted as (C(1^σ, 1^λ, desc(F), x), S(1^σ, 1^λ, desc(F))), and consisting of the following steps:

1. pp ← Offline(1^σ, 1^λ, desc(F)),

2. (y_C, y_S, tr) ← (C(1^σ, 1^λ, desc(F), pp, x), S(1^σ, 1^λ, desc(F)).

As discussed above, Step 1 is executed in an offline phase, when the input x to the function F is not yet available. Step 2 is executed in the online phase, when the input x to the function F is available to C. At the end of both phases, C learns y_C, intended to be = y, and S learns y_S, usually an empty string in this paper. We will often omit desc(F), 1^σ, 1^λ for brevity of description.

Correctness Requirement

Informally, the (natural) correctness requirement states that if both parties follow the protocol, C obtains some output at the end of the protocol, and this output is, with high probability, equal to the value obtained by evaluating function F on C’s input. A formal definition follows.

Security Requirement

Informally, the most basic security requirement would state the following: if C follows the protocol, a malicious adversary corrupting S cannot convince C to obtain, at the end of the protocol, some output y′ different from the value y obtained by evaluating function F on C’s input x. To define a stronger security requirement, we augment the adversary’s power so that the adversary can even choose C’s input x, before attempting to convince C of an incorrect output. We also do not restrict the adversary to run in polynomial time. A formal definition follows.

Privacy Requirement

Informally, the privacy requirement should guarantee the following: if C follows the protocol, a malicious adversary corrupting S cannot obtain any information about C’s input x from a protocol execution. This is formalized here by extending the simulation-based approach typically used in various formal definitions for cryptographic primitives. That is, there exists an efficient algorithm, called the simulator, that generates a tuple of messages distributed exactly like those in a random execution of the protocol. A formal definition follows.

Efficiency Metrics and Requirements

In our analysis, we only consider the most expensive group operations as atomic operations, such as group multiplications and/or exponentiation, and neglect lower-order operations, such as equality testing, additions and subtractions between group elements.

Let (C, S) be a client-server protocol for the delegated computation of function F with computational security parameter σ and statistical correctness parameter λ. We say that (C, S) has efficiency parameters (t_F, t_P, t_C, t_S, sc, cc, mc), if

1. F can be computed (without delegation) using t_F(σ, λ) atomic operations;

2. the offline phase can be run using t_P(σ, λ) atomic operations;

3. C can be run in the online phase using t_C(σ, λ) atomic operations;

4. S can be run using t_S(σ, λ) atomic operations;

5. at the end of the offline phase, data with storage complexity sc is stored on C’s device;

6. C and S exchange a total of at most mc messages; and

7. C and S exchange messages of total length at most cc.

While we naturally try to minimize all these protocol efficiency metrics, our main goal is to design protocols where

1. t_C(σ, λ) < < t_F(σ, λ), and

2. t_S(σ, λ) is not significantly larger than t_F(σ, λ),

based on the underlying assumption, consistent with the state of the art in cryptographic implementations, for essentially all group types, that group multiplication requires significantly less computing resources than group exponentiation.

Formal theorem statement

We obtain the following

The main takeaway from Theorem 4 is that C delegates the computation of product of multiple (i.e. m) exponentiations with a σ-bit exponents to S while C only performs an exponentiation with a λ-bit exponent, 2 group membership verifications in G, 2 multiplications in G and m modular multiplications in ℤ_q. In other words, C’s online complexity is only slightly larger than that in a delegation protocol for a single exponentiation, as in the protocol from [21]. In fact, our protocol can be seen as a non-trivial extension of the single exponentiation protocol in [21], based on two main ideas: (1) using a single small-coefficient linear verification test on the entire product of m exponentiations, instead of an independent test on each of the m exponentiations in the product; and (2) carefully redistributing the computation of products of exponentiation from the client to the server and the offline phase. This results in savings of about a multiplicative factor of m in the client’s online complexity over a direct use of that protocol to delegate a single exponentiation. Using the group in Example 1 from Section 2 for a concrete comparison, the client performs 2λ + m + 4 multiplications, while in a direct use of the protocol in [21] that bound would be 2mλ + 4m, and in non-delegated computation one can perform up to 2mσ + m − 1 multiplications. Using current typical settings in applied cryptography (i.e., σ = 2048, and λ = 128), and assuming m ranging from 2 to 128, we see that in our protocol the client’s online multiplications are smaller by 2-3 orders of magnitude than non-delegated computation and 1-2 orders of magnitude with respect to a direct use of the delegation of a single exponentiation from [21].

Also remarkable are the running time of S, who only performs 2 products of m exponentiations and 2 group membership proof generations in G. In other words, S’s complexity is only about 4 times as that in a non-delegated computation of the same function.

Even in the offline phase, only 2 products of fixed-base exponentiations with random exponents are needed by the client to later compute a product of m fixed-base exponentiations. Finally, the protocol only requires 2 messages, which is clearly minimal in this model, only requires the communication of 4 elements in G and 2m elements in ℤ_q, and only requires that 2m elements in ℤ_q and 2 group values are stored on C’s device at the end of the offline phase.

In what follows we prove Theorem 4 by describing our delegation protocol and proving its properties. The group membership test is realized via the assumed efficiently verifiable group membership protocol. While we do not know of such a protocol for any arbitrary cyclic group, we showed in Section 2 that two groups commonly used in cryptography have one.

Informal description of protocol (C, S)

Our starting point is the protocol for private, secure and efficient delegation of fixed-base exponentiation in cyclic groups in [21], also reviewed in Appendix A. There, one main idea consists of a probabilistic verification equation which is verifiable using a much smaller number of modular multiplications (i.e., up to 2λ, instead of 2σ, multiplications). Specifically, in that protocol, C injects an additional random value b ∈ {1, …, 2^λ} in one of the inputs on which S is asked to computed the value of the exponentiation function F_g,q, so to satisfy the following properties: (a) if S returns correct computations of F_g,q, then C can correctly compute y with a single group multiplication; (b) if S returns incorrect computations of F_g,q, then S either does not meet some deterministic verification equation or can only meet C’s probabilistic verification equation for at most one possible value of random value b; (d) C can check whether the probabilistic verification equation is satisfied with an exponentiation to the (shorter) exponent b; and (d) C’s messages hide the values of the random element as well as C’s input to the function. By choosing a large enough domain for b (e.g., setting λ ≥ 128), the protocol achieves a very small security probability (i.e., 2^−λ). As this domain is much smaller than the group, this results in a considerable efficiency gain on C’s running time.

Towards the design of our protocol proving Theorem 4, a first natural approach is that the client delegates each of the m exponentiations in the product using the delegation protocol for fixed-base exponentiation over cyclic groups in [21], and finally the client computes the product of the obtained m exponentiations. Note that this approach would satisfy correctness, privacy and security requirements. However, when it comes to performance, it is undesirable as it multiplies by a factor of about m both the number of multiplications by the client and the size of the client’s storage, and therefore we would gradually lose the computation benefit from the delegation as m gets larger. In the protocol presented here, we target an additive overhead of m, instead of a multiplicative one, and achieve this with the following two main modifications.

First, we view the probabilistic test of [21] as a small-coefficient linear test over a group value’s exponent. Then, by using the linear homomorphism properties of the exponentiation function, we can define a single small-coefficient linear test on the entire product of m exponentiations, instead of an independent test on each of the m exponentiations in the product. Thus, a single random coefficient value b is used in the protocol, instead of m random and independent values, so that C only performs a single exponentiation to the small exponent b to run the probabilistic verification equation in the resulting small-coefficient linear test.

Second, no products of exponentiations are performed by the client. When these are needed in the protocol, they are carefully redistributed to the computationally more powerful server or to the offline phase, where more computational power is available. Specifically, our protocol involves 4 products of m exponentiations, of which 2 are performed in the offline phase and 2 are computed by the server. Finally, the computation of these products is set up so that by the homomorphism properties of the exponentiation function, analogue group membership verifications and probabilistic verification test can be performed as in the original protocol, although on products of exponentiations instead of single exponentiations.

Formal description of protocol (C, S)

Let G be an efficient cyclic group, and let (mProve, mVerify) denote its efficiently verifiable membership protocol.

Input to C and S: 1^σ, 1^λ, desc(F_g1,…,g_m,q)

Input to C: x₁, …, x_m ∈ ℤ_q

Offline phase instructions:

1. Randomly choose u_i,j ∈ ℤ_q, for i = 1, …, m and j = 0, 1

2. Set vj=∏i=1mgiui,j and store (u_1,j, …, u_m,j, v_j) on C for j = 0, 1

Online phase instructions:

1. C randomly chooses b ∈ {1, …, 2^λ}

    C sets z_i,0 := (x_i − u_i,0) mod q, z_i,1 := (b ⋅ x_i + u_i,1) mod q for i = 1, …, m

    C sends (z_i,0, z_i,1) to S for i = 1, …, m

2. S computes wj:=∏i=1mgizi,j and π_j := mProve(w_j), for j = 0, 1

    S sends w₀, w₁, π₀, π₁ to C

3. C computes y := w₀ * v₀

    C checks that

     w₁ = y^b * v₁, also called the ‘probabilistic test’

     mVerify(w₀, π₀) = mVerify(w₁, π₁) = 1,

      also called the ‘membership test’

    if any one of these tests is not satisfied then

     Creturns: ⊥ and the protocol halts

    Creturns: y

Properties of protocol (C, S)

The efficiency properties are verified by protocol inspection.

1. Round complexity: the protocol only requires one round, consisting of one message from C to S followed by one message from S to C.

2. Storage complexity: at the end of the offline phase, tuples (u_1,j, …, u_m,j, v_j), for j = 0, 1, are stored on C’s device, resulting in a storage complexity of 2m values in ℤ_q and 2 group elements.

3. Communication complexity: the protocol requires the transfer of 2 elements in G and 2 proofs of group membership from S to C, and 2m elements in ℤ_q from C to S.

4. Runtime complexity: During the offline phase, 2 product of m exponentiations in bases g₁, …, g_m and with random σ-bit exponents are performed. This product of m exponentiations can be evaluated using any of the cited literature algorithms for a product of m exponentiations (e.g., the algorithm in [40]). During the online phase, S computes 2 products of m exponentiations to σ-bit exponents in G and 2 group membership proofs; and C verifies 2 group membership proofs and computes 2 multiplications in G, m modular multiplications in ℤ_q, and 1 exponentiation in G to a random exponent that is ≤ 2^λ and thus much smaller than 2^σ.

The correctness property follows by showing that if C and S follow the protocol, C always output y = ∏i=1mgixi. We show that the 2 tests performed by C are always passed. The membership test is always passed since w_j is computed by S as ∏i=1mgizi, for j = 0, 1, and g₁, …, g_m are generators of group G; the probabilistic test is always passed since

This implies that C never returns ⊥, and thus returns y. To see that this returned value y is the correct output, note that

The privacy property of the protocol against any arbitrary malicious S is proved by showing an efficient simulator Sim such that for any input x₁, …, x_m ∈ ℤ_q to C, the following two distributions are equal: the distribution D_prot of the messages in a random execution of (C, S) where C uses x₁, …, x_m as input; and the distribution D_sim output by Sim. First, we observe that C’s only message to S does not depend on values x₁, …, x_m. Specifically, this message can be written as (z_1,0, …, z_m,0, z_1,1, …, z_m,1) where z_i,0 = (x_i − u_i,0) mod q, z_i,1 = (bx_i + u_i,1) mod q, and z_i,0 and z_i,1 are uniformly and independently distributed in ℤ_q, as so are u_i,0 and u_i,1 for all i = 1, …, m. Thus, a simulator Sim can be defined as the algorithm that, on input 1^σ, 1^λ, desc(F_g1,…,gm,q), runs the following instructions:

1. generate a tuple mes1=(z1,0′,…,zm,0′,z1,1′,…,zm,1′) of random and independent values in ℤ_q

2. generate message mes2=(w0′,w1′,π0′,π1′) by running the same instructions run by S on input 1^σ, 1^λ, desc(F_g1,…,g_m,q) and (z1,0′,…,zm,0′,z1,1′,…,zm,1′)

3. return: (mes₁, mes₂)

We obtain that distribution D_Sim and distribution D_prot are identical since in both distributions the first message contains 2m random and independent values in ℤ_q and the second message is computed using the same algorithm starting from first message.

To prove the security property against any malicious S we need to compute an upper bound ϵ_s on the security probability that S convinces C to output a y such that y ≠ F_g1,…,gm,q(x₁, …, x_m). We start by defining the following events with respect to a random execution of (C, S) where C uses x as input:

1. e_y,≠, defined as ‘C outputs y such that y ≠ F_g1,…,gm,q(x₁, …, x_m)’

2. e_w,≠, defined as ‘In its message to C, S sends a pair (w0′,w1′)≠(w0,w1)’

3. e_⊥, defined as ‘C outputs ⊥’

By inspection of (C, S), we directly obtain the following fact.

With respect to a random execution of (C, S) where C uses x₁, …, x_m as input, we now define the following events:

1. e_1,b, defined as ‘∃ exactly one b such that the pair (w0′,w1′) sent by S to C satisfies w1′=(w0′∗v0)b∗v1′

2. e_>1,b, defined as ‘∃ more than one b such that the pair (w0′,w1′) sent by S to C satisfies w1′=(w0′∗v0)b∗v₁ ’.

By definition, events e_1,b, e_>1,b are each other’s complement event.

Now, let i ∈ {1, …, m}. We observe that no information is leaked by z_i,0, z_i,1 about x_i as: (a) for any x_i ∈ ℤ_q, there is exactly one u_i,0 corresponding to z_i,0; that is, u_i,0 = x_i − z_i,0 mod q; (b) for any x_i ∈ ℤ_q, for any b ∈ {1, …, 2^λ} chosen by C, there is exactly one u_i,1 corresponding to z_i,1; that is, u_i,1 = z_i,1 − bx_i mod q for all i = 1, …, m. This implies that, since u_i,0, u_i,1 are uniformly and independently distributed in ℤ_q, the distribution of tuple (x₁, …, x_m) input to C is independent from the distribution of tuple ((z_1,0, z_1,1), …, (z_m,0, z_m,1)) sent by C to S. Furthermore, by essentially the same proof, protocol (C, S) satisfies the following property: for any x₁, …, x_m ∈ ℤ_q, the value of b ∈ {1, …, 2^λ} chosen by C is independent from tuple ((z_1,0, z_1,1), …, (z_m,0, z_m,1)). This implies that all possible values for b in {1, …, 2^λ} are still equally likely even when conditioning over message ((z_1,0, z_1,1), …, (z_m,0, z_m,1)) from C to S. Then, if event e_1,b is true, the probability that the pair (w0′,w1′) sent by S to C satisfies the probabilistic test, is equal to 1 divided by the number 2^λ of values of b that are still equally likely even when conditioning over message (z_1,0, …, z_m,0, z_1,1, …, z_m,1). We obtain the following

We now show the main technical claim, saying that if S is malicious then it cannot produce in step 2 of the protocol a pair of values (w0′,w1′) different than the required pair (w₀, w₁), satisfying both of C’s tests for two distinct values b₁, b₂ ∈ {1, …, 2^λ}. Since S can be malicious, in step 2 it can send arbitrary values to C. In particular, S can send a pair (w0′,w1′) different than the pair (w₀, w₁) required by the protocol, where wj=Πi=1mgzij, for j = 0, 1. Since C uses π₀, π₁ to check in step 3 that the two group elements belong to the group, we can assume that w0′,w1′ ∈ G. Moreover, since G is cyclic, and we assumed that each g_i is generator of G, for i = 1, …, m, we can, without loss of generality, consider generator g₁ and write

Thus, we can also write y=w0′∗v0=g1u∗w0∗v0=g1u∗∏i=1mgixi. Now, recall that the goal of a malicious S is to pass C’s two verification tests and force C’s output to be y≠∏i=1mgixi, which is true when u ≠ 0 mod q. We then consider the following equivalent rewriting of C’s probabilistic test, obtained by variable substitutions and simplifications:

Notice that if u = 0 mod q then the above calculation implies that v = 0 mod q, and thus S is honest, from which we derive that ϵ_s = 0. Now consider the case S is dishonest, in which case we have that u ≠ 0 mod q. We want to show that b is unique in this case. If there exist two distinct b₁ and b₂ such that

then u(b₁ − b₂) = 0 mod q then b₁ − b₂ = 0 mod q (i.e b₁ = b₂) because u ≠ 0 mod q. This shows that b is unique and we obtain the following fact.

The rest of the proof consists of computing an upper bound ϵ_s on the probability of event e_y,≠, using all previously established facts. We obtain the following

where the first inequality follows from Fact 4.1, the first equality follows from the definition of events e_1,b, e_>1,b and the conditioning rule, the second equality follows from Fact 4.3, and the second inequality follows from Fact 4.2.

We can finally set ϵ_s = 2^−λ, which concludes the proof for the security property for (C, S). □

4.1 Performance

A naive algorithm to compute (without delegation) a product of m exponentiations consists of first computing single exponentiations yi=gixi for i = 1, …, m, and then the product ∏i=1myi. For this algorithm, which we call nPoExp, we have that t_prod,m,exp(ℓ) = m ⋅ t_exp(ℓ) + m − 1, which is equal to 2mσ + m − 1, when a single exponentiation is computed using the square-and-multiply algorithm.

Several papers propose faster algorithms to compute single exponentiations (see, e.g., [7, 10, 18, 25, 37, 44]), as well as a product of m exponentiations (see, e.g., [10, 37, 40, 42]). For instance, using the closed-form estimate from [11] of Pippenger’s algorithm in [40], one can obtain an algorithm, which we denote as fPoExp, satisfying t_prod,m,exp(ℓ) ∼ ℓ(1 + m/(log m + log ℓ)).

As yet another comparison method to delegate the computation of a product of m exponentiations to σ-bit exponent, we define protocol nDelPoExp in which a client delegates to a server the computation of each of the m exponentiations using Protocol 1 from [21] and then directly computes a product of the m obtained exponentiations.

In Table 1 we show concrete evaluations for our protocol’s main performance metric: the client’s number t_C of group multiplications in the online phase. In particular, we also compare our protocol with the delegated protocol nDelPoExp and the non-delegated algorithms nPoExp and fPoExp, for computing exponentiation in group Zp∗, for p = 2q + 1, where p, q are primes. First we show the numbers for t_C for varying and arbitrary values of m, while setting σ = 2048 and λ = 128, the currently recommended parameter settings for many cryptographic applications. Then, in the last row we show closed-form expressions for t_C with respect to arbitrary m, σ, λ. We observe that our result’s improvement is significant in many practical parameter settings. For small values of m, our result improves by 1-2 orders of magnitude over the non-delegated algorithms and between a constant factor and 1 order of magnitude over the delegation approach based on [21]. For large values of m, our result improves by at least 3 orders of magnitude over the non-delegated algorithms and at least 2 orders of magnitude over the delegation approach based on [21].

In Table 2 and Table 3 we report performance results measured when running our software implementation of our protocol in Section 4 and of the protocol nDelPoExp in [21] for the multiplicative group (Zp∗, ⋅ mod p), for p = 2q+1, where p, q are large primes, and using σ = 2048 and λ = 128. Our implementation was carried out on a macOS Catalina Version 10.15.1 laptop with 2.9 GHz Intel Core i9 processor with memory 32 GB 2400 MHz DDR4. The protocols were coded in Python 3.7 using the gmpy2 package. In each table we report performance data for one of our protocols, by measuring running times t_F, t_C, t_S, and t_P, and improvement ratio t_F/t_C, for different values of parameter m (i.e., m = 2, 4, 7, 10, 50, 100), and using both an implementation of the modular exponentiation based on the textbook square-and-multiply algorithm (in column labelled ‘SM’) and the Python built-in function gmpy2.powmod (in column labelled ‘NoSM’). Conclusions from our empirical results in Tables 2 and 3 essentially confirm our conclusions from our analytical results in Table 1.

5.1 Definitions: Signature Schemes in the standard model

We now recall the definition of digital signature schemes in the standard (i.e., non-delegated) model.

5.2 Definitions: Delegated Signature Schemes

Given a (non-delegated) signature scheme SS = (KG, Sign, Ver), as defined in Section 5.1, and a delegation protocol (C, S) for a function F, as defined in Section 3, we now formally define an associated delegated signature scheme dSS.

5.3 Delegated Signature Schemes: a general result

We show the relationship between non-delegated signature schemes, delegation protocols and delegated signature schemes in the following theorem.

The main takeaway from Theorem 9 is to provide a shortcut to provably turn a conventional signature scheme into a delegated signature scheme, as defined in Section 5.2: just design a suitable delegation protocol, as defined in Section 3, for a function F of interest in the computation or verification of a signature. In particular, the delegated signature scheme comes with protection of the original signature scheme against more powerful attacks such as eavesdropping on the delegation protocol messages, and querying the server oracle.

Critical to establish the relationship in the theorem is the delegation protocol’s simulation-based privacy property. First of all, we observe that the correctness property of the delegated signature scheme directly follows from the analogue property of the original signature scheme. Then, we show that the unforgeability of the delegated signature scheme follows by the unforgeability of the non-delegated signature scheme and the delegation protocol’s simulation-based privacy property. Specifically, assume an adversary A is able to violate the unforgeability of the delegated signature scheme. One can construct an adversary A′ that violates the unforgeability of the non-delegated signature scheme, as follows:

1. A′ runs algorithm A and processes A’s queries as follows

2. When A queries dSign(pk, sk, ⋅) with message m, A′ does the following:

    A′ queries Sign(pk, sk, ⋅) with message m, thus obtaining signature sig

    A′ runs simulator Sim to obtain the transcripts {tr} containing

     queries to S and replies from S performed during

     the executions of algorithms Sign^S and Ver^S

    A′ simulates the oracle dSign(pk, sk, ⋅)’s answer as (sig, {tr})

3. When A queries S(⋅) with message qmes_C, A′ does the following:

    A′ runs S on input query message qmes_C thus obtaining answer qans_S

    A′ simulates the oracle S(⋅)’s answer as qans_S

We note that the simulation-based privacy of the delegation protocol for F implies that the the success of A′ in breaking SS is the same as the success of A in breaking dSS. The theorem follows.

5.4 Delegating ElGamal, Schnorr and Okamoto’s Schemes

In this section we show delegated signature protocols for 3 well-known signature schemes: those by El Gamal [27], Schnorr [41] and Okamoto [39]. In each case, the delegated signature scheme, denoted as dSS, is obtained by combining the non-delegated signature scheme, denoted as SS and reviewed in Appendix B, with the delegation protocol (C, S) for a product of exponentiations in the associated group, described in Section 4, and then applying Theorem 9. In all considered non-delegated signature schemes, the online complexity of the signature generation and verification process is dominated by a product of 2 or 3 fixed-base exponentiations. In the design of each dSS scheme, we replace each of these products with an execution of protocol (C, S) and also carefully split the signature and verification computations between offline and online phases of the two algorithms. For uniformity of presentation and performance evaluation, both our review of the non-delegated signature scheme in Appendix B and the presentation of our delegated signature schemes in the rest of this section use as example group G = (Zp∗, ⋅ mod p), where p = 2q + 1, for p, q primes. We obtain that with respect to this group, our delegated schemes improve the online complexity of the signature generation and verification process by a factor between 30 and 50 over the non-delegated version and by a factor between 2 and 3 over the delegation approach built on [21], as detailed in Table 4.