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

Abstract Many public-key cryptosystems and, more generally, cryptographic protocols, use group exponentiations as important primitive operations. To expand the applicability of these solutions to computationally weaker devices, it has been advocated that a computationally weaker client (i.e., capable of performing a relatively small number of modular multiplications) delegates such primitive operations to a computationally stronger server. Important requirements for such delegation protocols include privacy of the client’s input exponent and security of the client’s output, in the sense of detecting, except for very small probability, any malicious server’s attempt to convince the client of an incorrect exponentiation result. Only recently, efficient protocols for the delegation of a fixed-based exponentiation, over cyclic and RSA-type groups with certain properties, have been presented and proved to satisfy both requirements. In this paper we show that a product of many fixed-base exponentiations, over a cyclic groups with certain properties, can be privately and securely delegated by keeping the client’s online number of modular multiplications only slightly larger than in the delegation of a single exponentiation. We use this result to show the first delegations of entire cryptographic schemes: the well-known digital signature schemes by El-Gamal, Schnorr and Okamoto, over the q-order subgroup in ℤp, for p, q primes, as well as their variants based on elliptic curves. Previous efficient delegation results were limited to the delegation of single algorithms within cryptographic schemes.


Introduction
Delegation of cryptographic operations is an active research direction addressing the problem of computationally weaker clients delegating the most expensive cryptographic computations to computationally powerful servers. Recently, this area is seeing an increased interest because of shifts in modern computation paradigms towards cloud computing, edge computing, large-scale computations over big data, and computations with low-power devices, such as RFIDs.
The first formal model for delegation of cryptographic operations (also called outsourcing of cryptographic operations, server-aided cryptography, and server-assisted cryptography) was introduced in [31], where the authors especially studied the case of modular exponentiation, as this operation is a cornerstone of so many cryptographic schemes and protocols. In this model, we have a client, with an input x, who delegates to one or more servers the computation of a function F on the client's input, and the main desired requirements are: 1. privacy: only minimal or no information about x should be revealed to the server(s); 2. security: the server(s) should not be able, except possibly with very small probability, to convince the client to accept a result different than F(x); and 3. efficiency: the client's computation time should be much smaller than computing F(x) without delegating the computation.
Moreover, in all previous work in the area, the computational weakness of the client is really only restricted to the online phase and relatively expensive o ine computation can be performed and stored on the client's device, say, at client deployment time. For instance, towards a delegated computation of modular exponentiation, it seems reasonable to assume that even computationally weaker devices are or will soon be able to perform a moderate number of less expensive operations like modular multiplications (see, e.g., recent advances in [1], showing how to practically implement group multiplication, for a specific group, and a related public-key cryptosystem, using RFID tags). This computation gap between servers and clients is significant in that with currently recommended parameter settings an unoptimized single exponentiation may require, on average, more than 2000 multiplications. Examples of computationally weaker devices provided in [31] include RFID tags, embedded devices, and, more generally, low-resource devices, but we note that the delegation problem is actually meaningful in any application domain where clients with server access would rather reduce their computation workload. In [31], the authors studied delegation of modular exponentiation to 2 servers of which at most one was malicious, and to 1 server, who was honest on almost all inputs. Recently, we solved the open problems of private, secure and efficient delegation to a single, possibly malicious, server, of a single fixed-based exponentiation in cyclic groups [21] and a single fixed-exponent exponentiation in RSA-type groups [22]. We showed delegation for these exponentiation functions over a more general class of groups in [19], however with slightly worse efficiency or security properties than in [21,22]. Previously, in [13], we had also showed private, secure and efficient delegation to a single, possibly malicious, server, of group inverses, without need for an o ine phase.
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 Zp, 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 Zp 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 Zp, 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.

Definitions: Groups with Eflcient Membership Proofs
In this section we formally define group notations and definitions that will be used in the rest of the paper.
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 1 , . . . , gm. By y = g x1 1 · · · g xm m = ∏︀ m i=1 g x i i we denote the product of m (fixed-base) exponentiations (in G). Let Zq = {0, 1, . . . , q − 1}, and let Fg 1 ,...,gm ,q : (Zq × ... × Zq) → G denote the function that maps to each (x 1 , . . . , xm) ∈ Zq × ... × Zq the product of m (fixed-base) exponentiations (in G). By desc(Fg 1 ,...,gm ,q) we denote a conventional description of the function Fg 1 ,...,gm ,q that includes its semantic meaning as well as generators g 1 , . . . , gm, order q and the efficient algorithms computing multiplication and inverses in G.
By texp(ℓ) 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 tm,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 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).
Example 1: (G, *) = (Gq , · mod p), for large primes p, q such that p = kq + 1, where k ≠ q is another prime and Gq is the q-order subgroup of Z * p . This group is one of the most recommended for cryptographic schemes like the Diffie-Hellman key exchange protocol [23], El-Gamal encryption [27], Cramer-Shoup encryption [17], DSA etc. It is known that by Sylow's theorem, Gq in this case is the only subgroup of order q in the group Z * p (i.e. g q = 1 mod p if and only if g ∈ Gq). Also, the set of elements of Gq is precisely the set of k-th powers of elements of Z * p . Thus, an efficiently verifiable membership protocol can be built as follows: 1. on input w, mProve computes r = w (q+1)/k mod p and returns r; 2. on input w, r, mVerify returns 1 if w = r k mod p and 0 otherwise.
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 = 2), 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).
Example 2: (G, +) = (E(Fp), point addition), for a large prime p > 3: an elliptic curve E over a field Fp, is the set of pairs (x, y) ∈ E(Fp) that satisfy the Weierstrass equation together with the imaginary point at infinity O, where a, b ∈ Fp and 4a 3 +27b 2 ≠ 0 mod p. The elliptic curve defined above is denoted by E (Fp). This group is one of the most recommended for cryptographic schemes like Elliptic-curve Diffie-Hellman key exchange protocol, Elliptic-curve ElGamal encryption, etc. Moreover, many discrete logarithm based cryptographic protocols defined over the set Zp in Example 1 can be rewritten as defined over E(Fp). When those protocols are rewritten using the additive operation for this group instead of modular multiplication over Zp, the multiplication operation is rewritten as point addition and the exponentiation is rewritten as scalar multiplication in the group E(Fp), and the textbook "square-andmultiply" algorithm becomes a "double-and-add" algorithm. An efficiently verifiable membership protocol for this group simply consists of verifying the Weierstrass equation, as follows: 1. on input (x, y), mProve does nothing; 2. on input (x, y), mVerify returns 1 if y 2 = x 3 + ax + b mod p and 0 otherwise.
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.

Definitions: Delegated Protocols
In this section we formally define delegation protocols, and their correctness, security, privacy and efficiency requirements, mainly relying on the definition approach from [21], which in turn builds on those from [29,31].
One new aspect in our definition, of interest for our results in later sections, is that we use a simulation-based definition of privacy instead of the indistinguishability-based definition in [21].
Basic notations. The expression y ← T denotes the probabilistic process of randomly and independently choosing y from set T. The expression y ← A(x 1 , x 2 , . . .) denotes the (possibly probabilistic) process of running algorithm A on input x 1 , x 2 , . . . and any necessary random coins, and obtaining y as output. The expression (z A , z B , tr) ← (A(x 1 , x 2 , . . .), B(y 1 , y 2 , . . .)) denotes the (possibly probabilistic) process of running an interactive protocol between A, taking as input x 1 , x 2 , . . . and any necessary random coins, and B, taking as input y 1 , y 2 , . . . 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 1 ; . . . ; Rn : x}, where R 1 , . . . , Rn 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 o ine 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 o ine 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: As discussed above, Step 1 is executed in an o ine 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.

Definition 1.
Let σ, λ be the security parameters, let F be a function, and let (C, S) be a client-server protocol for the delegated computation of F. We say that (C, S) satisfies δc-correctness if for any for some δc close to 1, where experiment CorrExp is detailed below: then return: 1 else return: 0 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.

Definition 2.
Let σ, λ be the security parameters, let F be a function, and let (C, S) be a client-server protocol for the delegated computation of F. We say that (C, S) satisfies ϵs-security against a malicious adversary if for any algorithm A, it holds that for some ϵs close to 0, where experiment SecExp is detailed below: then return: 0 else return: 1.

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.

Definition 3.
Let σ, λ be the security parameters, let F be a function, and let (C, S) be a client-server protocol for the delegated computation of F. We say that (C, S) satisfies privacy (in the sense of simulation) against a malicious adversary if there exists an efficient algorithm Sim such that for any efficient adversary A and any input x to C, the following two distributions are equal: 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 o ine 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 o ine 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 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.

Delegating a Product of Exponentiations
In this section we present our protocol for delegation of a product of (fixed-base) exponentiations in a large class of groups used in cryptographic protocols, which provably satisfies correctness, simulation-based privacy, security with exponentially small probability, and various desirable efficiency properties. Most notably, the client's online complexity is dominated by a single exponentiation to a significantly smaller exponent.
We first formally state our result, then describe the protocol, and finally prove its correctness, security, privacy and efficiency properties.
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 Zq. 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 o ine 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 o ine 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 Zq, and only requires that 2m elements in Zq and 2 group values are stored on C's device at the end of the o ine 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 Fg,q, so to satisfy the following properties: (a) if S returns correct computations of Fg,q, then C can correctly compute y with a single group multiplication; (b) if S returns incorrect computations of Fg,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 o ine phase, where more computational power is available. Specifically, our protocol involves 4 products of m exponentiations, of which 2 are performed in the o ine 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. Online phase instructions: i and π j := mProve(w j ), for j = 0, 1 S sends w 0 , w 1 , π 0 , π 1 to C 3. C computes y := w 0 * v 0 C checks that w 1 = y b * v 1 , also called the 'probabilistic test' mVerify(w 0 , π 0 ) = mVerify(w 1 , π 1 ) = 1, also called the 'membership test' if any one of these tests is not satisfied then 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 Zq, 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 = ∏︀ m i=1 g x i i . 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 ∏︀ m i=1 g z i i , for j = 0, 1, and g 1 , . . . , gm 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 1 , . . . , xm ∈ Zq 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 1 , . . . , xm 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 1 , . . . , xm. 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 Zq, 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(Fg 1 ,...,gm ,q), runs the following instructions: 1. generate a tuple mes 1 = (z ′ 1,0 , . . . , z ′ m,0 , z ′ 1,1 , . . . , z ′ m,1 ) of random and independent values in Zq 2. generate message mes 2 = (w ′ 0 , w ′ 1 , π ′ 0 , π ′ 1 ) by running the same instructions run by S on input 1 σ , 1 λ , desc(Fg 1 ,...,gm ,q) and (z ′ 1,0 , . . . , z ′ m,0 , z ′ 1,1 , . . . , z ′ m,1 ) 3. return: (mes 1 , mes 2 ) 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 Zq 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 ≠ Fg 1 ,...,gm ,q(x1 , . . . , xm). We start by defining the following events with respect to a random execution of (C, S) where C uses x as input: e y,≠ , defined as 'C outputs y such that y ≠ Fg 1 ,...,gm ,q(x1 , . . . , xm)' -e w,≠ , defined as 'In its message to C, S sends a pair (w ′ 0 , w ′ 1 ) ≠ (w 0 , w 1 )' -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 1 , . . . , xm as input, we now define the following events: 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 ∈ Zq, 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 ∈ Zq, 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 Zq, the distribution of tuple (x 1 , . . . , xm) 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 1 , . . . , xm ∈ Zq, 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 (w ′ 0 , w ′ 1 ) 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 (w ′ 0 , w ′ 1 ) different than the required pair (w 0 , w 1 ), satisfying both of C's tests for two distinct values b 1 , b 2 ∈ {1, . . . , 2 λ }. Since S can be malicious, in step 2 it can send arbitrary values to C. In particular, S can send a pair (w ′ 0 , w ′ 1 ) different than the pair (w 0 , w 1 ) required by the protocol, where w j = Π m i=1 g z ij , for j = 0, 1. Since C uses π 0 , π 1 to check in step 3 that the two group elements belong to the group, we can assume that w ′ 0 , w ′ 1 ∈ 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 1 and write Thus, we can also write . 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 ≠ ∏︀ m i=1 g x i i , 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 1 and b 2 such that 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).

Performance
A naive algorithm to compute (without delegation) a product of m exponentiations consists of first computing single exponentiations y i = g x i i for i = 1, . . . , m, and then the product ∏︀ m i=1 y i . For this algorithm, which we call nPoExp, we have that t prod,m,exp (ℓ) = m · texp(ℓ) + m − 1, which is equal to 2mσ + m − 1, when a single exponentiation is computed using the square-and-multiply algorithm.
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 Z * p , 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 (Z * p , · 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 Table 2: Performance of the protocol when σ = 2048, λ = 128 and group G = Z * p where p = 2q + 1 where p and q are primes. Table 3: Performance of the protocol using [21] of protocol nDelPoExp when σ = 2048, λ = 128 and group G = Z * p where p = 2q + 1 where p and q are primes.
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.

Delegating Signature Schemes
In this section we show private, secure and efficient delegation schemes for well-known (i.e., ElGamal, Schnorr and Okamoto's) signature schemes using the delegation of a product of (fixed-base) exponentiation for cyclic groups from Section 4. We start the presentation by recalling in Section 5.1 the definition of signature schemes in the standard (i.e., non-delegated) model. In Section 5.2 we augment this definition so to additionally take into account eavesdropping and oracle query attacks in the delegated model. Then, in Section 5.3 we present a general result that shows how to convert signature schemes in the non-delegated model into signature schemes in the delegated model by using a suitable delegation protocol. Finally, in Section 5.4 we show delegated ElGamal, Schnorr and Okamoto's signature schemes by simply showing modification to the original algorithms where signers and/or verifiers use the delegated protocol for computing a product of exponentiations. The proof that these modifications result in correct, secure and private delegated signature schemes directly follows from our general result in Section 5.3.

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

Notations and algorithm syntax. An oracle, denoted as O(·), is a function. An oracle algorithm, denoted as A O(·)
, is an algorithm that during its computation can repeatedly make a query to the oracle and obtain the corresponding oracle's output.
In a signature scheme SS, we consider two types of parties: signers and verifiers, and three algorithms: a key-generation algorithm KG, a signing algorithm Sign, and a verification algorithm Ver, satisfying the following syntax and requirements.
On input a security parameter 1 σ , algorithm KG returns a public key pk and a matching secret key sk. On input a message m of arbitrary length, algorithm Sign returns a signature sig. On input a putative message m ′ , and a putative signature sig ′ , algorithm Ver returns a bit = 1 (resp., 0) to denote that sig ′ is a valid (resp., not valid) signature of m ′ .
Requirements: Correctness and Unforgeability. Informally speaking, the correctness requirement states that if both signer and verifier correctly run the algorithms, the verifier can recognize the signer's signature as valid; and the unforgeability requirement states that no efficient algorithm querying the signature oracle can produce a message with a valid signature. Formal definitions follow. (m ′ , sig ′ ) ← A Sign(pk,sk,·) (pk) 3. Let Q be the set of message queries made by A to oracle Sign(pk, sk, ·) 4. if m ′ ∈ Q or Ver(pk, sk, m ′ , sig ′ ) = 0 then return: 0 else return: 1.

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.
Notations and algorithm syntax. We consider three parties: a signer, a verifier, and a server, where during their computations the signer and/or the verifier may act as clients interacting with the server. Since in this paper we only use one-round client-server delegation protocols, we first model the server as an oracle that answers client queries, and then model the signer and verifier's interactions with the server as calls to the server oracle.
For each one-round delegation protocol (C, S) for a function F, we define an (F, C, S)-associated server oracle, denoted as S(desc(F), 1 σ , 1 λ , ·), as the oracle taking as query input C's message in (C, S) and returning as output the server S's response to this message according to protocol (C, S).
An oracle signature algorithm, denoted as Sign S , is defined as an algorithm with the same syntax as signature algorithm Sign, but with the additional capability of making queries to an oracle S. Analogously, an oracle verification algorithm, denoted as Ver S , is defined as an algorithm with the same syntax as a verification algorithm Ver, but with the additional capability of making queries to an oracle S. An oracle signature scheme is defined as a signature scheme (KG,Sign S ,Ver S ) where signature and verification algorithms are actually oracle signature and oracle verification algorithms, capable of querying the same oracle S. We then say that an oracle signature scheme (KG,Sign S ,Ver S ) is (F, C, S)-compatible if oracle signing algorithm Sign S and oracle verification algorithm Ver S are semantically equivalent to the signature algorithm Sign and the verification algorithm Ver from SS, in the sense that on the same input, the final output from Sign S and Ver s is identical to the output from Sign and Ver, respectively (but in the middle of its computation, Sign S and Ver S may also perform queries to S). Finally, we formally define the (SS,F, C, S)-compatible delegated signature scheme dSS as the tuple (S, KG, Sign S , Ver S ), where S is the (F, C, S)-associated server oracle and (KG,Sign S ,Ver S ) is the (F, C, S)-compatible oracle signature scheme.
In our formal description of the protocols, we will actually separate algorithms Sign S and Verify S into an o ine-phase and online-phase version, for the purpose of minimizing the online complexity; however, to reduce notation in the description of the model, in this subsection we keep both o ine and online version as a single algorithm.
Requirements: Correctness and Unforgeability. The requirements of correctness and unforgeability for dSS are also obtained by suitably augmenting those for SS. In the case of correctness, the extension is immediate. In the case of unforgeability, we replace the adversary A's oracle Sign with two oracles: 1. an augmented oracle dSign(pk, sk, ·) which, on input message m, returns a signature sig as well as the transcript of any query/answer interaction with the server oracle S performed by Sign during the generation of sig; 2. the server oracle S(desc(F), 1 σ , 1 λ , ·), which, on input C's query message qmes C , returns S's response to qmes C in an execution of protocol (C,S).
Note that by giving the adversary access to oracle dSign, we model the adversary's eavesdropping attacks on executions of the delegation protocol between a signer (acting as client) and the server, as well as between a verifier (acting as client) and the server. Moreover, by giving the adversary access to oracle S, we model the adversary's interaction with the server while colluding with a signer or verifier. Formal definitions of correctness and unforgeability requirements for dSS follow.

Definition 8.
Let F be a function, and (C, S) be a delegation protocol for F, and let S be the (F, C, S)associated server oracle. We say that the (SS,F, C, S)-compatible delegated signature scheme dSS = (S, KG, Sign S , Ver S ) satisfies existential ϵ-unforgeability under chosen message attack (briefly, ϵ-cma-EU) if for any efficient oracle algorithm A, it holds that for some ϵ close to 0, where experiment SecExp is detailed below: (m ′ , sig ′ ) ← A dSign(pk,sk,·),S(·) (pk) 3. Let Q be the set of message queries made by A to oracle dSign(pk, sk, ·) 4. if m ′ ∈ Q or Ver S (pk, sk, m ′ , sig ′ ) = 0 then return: 0 else return: 1.

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.
Theorem 9. Let F be a function, and (C, S) be a delegation protocol for F, and let S be the (F, C, S)associated server oracle. Also, let SS = (KG,Sign,Ver) be a (non-delegated) signature scheme and let dSS = (S,KG,Sign S ,Ver S ) be the (F, C, S)-compatible delegated signature scheme. If SS satisfies δ-correctness and ϵ-unforgeability under chosen message attack, then dSS satisfies δ ′ -correctness and ϵ ′ -unforgeability under chosen message attack, for δ ′ = δ and ϵ ′ = ϵ.
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.

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 o ine 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 = (Z * p , · 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. Table 4: Comparison of the number of C's online multiplications in non-delegated and delegated versions of signature schemes in [27,39,41], all defined in group G = (Z * p , · mod p), where p = 2q + 1, and p, q are primes. Delegated El Gamal Signature Scheme. Let (C, S) be the client-server protocol from Section 4 for the delegation of the function Fg 1 ,g2,q computing the product of two exponentiations over group G. Also, by (C inv , S inv ) we denote the client-server protocol from Section 3 of [13] for the delegation of the function computing an inverse of an element in Zq. Finally, let H denote a cryptographic hash function. Our delegated version of the signature scheme in [27] goes as follows.
1. Key generation: Let g be a generator of the q-order subgroup of group G. Randomly choose x ∈ {0, . . . , q − 1} and set y := g x mod p. The public key is (p, q, g, y) and the private key is x.

5.
Online Verifying: on input a public key (p, q, g 1 , g 2 , t, v), o ine output pp, a message m, and signature (e, y 1 , y 2 ), set x 1 = y 1 , x 2 = y 2 , x 3 = e, query S with inputs g 1 , g 2 and g 3 = v, and use S's reply to compute the product π. Finally, check that H(π, m) = e mod p.

Conclusions
We considered the problem of delegating the computation of a product of group exponentiations to a single, possibly malicious, server. We solved this problem by showing a protocol that provably satisfies formal correctness, privacy, security and efficiency requirements, in a large class of cyclic groups; specifically, cyclic groups whose multiplication and inverse operations can be efficiently computed, and which admit an efficiently verifiable protocol to prove that an element is in the group. The considered class of cyclic groups includes groups often discussed in cryptography literature, such as prime-order subgroups in Zp and elliptic curve groups.
As an application, we showed the first private, secure and efficient delegated (to a single, possibly malicious, server) versions of an entire cryptographic scheme. Previous research only achieved these properties for delegation of a single operation in a scheme's algorithm. Specifically, we showed delegated versions of well-known signature schemes whose most expensive computations could be rephrased as products of exponentiations over cyclic groups. This implies that in any delegated model of computation, certain well-known signature schemes can be run with improvements of 1-2 orders of magnitude in the online runtime for the entire signature generation and verification process.
Moreover, we believe that our methods provide hope towards private, secure and efficient delegation of more complex cryptographic protocols to a single, possibly malicious, server.

A Delegation of a Single Fixed-Base Exponentiation
Let (G, *) be a cyclic group having order q, efficient operation, efficiently computable inverses, and an efficiently verifiable membership protocol, denoted as (mProve, mVerify). Let g be a generator for G, and denote as y = g x a (fixed-base) exponentiation (in G). Let Zq = {0, 1, . . . , q − 1}, and let Fg,q : (Zq × ... × Zq) → G denote the function that maps to each x ∈ Zq a fixed-base exponentiations (in G). By desc (Fg,q) we denote a conventional description of the function Fg,q that includes its semantic meaning as well as generator g, order q and the efficient algorithms computing multiplication and inverses in G. The delegation protocol for a single fixed-base exponentiation in G was formally defined in [21] as follows.

B Non-Delegated Signature Schemes
We review non-delegated signature schemes from [27,39,41], all defined using group G = (Zp , · mod p), where p = 2q + 1, for p, q primes. We note that G has a q-order subgroup with an easily computable generator (e.g., any quadratic residue modulo p different than 1).