An Efficient HPRA-Based Multiclient Verifiable Computation: Transform and Instantiation

Choi, Katz, Kumaresan, and Cid put forward the conception of multiclient noninteractive verifiable computation (MVC), enabling a group of clients to outsource computation of a function of f. CKKC’s MVC is impractical due to their dependence on fully homomorphic encryption (FHE) and garbled circuits (GCs). In this paper, with the goal of satisfying practical requirements, a general transform is presented from the homomorphic proxy re-authenticator (HPRA) of Deler, Ramacher, and Slamanig to MVC schemes. MVC constructions in this particular study tend to be more efficient once the underlying HPRA avoids introducing FHE and GCs. By deploying the transform to DRS’s HPRA scheme, a specific MVC scheme for calculating the linear combinations of vectors has been proposed. It can be understood that it is the first feasible and implementableMVC scheme so far, and the instantiation solution has a great advantage in efficiency compared with related works.


Introduction
e past several years have witnessed a rapid growth of attention on outsourcing computation due to the popularity of cloud computing: the on-demand availability of computer system resources, including data storage and computing power, without maintaining infrastructure by the client. e proliferation of mobile devices is also one of the reasons why outsourced computing is getting more attention.
Outsourcing computation allows relatively weak devices (phones, tablets, laptops, and PCs) to offload work (storage, image processing, and video encoding) to powerful cloud servers. However, many things can (and do) go wrong in cloud computing scenarios. One must worry about bugs, misconfigurations, operator error, natural disasters, or even malicious cloud servers. e servers may have considerable financial incentives to perform dishonestly, and the servers may offer fast but faulty computations to reduce the occupation of computational resources. In the above cases, the client needs some measures to ensure that computation was processed in the expected way and has not been tampered with. Moreover, when the client's data (e.g., function and inputs or/and outputs) are not encrypted, the servers may misuse the data. How to ensure that the correctness of the calculations and how to ensure that the clients' data are not misused are two critical security topics in the outsourcing computation area.
Gennaro et al. [1] proposed the conception of noninteractive verifiable computation (VC) for the single-client scenario. e VC scheme allows client with weak computing power to outsource the computation task of a function f on a set of inputs x 1 , x 2 , . . . , x n to a server, ensuring that client can detect the malicious or malfunctioning server by verifying the results returned, but their efficiency is problematic due to the dependence on expensive cryptographic primitives, for example, fully homomorphic encryption (FHE) and garbled circuits (GCs). e initial proposal and construction of VC led to a long line of follow-up work, which provided further exploration on optimizing the efficiency of outsourced computations for restricted classes of functions. Some researchers extended VC into different scenarios. ere are, however, scenarios in which it would be meaningful to extend this functionality to multiclient case. For example, with limited infrastructure, n resource-constrained nodes cannot directly communicate with each other while are only given access to a central server. It may be desirable for the nodes to get evaluation result of a function f over their joint inputs. At this point, only the central server is responsible for collecting the data and reporting the computation results, thereby letting the nodes to adjust the modalities.
Choi et al. [2] initiated the study of this setting, extending the single-client VC model to the multiclient noninteractive verifiable computation (MVC) model. ey assumed no client-client communication involved and focused on noninteractive solutions, where each evaluation of the function f required only a single round of communication, i.e., noninteractive. In a single round of communication, n clients send the representation of joint inputs (x (1) 1 , . . . , x (1) n ) to the server, and server returns the evaluation result accompanied by a proof. MVC ensures that a malicious server can neither fool any client into accepting a wrong result nor misuse the inputs of the clients. In the scheme, they consider the case where only the first client obtains output (a more general case is dealt with by simply making the clients execute the scheme several times in parallel, with each client playing the role of the first client in one round of execution). ey also presented a construction for outsourcing the evaluation of universal Boolean circuits by integrating the scheme of Gennaro et al. [1] with the proxy oblivious transfer. Since FHE and GCs are still the main technical primitives in their construction, the efficiency issue remains unresolved.
Reducing the use of these expensive cryptographic primitives is necessary for constructing a more practical MVC scheme. Unfortunately, if we are limited to the outsourcing of arbitrary computations on confidential data, then using these primitives is somehow unavoidable. In order to go further in efficiency, we sacrifice the generality of the outsourced functions. is paper is primarily concerned with efficient MVC schemes for specific functions, especially for calculating the linear combination of vectors.

Our Contribution.
e main contributions in this paper are twofold. e first one is a proposal of general transform from the homomorphic proxy re-authenticator (HPRA) [3], a tool providing security and verifiability guarantees to the multiuser data aggregation scenarios, to the MVC schemes. e HPRA makes distinct signers authenticate input data under private keys and allows an aggregator to transform all authenticators into an MAC under the receiver's secret key. e evaluation of a function f on the data along with an aggregate authenticated message vector is computed by the aggregator; therefore, the receiver can verify whether the computation is correct or not. Compared with the MVC, there is an additional receiver in the HPRA that obtains and verifies the function output; by contrast, in the MVC, the first client not only performs verification but also provides its own function input.
A very natural idea is thus generated: what will happen if we map the parties in the HPRA into those in the MVC? Taking into account the different properties and functionalities of all the entities, the first step was to merge the receiver with the first signer in the HPRA and then to consider this merged participant as the first client in the MVC. Second, we consider each of the remaining signers play as a different client in the MVC. ird, we regard the aggregator in the HPRA as a cloud server in the MVC. Following this idea, we construct a general transform that can be applied to any HPRA scheme, resulting in an MVC with the following properties:  [3] to the transform, which allows n clients to jointly outsource the linear combination of n vectors of length ℓ. It can be seen that it is the first time to implement an MVC scheme.
A model was developed by Parno et al. [4] to analyze the efficiency of the computational performance of the FHE + GC-based VC schemes [1,2]. ey estimated that the client would take ≥10 11 seconds to outsource the multiplication of two 100 by 100 matrices in the MVC by Choi et al. [2] as our MVC can also be adjusted to outsource the matrix multiplications as well.
e experimental results show that, in our MVC scheme instance, calculating the multiplication of two 100 by 100 matrices takes only ≈10 3 seconds at the client side. Our proposed scheme evidently has a great advantage in terms of efficiency.

Related Works.
A single-client noninteractive VC model was presented by Gennaro et al. [1], and an instantiation by considering FHE and GCs as main technical tools was constructed. Parno et al. [4] and Setty et al. [5] gave general-purpose VC protocols on the basis of the quadratic arithmetic programs (QAPs) [6]. To provide noninteractive, publicly verifiable computation and zero-knowledge proofs, many recent systems [7][8][9][10] have converged on the Pinocchio protocol [4] as a cryptographic primitive. Benabbas et al. [11] initiated a line of research about efficient protocols for specific functions. Following this line, a series of subsequent outsourcing computations systems [12][13][14][15] developed schemes with improved efficiency for restricted classes of functions. Some research studies [16,17] are dedicated to provide additional security, ensuring that the outsourced polynomial remains hidden.
Choi et al. [2] firstly formed the conception of multiclient noninteractive verifiable computation. In a nutshell, MVC is like VC with an extra feature, allowing multiple clients to jointly outsource a computation under different secret keys. ey also proposed an FHE-based construction for outsourcing the computation of arbitrary Boolean circuits by integrating Gennaro et al.'s scheme [1] with proxy oblivious transfer. However, their scheme still uses FHE and GCs as main technical tools and would thus leave the efficiency problem. Moreover, if a malicious server is allowed to send malformed responses and observe the reaction of the first client, the soundness might be threatened. is problem was resolved by Gordon et al. [18], and they provide solutions against a malicious server or multiple colluding clients. However, as they used the falsifiable assumption which is not as mature as the well-known assumptions such as DLOG, CDH, and DDH, they may have potential weakness. e falsifiable assumption introduced the dependence on the circuit depth, and the efficiency is also sacrificed.
Multi-input functional encryption (MIFE) is a generalization of the functional encryption into the case of multiinput functions. MIFE has a great variety of applications related to computation over the encrypted data from multiple sources. However, the construction of MIFE assumed indistinguishability obfuscation (iO) for circuits, which introduces a strong assumption as the work of Goldwasser et al. revealed [19]. Moreover, current MIFE schemes have prohibitively large overhead. Fiore et al. [20] built a multikey homomorphic authenticator (multikey HA), allowing multiple clients to authenticate and outsource a large collection of data, together with the corresponding authenticators, to a malicious server. Backes et al. [12] added a crucial efficiency property for the verification of multikey HAs. Based on the line of multikey HAs, the HPRA introduced by Derler et al. [3] allows a group of signers to authenticate data under private keys and allows an aggregator to transform all the single authenticators into an MAC under the secret key of receiver. Following this research line of multikey HAs, Schabhüser et al. [21] presented a publicly verifiable homomorphic authenticator scheme with efficient and context hiding verification in the case of multiple clients. However, in their scheme, the result of the outsourced computation is public to all entities, thus leading to privacy breaches.

Organization of the Paper.
e preliminaries, such as MVC and HPRA, are highlighted in Section 2. e HPRA to MVC transform and related security proof are presented in Section 3. A concrete construction is then provided in Section 4. e implementation of concrete instantiation and analysis of results are illustrated in Section 5. Conclusions are drawn based on this particular research in Section 6.

Preliminaries
To facilitate the comprehension of our work, we give some notations and review some preliminaries pertaining to our research work, namely, multiclient noninteractive verifiable computation and homomorphic proxy re-authenticator.

Notation.
e Greek letter κ stands for the security parameter of schemes. A function f(κ) is considered to be negligible in κ if f(κ) � o(κ − c ) under every constant c > 0, and we denote all such functions as negl(κ) and otherwise denoted as non − negl(κ). When a function can be represented as a polynomial, we use the notation poly(· Given a set S, the notation s← R S remains for the process of sampling s from S uniformly.

Multiclient Verifiable Computation.
In an n-party MVC introduced by Choi et al. [2], there are n clients P 1 , P 2 , . . . , P n who expect to outsource the evaluation of some functions over their joint inputs to a server for several times. In the i-th evaluation, client P 1 , P 2 , . . . , P n inputs are denoted as x (i) 1 , x (i) 2 , . . . , x (i) n , respectively. To ensure the data privacy, the clients encode the original inputs into χ (i) 1 , . . . , χ (i) n and send it to a server along with the encoded function Φ of function f. e server is expected to evaluate Φ(χ (i) 1 , . . . , χ (i) n ) and respond with encoded output ω (i) . P 1 is designated to verify the correctness of ω (i) with a decoding secret ξ and restore the real result For the convenience of follow-up research, we made some reasonable modifications to the MVC model: (1) we replace the security parameter 1 κ with public parameter set pp containing the information of 1 κ and the public outsourcing function f. (2) Let P 1 runs KeyGen 1 algorithm first and let pk 1 be one of the inputs of algorithm KeyGen j , for j � 2, . . . , n. As MVC has assumed the existence of a publickey infrastructure (PKI), which makes all the public keys of clients be accessible to all other entities. is change makes other client P j to wait for client P 1 to finish running KeyGen 1 but does not affect security. (3) As EnFunc is run by client P 1 , taking P 1 's private key sk 1 as an extrainput of EnFunc is also reasonable. (i) (pk 1 , sk 1 )←KeyGen 1 (pp). Client P 1 will execute this algorithm on public parameters pp to produce a public key pk 1 and a private key sk 1 .
(ii) (pk j , sk j )←KeyGen j (pp, pk 1 ). For j � 2, . . . , n, client P j will execute this algorithm to produce a public key pk j and a private key sk j . (iii) (ϕ, ξ)←EnFunc(pk �→ , sk 1 , f). Client P 1 will execute this algorithm with pk �→ � (pk 1 , pk 2 , . . . , pk n ) and sk 1 to encode any f ∈ F to an encoded function ϕ and send ϕ to the server. en, Client P 1 will produce a decoding secret ξ and keep it private.
(iv) (χ (i) 1 , τ (i) )←EnInput 1 (i, pk �→ , sk 1 , ξ, x (i) 1 ). When out sourcing the i-th computation to the server, P 1 will execute this algorithm to encode its input x (i) 1 to an encoded input χ (i) 1 and send χ (i) 1 to the server. en, Client P 1 will produce a decoding secret τ (i) and keep it private.
. When outsourcing the i-th computation to the server, each client P j (j ≠ 1) will execute the algorithm to encode its input x (i) j to an encoded input χ (i) j and send χ (i) j to the server. We denote χ . e server will execute the algorithm to obtain an encoded output , ω (i) ). Client P 1 will implement this algorithm to return either an evaluation result or a symbol ⊥ informing that the server returned an incorrect result.
Required by [2,18], an MVC scheme should be correct, sound, and input private. An MVC satisfies the property of correctness if all the involving algorithms are honestly executed; an honest server will always produce output corresponding to the evaluation of f on those inputs and will always pass the verification.
An MVC scheme satisfies the property of soundness if no malicious server can fool clients into obtaining a wrong evaluation on given inputs, even if the server is given access to an oracle, which can generate arbitrary valid input encodings:

Definition 2. (soundness). For scheme Π, consider an experiment Exp sound
A [Π, f, κ, n] with a malicious server A: for j � 1, . . . , n, the public/private key pairs (pk j , sk j ) are produced; an encoded function ϕ and a decoding secret ξ are produced. A is given inputs pk �→ and ϕ and access to Oracle IN and returns a forge ω * . e challenger obtains y * by executing Verify; if is defined to be 1 and 0 otherwise. Scheme Π satisfies the property of soundness if for all n � poly(κ), all functions f ∈ F, and all probabilistic polynomial-time adversary (PPT) adversary A; there is a negligible function negl(·) such that Pr[Exp sound An MVC scheme satisfies the property of input privacy if no information about the inputs is leaked to all the other entities including both server and other clients. While the clients except the first one apparently had no opportunity to learn any information about the others' input data, the input privacy of the MVC scheme includes two properties: privacy against the first client and privacy against the server. Definition 3. (privacy against the first client). e scheme Π achieves the privacy against the first client if for any , the view of P 1 executing Π if all clients holding x → 0 cannot be distinguished from the view of P 1 when executing with all clients holding x → 1 . Privacy against the server requires that the server should not be able to distinguish the encoded inputs from two distinct inputs, even if the malicious server gains access to the Oracle IN.
Definition 4. (privacy against the server). Consider an experiment Exp priv A (Π, f, κ, n, b) with an adversarial server A: for j � 1, . . . , n, the public/private key pairs (pk j , sk j ) are generated, so are an encoded function ϕ and a decoding secret ξ. e adversary A is given inputs pk �→ and ϕ and access to Oracle IN and outputs two series of jointly inputs is computed and given to A. A continues to have oracle access to IN and outputs a guess b ′ of b. e advantage of A in the experiment above is defined as (1) e MVC scheme Π is private against the server if for any n � poly(κ), any function f ∈ F, and any PPTadversary A, there is a negligible function negl(·) such that Adv priv

Homomorphic Proxy Re-Authenticator (HPRA).
e HPRA scheme introduced by Derler et al. [3] consists of nine algorithms: Gen, SGen, VGen, Sign, Verify, SRGen, VRGen, Agg, and AVerify. And there are three types of parties: a set of signers, an aggregator, and a receiver. In a nutshell, HPRA allows n signers to authenticate data items m → 1 , m → 2 , . . . , m → n with signatures under their own distinct keys and allows the aggregator to convert their signatures to one under the receiver's key. e aggregator outputs an aggregate authenticated message vector Λ consists of an evaluation result of function f on the inputs, and a signature corresponds to the result. (i) pp←Gen(1 κ , ℓ): given a security parameter 1 κ and a constant ℓ, the algorithm generates public parameter set pp, which defines a message space M ℓ , a function family F � f|f: (M ℓ ) n ⟶ M ℓ , and a tag space. (ii) (id, sk, pk)←SGen(pp): each signer P i will execute this algorithm on public parameter set pp to output a signer key, including an identifier id, a private key sk, and a public key pk.
(iii) (mk, aux)←VGen(pp): the receiver will execute this algorithm on public parameters pp to obtain an MAC key mk and an auxiliary information aux. (iv) σ←Sign(sk, m → , μ): each signer will execute this algorithm to sign its input m → as a signature σ, which will be sent to the aggregator. For all the signers P 1 , . . . , P n , we denote their signatures as σ → � (σ 1 , . . . , σ n ).
(v) b←Verify(pk, m → , μ, σ): any entity with m → can verify the validation of a signature σ with the algorithm and outputs a bit b← 0, 1 { }. (vi) rk i ←SRGen(sk i , aux): each signer will generate a re-encryption key rk i with the algorithm. (vii) ak i ←VRGen(pk i , mk, rk i ): with this algorithm, an aggregation key ak i can be generated by the receiver, which will be sent to the aggregator.
, μ, f): the aggregator will generate the aggregate authenticated message vector Λ by the algorithm. Let ak : the receiver will generate a pair (m → , μ) with the algorithm and otherwise output (⊥, ⊥) showing that the aggregator tries to cheat.
Required by [3], an HPRA scheme is required to be correct, input private, signer unforgeable, and aggregator unforgeable.
e correctness of an HPRA should meet the requirement that if all the involving algorithms are honestly executed, the aggregate authenticated message vector Λ will always pass the verification and extract the real result of evaluation m . e input privacy of HPRA should meet the requirement that an aggregate authenticated message vector Λ should not leak any more information of the signers' data m n compared with what can be directly speculated from f and the real result of evaluation m → .
Definition 6. (input privacy). e HPRA scheme Σ for F is input private if for any κ ∈ N, any f ∈ F, all tags μ, and all . e following distributions are identical: e signer unforgeability of an HPRA requires that if the aggregator always remains honest, no coalition of dishonest signers can produce a valid Λ with respect to the function f ∈ F such that Λ is outside of the range of f evaluated on arbitrary combinations of the actually signed vectors. e aggregator unforgeability is the natural counterpart of signer Security and Communication Networks unforgeability; if the signers always remain honest, malicious aggregator cannot output a valid aggregate authenticated message vector with respect to the function f, such that the aggregate authenticated message vector is out of the range of f evaluated on the virtually signed vectors.
Let T represent "Signer" or "Aggregator." In both definitions, the adversary gains access to a set O T of oracles, where O T ≔ SG, SKey, SR, VR, A for T � "Signer" and O T ≔ SG, Sig, SR, VR, VRKey for T � "Aggregator." e oracles maintain some sets S, AK, RK, and SIG which are initially empty and work as follows, let i � 1, . . . , n represents the index of client P i , and we do not consider the corruption between the signers: (i) SG(i): works as SGen, sets S[i]←(id, sk, pk) and returns (id, pk). (Σ, κ, n, l) with regard to a PPT adversary A: Public parameter pp is generated by running Gen(1 κ , ℓ); the MAC key and the auxiliary information (mk, aux) are generated by running VGen(pp). A is given inputs pp and aux and access to oracle O T and outputs a forge (Λ ⋆ , ID ⋆ , f ⋆ ).
e challenger carries out AVerify ere is an optional property for HPRA and output privacy, which simulates the situation that the aggregator learns nothing about either the inputs or the function's output. In order to formally give a definition of output privacy, we define an oracle RoS as follows:

The HPRA to MVC Transform
Following the definition in Section 2, some similarities between the two models are figured out through observation: (1) the clients in MVC and signers in HPRA play similar roles in providing inputs; (2) the server in MVC and the aggregator in HPRA play similar roles in computing an encoded output with a corresponding proof; (3) the first client in MVC and the receiver in HPRA play similar roles in extracting the evaluation result and verifying its correctness. A very straightforward idea is that we can achieve the goal of transforming HPRA to MVC by constructing a mapping of the participants in the two schemes as follows, which can be depicted in Figure 3: (1) let the aggregator in HPRA take over the work of the server in MVC; (2) merge the receiver with the first signer in HPRA, and let this merged participant take over the work of the first client in MVC; (3) let each of the rest signers play a different client in MVC.
Let Σ � (Gen, SGen, VGen, Sign, Verify, SRGen, VRGen, Agg, AVerify)⊲ be an HPRA scheme for a function family F. e general transform from Σ to Π � ( KeyGen j n j�1 , EnFunc, EnInput j n j�1 , EnInput j n j�1 , Compute, Verify), an MVC scheme for F, will be explained in elaborate as follows. Let pp←Σ.Gen (1 κ , ℓ) be a set of public parameters. In the proposed MVC scheme, we consider the computation of a function f on inputting is a vector over a finite field of each client P j .
On inputting private key sk j and auxiliary information aux, client P j executes signer's re-key generation algorithm Σ.SRGen (sk j , aux) and obtains a re-encryption key rk j . Client P j individually sets pk j � (id j , pk j , rk j ), sk j � sk j . (iii) (ϕ, ξ)←EnFunc(pk �→ , sk 1 , f). For j � 1 . . . n, takes a public key pk j and the private key sk 1 of client P 1 , client P 1 executes Σ.VRGen(pk j , mk, rk j ) and obtains an aggregation key ak j . Client P 1 sets the encoded function ϕ � (f, ak �→ ) and the decoding secret ξ � ∅.
. When out sourcing the i-th computation to the server, it takes a time period i, the public keys pk �→ , the private key sk 1 of client P 1 , an input message vector x →(i) 1 , the decoding secret ξ, the first client P 1 gets a tag μ ∈ G, executes the sign algorithm Σ.Sign(sk 1 , x →(i) 1 , μ), gets a signature σ 1 , and sets . When outsourcing the i-th computation to the server, each client P j takes a time period i, the public keys pk �→ , the signer secret key sk j of client P j , and input message vector x →(i) j ; P j (with j ≠ 1) obtains a tag μ ∈ G, and then he executes the algorithm Σ.Sign(sk j , x →(i) j , μ), gets signature σ j , and sets . Given the public keys pk �→ , the encoded function ϕ, and the encoded inputs χ →(i) , the server executes the algorithm μ, ϕ), gets aggregate authenticated message vector Λ, and sets ω (i) � Λ.
. Take the public keys pk �→ , the decoding secrets (ξ, τ (i) ), and an encoded output ω (i) as inputs, and the first client P 1 executes the receiver's verification algorithm Σ.AVerify(mk, Λ, ID, f) which outputs pair of message vector and tag (m → , μ), on success, and (⊥, ⊥) otherwise. Set y (i) � m → and otherwise return ⊥ informing that the server tries to cheat.
Scheme Π should satisfy the properties of correctness, soundness, and privacy. While the correctness is quite obvious, we start with soundness.

Proof.
is study demonstrates that if there is a probabilistic polynomial-time (PPT) adversary A for which break soundness (Definition 2) of Π and let Pr[Exp sound A [Π, f, κ, n] � 1] ≥ non − negl(κ). A PPT adversary B can be constructed that breaks the T-unforgeability (Definition 7) of Σ for T � "Aggregator." B is given inputs (1 κ , n, ℓ) and an oracle O T ≔ SG, Sig, SR, VR, VRKey , and its goal is to output a forge that can successfully convince the challenger. In detail, the following holds: (1) e challenger executes pp←Gen(1 κ , ℓ), (mk, aux) ←VGen(pp) and sends pp and aux to B. (2) For j � 1, . . . n, B queries the following oracles and obtains (id j , pk j )←SG(j), rk j ←SR (j); B also queries the oracle VR(j) to produce ak j and queries ak j ←VRKey(j). (3) B then sets pk 1 � (id 1 , pk 1 , aux, rk 1 ); for j � 2 . . . n, pk j � (id j , pk j , rk j ), ϕ � (f, ak), and sends them to A. Let f be the function on which A can break MVC soundness. (a) Set i ≔ i + 1.

Security and Communication Networks (c) Query and get
, and at least one x → j has not been queried by A in the i-th query or 2. f ⋆ ( x → 1 , . . . , x → n ) ≠ m → ) outputs 1 and otherwise outputs 0.
A PPT adversary A will find a ω ⋆ such that the challenger gets y * ∉ ⊥, f( x →(i) 1 , . . . , x →(i) n ) when running Verify if A is considered to be able to break Π with non-negl(κ) As Π.Verify in our transform directly calls Σ.AVerify, if such a ω * is produced, B can directly consider ω * as an input of Σ.AVerify. Clearly, if A can cheat Π.Verify and make Exp sound en, we successfully construct such an adversary B who breaks T-unforgeability when T � "Aggregator" with non-negl(κ): However, it has been proved that Σ is a T-unforgeable HPRA [3], which contradicts our derivation; that is, soundness is guaranteed in MVC based on the T-unforgeability of HPRA.
where σ → 1 is the signatures of (m . Since the first client P 1 has no other opportunity to access information from all other entities when performing Σ, except when running the algorithm Verify: P 1 obtains an encoded output ω (i) , which may reveal some information. As a result, it is only necessary to prove that the distributions below are identical:  [Σ, κ, n, ℓ]: (1) e challenger carries out pp←Gen(1 κ , ℓ), (mk, aux)←VGen(pp) and selects a random bit b← 0, 1 { } and then returns pp and aux to B.
, B answers the queries as follows:  (iii) While A gives a bit b 1 to B, B outputs 1, if b 0 � b 1 ; otherwise, B outputs 0.
Intuitively speaking, when b 0 � b 1 , A outputs a successful guess b ′ � b of which one of the inputs x 0 , x 1 is signed, then B guesses that its challenge string given by RoS(b) must be a signature and outputs a guess b ′ � 1 of b. Otherwise, while if A does not succeed, B guesses that its challenge string given by RoS(b) must be random and generates a guess bit b ′ � 0 of b. When the privacy against the server (Definition 3) of Π against A does not hold, we have

then the view of A when runs as a subroutine by B is indistinguishable to the view of A in experiment Exp
A string of random numbers is encrypted by RoS(b) when b � 1, then the view of A when runs as a subroutine by B is indistinguishable to the view of A in an experiment of guessing random numbers. us, Considering the above two equations, because the challenger chooses b randomly, Pr[b � 0] � Pr[b � 1] � (1/2), if adversary A can break the privacy against the server and B can determine whether its challenge string is a true signature or a random string with probability:

Security and Communication Networks
Pr

(9)
But the output privacy has been confirmed [3], which leads to a contradiction. In other words, privacy against the server is guaranteed in our MVC scheme based on the output privacy of HPRA.

A Concrete Instantiation
To explain our transform in more detailed way, we give a concrete instantiation. Essentially, we build an MVC for the family of linear function F over Z q based on a concrete HPRA scheme 4 in [3].

Bilinear Map.
Let G 1 � 〈g 1 〉, G 2 � 〈g 2 〉, and G T � 〈g〉 be cyclic groups of prime order q. Let g 1 , g 2 be generators of groups G 1 and G 2 , respectively, and a paring e: G 1 ×G 2 ⟶ G T is a bilinear map if the following features hold: For simplicity, assuming there is a symmetric bilinear map such that G 1 � G 2 � 〈g〉. Let BG←BGGen(1 κ ) be a bilinear group generation algorithm, and the output BG is the generator (g, g) of G and G T with a bilinear pairing e: G × G ⟶ G T . [3] is said to be an input private, T-unforgeable, and output private HPRA scheme. ey allow the signer to report an encrypted data with its signature under their own keys; the aggregator re-encrypts the ciphertexts and converts them to the ciphertexts under the receiver's key and homomorphically evaluates the function f on ciphertexts.

Overview of a Detailed HPRA Scheme. Scheme 4 in
For more details, to achieve the output privacy and the homomorphism, they employ an ElGamal-like encryption scheme: encode message x ∈ Z q into the exponent and encrypt g x . One can decrypt and get x ′ � g x and then additionally compute x � log g x ′ to obtain x, with size of the message space being polynomial in security parameter κ. As one can verify the guesses for signed messages using solely the signatures, they blind signer P j 's signature with a random element g r j . Unfortunately, because of some flaws in this scheme, even if the aggregator performs honestly, the evaluation result still cannot pass AVerify; that is, the Scheme 4 in [3] is not a correct HPRA scheme.
We slightly modified Scheme 4 in [3] and turned it into a correct HPRA scheme: we blinded the input od signer P j with a random element g r j instead of blinding signer of P j with a random element g r j and prevented verifying guesses for signed messages as well. It has been proven that the revised HPRA scheme still maintains input privacy, T-unforgeability, and output privacy (see Appendix A for more details of the origin scheme 4 in [3] and how we revised it; Appendix B gives the security proof ).

e Construction.
We describe n clients where each client P j holds an ℓ-length input ) ∈ (Z q ) ℓ and a tag μ ∈ G which is related to the set of inputs. Here, f is a linear function represented by its coefficient (q 1 , . . . , q n ). It is worth noting that when the inputs of f are vectors, e.g., given n ℓ-length input vectors , we define f as a function calculated column by column, that is, An additional symbol is placed at the end of the ciphertext to indicate the state of the ciphertext: "1" stands for first-level ciphertext, which is not allowed to re-encrypt, "2" stands for second-level ciphertext, which is allowed to be reencrypted, and "R" means that this ciphertext has already been re-encrypted. In this instantiation, we describe the process for one time period i to simplify.
(a) On inputting public parameter pp, client P 1 randomly chooses a vector a q , and β 1 ← R Z q yields an identifier and a public/private key pair set: (b) e first client P 1 randomly chooses α← q and obtains an MAC key mk and the auxiliary information aux: (c) Client P 1 obtains the re-encryption key rk 1 � ((g b 1 ) a ). (d) Client P 1 sets and outputs: pk 1 � id 1 , pk 1 , aux, rk 1 , (2) (pk j , sk j )←KeyGen j (pp, pk 1 ).
(a) On inputting public parameter pp, client P j randomly chooses a q , and β j ← R Z q produces an identifier and a public/private key pair set: (b) For j � 2, . . . , n, client P j obtains the re-encryption key rk j � (g b 1 a ). (c) Client P j sets and outputs: pk j � id j , pk j , rk j , sk j � sk j .
τ as mk, let y → � (y 1 , y 2 , . . . , y ℓ ) denote the result of For t � 1, . . . , ℓ, the server calculates g y t and g r as follows: (b) Solving the discrete log problem and return y → if the following equation holds and ⊥ otherwise:

Correctness.
We now present the proof of the correctness, if the server runs Compute honestly, the result will pass Verify. We start with showing an honest server do return expected y → � f( x → 1 , . . . , x → n ), according to the equation (29), for t � 0, . . . , ℓ: and, for g r in equation (29), we can also do the same calculation as above and find g r � n j�1 g r j q j . Client P 1 requires an alternative decryption strategy for the vector components (g y 1 , . . . , g y ℓ , g r ), as r is uniformly chosen in Z q and can thus not be efficiently recovered, when decrypting the vector components (g y 1 , . . . , g y ℓ , g r ), and client P 1 cannot directly obtain the plaintext. Fortunately, obtaining r ∈ Z q is unnecessary, and it is sufficient to unblind the signature by g r (resp., g r ). We now present the left side and the right side of the equation (30) always keeps equal as long as the server remains honest. Here, we reemphasize that g t is randomly chosen from G and do not mix it up with the generator g of group G T e left-hand side of the equation (30) is equal to and the right-hand side of the equation (30) is equal to We can clearly find that the two sides of the equation (30) are equal and thus conclude that our detailed construction meets the correctness definition. Furthermore, following the security proof of general construction, the detailed construction is a sound, private against the first client, and private against server MVC scheme.

Implementation
To measure the performance of our transform, we implement concrete instantiation described in Section 5 and conduct a variant of experiments and focus on evaluating the performance overhead. All the experiments are run on a PC with an Intel Core i7-4790K CPU running at 3.60 GHz and 8 GB of RAM on ubuntu-16.04.1. e implementation is in C with the help of PBC (pairing-based cryptography) library, which is designed to be the backbone of implementations of pairing-based cryptosystems [22]. More specifically, we use the symmetric pairings constructed on the curve y 2 � x 3 + x over the field F q for some prime q � 3 mod 4 with |q| � 512.

Client Computation.
Following the theoretical analysis, the length ℓ of the input vector, the maximum size x max of the input vector element (any element in the input vector x j →(i) of client P j is smaller than 2 x max ), and the number of clients n in total largely influence the runtime of the algorithms. We give some notations for the basic cost units of our protocol: (Mul G /Mul G T ) represents the runtime of a multiplication in (G/G T ). (Exp G /Exp G T ) represents the runtime of an exponentiation in (G/G T ). Pair G represents the runtime of a pairing in G. Log represents the runtime of solving a discrete log problem.
Key generation.
e key generation process includes both KeyGen 1 and KeyGen j . We theoretically analyzed the computational performance of our key generation process, which is shown in Table 1. Figure 4 depicts the key generation process cost for our scheme, and we set the maximum size x max of input vector element to a fixed size 20 bits and observe how the total number n and the length ℓ of the input vector affect the performance: (i) When n remains constant, the runtime of the key generation process changes uniformly with respect to ℓ. (ii) When ℓ remains constant, the runtime of the key generation process changes uniformly with respect to n. (iii) Compared to n, ℓ can determine the runtime to a greater extent.
Function encoding. We did not conduct the experimental analysis of function encoding process which only contains EncFunc, and as shown in Table 1, the runtime changes uniformly with respect to the total number of the clients. Input encoding. We did not conduct the experimental analysis of clients' encoding process which only contains EnInput, as shown in Table 1, and the runtime changes uniformly with respect to the length ℓ of the input vector. e algorithm Verify, involving computing discrete logarithm, is the only step in the verification process. Pollard's kangaroo algorithm [29] is the known fastest algorithm to solve the discrete logarithm problem for a general elliptic curve, and the time complexity is ).
x is the size of the input number of Pollard's kangaroo algorithm, which is mainly determined by the maximum size x max of input vector element. Based on the theoretical analysis in Table 1, we can find that the verification process requires a total of ℓ discrete logarithmic calculations. We fix n to 2 as it has relatively small influence on runtime, and the algorithm performance on different x max and ℓ is given in Figure 5 with log 2-type Y axis: (i) When x max remains constant, the runtime of verification process increases along with ℓ. (ii) When ℓ remains constant, the runtime of verification process increases along with x max . (iii) e increase in x max has a greater impact on the runtime of verification process than the increase in ℓ.
Note that each ℓ discrete logarithm is computed separately; as a consequence, the ℓ computation can be parallelized and will greatly save the client's runtime. However, as we assume that clients are usually devices with limited computing power, performing parallel computation is obviously against our assumptions, so we do not implement Verify algorithm in parallelized way.

Server Computation.
As server only carries out Compute, the experiments of the server's runtime focus on the parameters influence on the efficiency of Compute. We fix x max to 20 bits for simplicity, and the results plotted in Figure 6 and Table 1 show the server's runtime in relation to the total number n of the clients and the input vector length ℓ: (i) When n is fixed, the server's runtime increases along with the length ℓ. (ii) When ℓ is fixed, the server's runtime increases along with total number n of the clients.
Security and Communication Networks 13

Efficiency Analysis.
e client computation overhead may be even higher than that of the server in some cases. According to both theoretical and experimental analyses, we show how to avoid these inefficiencies and under what circumstances an instance can be regarded as an efficient solution. Assume that the computational complexity of all group operations is constant and that x max + log 2 n − 1 is the expected length of the evaluation results of the linear combinations of the n clients' input vector with the maximum element size x max . We hope that the runtime of any client in the scheme will be less than that of the server; however, client P 1 runs most algorithms on the client side. Here, we denote the computational complexity of P 1 as T client : T client � 12ℓ + 5n + 12 + ℓ ������������� x max + log 2 n − 1, T client ≤ 7n +(4n − 1)ℓ − 1.

(34)
By the above inequality, one can indicate that when n becomes sufficiently large and x max stays rather small, the runtime required on the server side will exceed the runtime required on the client side, and the gap will become more significant as n grows. Although the runtime of both sides is O(n), the coefficient of n on the server side is obviously larger and hence more sensitive to the increase in n. We fixed ℓ to 128 and let x max be rather small, i.e., 20 bits. ese theoretical analyses correspond well with the experimental results shown in Figure 7.

Performance
Relative to Prior Scheme. Parno et al. [4] built a model to estimate the performance of FHE + GCbased VC schemes according to the results for FHE [30]. Because of the similarities between FHE + GCs based VC     and MVC, we can likewise use the method to estimate the performance of MVC.
Parno et al. [4] used multiplication of two (t × t) matrices M 1 and M 2 as test application, and each component in M 1 and M 2 is at most 32 bits. As the multiplication of two (t × t) matrices can be viewed as (t × t) linear combinations of vectors with length t, we set both the clients' number n and the length ℓ of the input vectors to t, and let the maximum size x max of input vector elements equal to 32 bits in order to construct an MVC with the same computational scaling as above. We plot the time complexity for the verification process in Figure 8. roughout the results, it can be observed that our scheme significantly improves performance and can be considered applicable in a practical setting.

Conclusions
We combined MVC with an efficient cryptographic protocol HPRA by providing a general transform. We also gave and implemented a concrete instantiation of MVC scheme for outsourcing the linear combinations of vectors over a finite field. e instantiation and implementation could give the way for the future research on the designs and optimizations of outsourcing computation. Our implementation requires solving discrete logarithm problem. How to avoid the usage of these expensive operations is an open question for further research. ′ i∈[n] , f).