Abstract
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 . 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 implementable MVC scheme so far, and the instantiation solution has a great advantage in efficiency compared with related works.
1. Introduction
The 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. The 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. The 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. The VC scheme allows client with weak computing power to outsource the computation task of a function on a set of inputs 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). The 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. There are, however, scenarios in which it would be meaningful to extend this functionality to multiclient case. For example, with limited infrastructure, 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 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. They assumed no client-client communication involved and focused on noninteractive solutions, where each evaluation of the function required only a single round of communication, i.e., noninteractive. In a single round of communication, clients send the representation of joint inputs 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). They 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. This paper is primarily concerned with efficient MVC schemes for specific functions, especially for calculating the linear combination of vectors.
1.1. Our Contribution
The main contributions in this paper are twofold. The 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. The 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. The evaluation of a function 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. Third, 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:(i)No malicious server can generate an incorrect output passing the verification of the client, except with a nonnegligible probability.(ii)For each client, any information on the client’s input should not be leaked to the other entities.(iii)No malicious server can learn anything about the result of the computation beyond what the description of would leak.(iv)There is no client-client communication, and all the involved parties do not share a secret key. As an alternative, the clients use independent private keys generated by themselves to encrypt and authenticate the data.(v)Compared with the HPRA, no extracomputational consumption is introduced. Our MVC construction has nothing to do with FHE and GCs as long as the underlying HPRA avoids introducing these expensive cryptographic primitives.(vi)Compared with the HPRA, no extracryptographic assumption is introduced. Our MVC construction relies only on the assumptions required in the HPRA.
The second contribution is an MVC scheme implementable by applying a particular HPRA scheme of Derler et al.’s [3] to the transform, which allows clients to jointly outsource the linear combination of 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]. They estimated that the client would take seconds to outsource the multiplication of two by matrices in the MVC by Choi et al. [2] as our MVC can also be adjusted to outsource the matrix multiplications as well. The experimental results show that, in our MVC scheme instance, calculating the multiplication of two by matrices takes only seconds at the client side. Our proposed scheme evidently has a great advantage in terms of efficiency.
1.2. 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–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–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. They 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. This 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. The 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 multi-input 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.
1.3. Organization of the Paper
The preliminaries, such as MVC and HPRA, are highlighted in Section 2. The HPRA to MVC transform and related security proof are presented in Section 3. A concrete construction is then provided in Section 4. The implementation of concrete instantiation and analysis of results are illustrated in Section 5. Conclusions are drawn based on this particular research in Section 6.
2. 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.
2.1. Notation
The Greek letter stands for the security parameter of schemes. A function is considered to be negligible in if under every constant , and we denote all such functions as and otherwise denoted as . When a function can be represented as a polynomial, we use the notation . For any , we refer to as . We use to denote a vector and to denote a sequence of vectors . For vectors with subscript in their variable name, say , we use to indicate the -th element in vector . Given a set , the notation remains for the process of sampling from uniformly.
2.2. Multiclient Verifiable Computation
In an -party MVC introduced by Choi et al. [2], there are clients who expect to outsource the evaluation of some functions over their joint inputs to a server for several times. In the -th evaluation, client inputs are denoted as , respectively. To ensure the data privacy, the clients encode the original inputs into and send it to a server along with the encoded function of function . The server is expected to evaluate and respond with encoded output . is designated to verify the correctness of with a decoding secret and restore the real result from .
For the convenience of follow-up research, we made some reasonable modifications to the MVC model: (1) we replace the security parameter with public parameter set containing the information of and the public outsourcing function . (2) Let runs algorithm first and let be one of the inputs of algorithm , for . As MVC has assumed the existence of a public-key infrastructure (PKI), which makes all the public keys of clients be accessible to all other entities. This change makes other client to wait for client to finish running but does not affect security. (3) As is run by client , taking ’s private key as an extrainput of is also reasonable.
Definition 1. (MVC). An -party MVC scheme ) for a function family consists of algorithms as follows and in Figure 1:(i) Client will execute this algorithm on public parameters to produce a public key and a private key .(ii) For , client will execute this algorithm to produce a public key and a private key .(iii) Client will execute this algorithm with and to encode any to an encoded function and send to the server. Then, Client will produce a decoding secret and keep it private.(iv) When out sourcing the -th computation to the server, will execute this algorithm to encode its input to an encoded input and send to the server. Then, Client will produce a decoding secret and keep it private.(v) When outsourcing the -th computation to the server, each client () will execute the algorithm to encode its input to an encoded input and send to the server. We denote .(vi). The server will execute the algorithm to obtain an encoded output .(vii). Client 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 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:(i)(ii);(iii)record ;(iv);(v)for ;(vi)output
Definition 2. (soundness). For scheme , consider an experiment with a malicious server : for , the public/private key pairs are produced; an encoded function and a decoding secret are produced. is given inputs and and access to and returns a forge . The challenger obtains by executing ; if , the output of is defined to be and otherwise. Scheme satisfies the property of soundness if for all , all functions , and all probabilistic polynomial-time adversary (PPT) adversary ; there is a negligible function such that
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). The scheme achieves the privacy against the first client if for any with , the view of executing if all clients holding cannot be distinguished from the view of when executing with all clients holding .
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 .
Definition 4. (privacy against the server). Consider an experiment with an adversarial server : for , the public/private key pairs are generated, so are an encoded function and a decoding secret . The adversary is given inputs and and access to and outputs two series of jointly inputs . The challenge ciphertext is computed and given to . continues to have oracle access to and outputs a guess of . The advantage of in the experiment above is defined asThe MVC scheme is private against the server if for any , any function , and any PPT adversary , there is a negligible function such that
2.3. Homomorphic Proxy Re-Authenticator (HPRA)
The HPRA scheme introduced by Derler et al. [3] consists of nine algorithms: , , , , and . And there are three types of parties: a set of signers, an aggregator, and a receiver. In a nutshell, HPRA allows signers to authenticate data items with signatures under their own distinct keys and allows the aggregator to convert their signatures to one under the receiver’s key. The aggregator outputs an aggregate authenticated message vector consists of an evaluation result of function on the inputs, and a signature corresponds to the result.
Definition 5. (HPRA). A homomorphic proxy re-authenticator scheme is composed of nine polynomial-time algorithms as follows and demonstrated in Figure 2.(i): given a security parameter and a constant , the algorithm generates public parameter set , which defines a message space , a function family , and a tag space.(ii): each signer will execute this algorithm on public parameter set to output a signer key, including an identifier , a private key , and a public key .(iii): the receiver will execute this algorithm on public parameters to obtain an MAC key and an auxiliary information .(iv): each signer will execute this algorithm to sign its input as a signature , which will be sent to the aggregator. For all the signers , we denote their signatures as .(v): any entity with can verify the validation of a signature with the algorithm and outputs a bit .(vi): each signer will generate a re-encryption key with the algorithm.(vii): with this algorithm, an aggregation key can be generated by the receiver, which will be sent to the aggregator.(viii): the aggregator will generate the aggregate authenticated message vector by the algorithm. Let .(ix): the receiver will generate a pair 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.
The 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 .
The input privacy of HPRA should meet the requirement that an aggregate authenticated message vector should not leak any more information of the signers’ data compared with what can be directly speculated from and the real result of evaluation .
Definition 6. (input privacy). The HPRA scheme for is input private if for any , any , all tags , and all and with , all , all , for , , , and . We denote QUOTE . The following distributions are identical:The 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 such that is outside of the range of evaluated on arbitrary combinations of the actually signed vectors. The aggregator unforgeability is the natural counterpart of signer unforgeability; if the signers always remain honest, malicious aggregator cannot output a valid aggregate authenticated message vector with respect to the function , such that the aggregate authenticated message vector is out of the range of evaluated on the virtually signed vectors.
Let represent “” or “.” In both definitions, the adversary gains access to a set of oracles, where for T = “” and for T = “.” The oracles maintain some sets , , , and which are initially empty and work as follows, let represents the index of client , and we do not consider the corruption between the signers:(i): works as , sets and returns .(ii): returns .(iii): works as , sets for , returns and . Let .(iv): works as , returns .(v): works as but without returning anything, sets .(vi): returns .(vii): works as , returns .
Definition 7. (-unforgeability). For the HPRA scheme , consider an experiment with regard to a PPT adversary : Public parameter is generated by running ; the MAC key and the auxiliary information are generated by running . is given inputs and and access to oracle and outputs a forge . The challenger carries out and obtains ; if and , it outputs 1 and otherwise outputs 0. The HPRA scheme is -unforgeable; if for all PPT adversaries , there is a negligible function such that
There 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 as follows:(i): If , it returns . Otherwise, it samples uniformly at random, and if , for , it computes . Else, it randomly chooses , and for , it computes and returns .
Definition 8. (output privacy). For the HPRA scheme , assuming an experiment with a PPT adversaries : public parameter is gained by executing , the MAC key, and the auxiliary information are gained by executing . is given input and access to oracle . A random bit is chosen by the challenger, and a challenge ciphertext is computed and given to . continues to have oracle access to QUOTE and outputs a guess of .
An HPRA for a family of function classes is output private; if for all PPT adversaries , there is a negligible function such that .
3. 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 be an HPRA scheme for a function family . The general transform from to , an MVC scheme for , will be explained in elaborate as follows. Let be a set of public parameters. In the proposed MVC scheme, we consider the computation of a function on inputting , where is a vector over a finite field of each client .(i). On inputting public parameter , client executes HPRA’s signer’s key generation algorithm and obtains an identifier and a public/private key pair . Client runs receiver’s key generation algorithm. gets an MAC key and auxiliary information . On private key and auxiliary information , client executes signer’s re-encryption key generation algorithm , and obtains re-encryption key . Client sets , .(ii). On inputting public parameter and client ’s public key , for , each client executes HPRA’s signer’s key generation algorithm and obtains an identifier and a public/private key pair . On inputting private key and auxiliary information , client executes signer’s re-key generation algorithm and obtains a re-encryption key . Client individually sets , .(iii). For , takes a public key and the private key of client , client executes and obtains an aggregation key . Client sets the encoded function and the decoding secret .(iv). When out sourcing the -th computation to the server, it takes a time period , the public keys , the private key of client , an input message vector , the decoding secret , the first client gets a tag , executes the sign algorithm , gets a signature , and sets , .(v). When outsourcing the -th computation to the server, each client takes a time period , the public keys , the signer secret key of client , and input message vector ; (with ) obtains a tag , and then he executes the algorithm , gets signature , and sets .(vi). Given the public keys , the encoded function , and the encoded inputs , the server executes the algorithm , gets aggregate authenticated message vector , and sets .(vii). Take the public keys , the decoding secrets , and an encoded output as inputs, and the first client executes the receiver’s verification algorithm which outputs pair of message vector and tag , on success, and otherwise. Set 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.
Theorem 1. (soundness). If is a -unforgeable HPRA scheme, where T = “,” then described above is a sound MVC scheme.
Proof. This study demonstrates that if there is a probabilistic polynomial-time (PPT) adversary for which break soundness (Definition 2) of and let . A PPT adversary can be constructed that breaks the -unforgeability (Definition 7) of for T = “.” is given inputs and an oracle , and its goal is to output a forge that can successfully convince the challenger. In detail, the following holds: (1)The challenger executes , and sends and to .(2)For , queries the following oracles and obtains , ; also queries the oracle to produce and queries .(3) then sets ; for , , , and sends them to . Let be the function on which can break MVC soundness.(4) initializes a counter .(5)Whenever queries its encryption Oracle with inputs , answers the queries as follows:(a)Set .(b)Record .(c)Query and get . Let , and denote .(d)Set and return .(6)When outputs , sets and sends to the challenger, where , .(7)The challenger executes the algorithm .(8)If and (i.e., 1. , and at least one has not been queried by in the -th query or 2. ) outputs 1 and otherwise outputs 0.A PPT adversary will find a such that the challenger gets when running if is considered to be able to break with - As in our transform directly calls , if such a is produced, can directly consider as an input of . Clearly, if can cheat and make , can definitely also fool and let equal to . Then, we successfully construct such an adversary who breaks -unforgeability when T = “” with -:
However, it has been proved that is a -unforgeable HPRA [3], which contradicts our derivation; that is, soundness is guaranteed in MVC based on the -unforgeability of HPRA.
Theorem 2. (privacy against the first client). If is an input private HPRA scheme, then is an MVC scheme with the privacy against the first client.
Proof. The privacy against the first client (Definition 3) can be directly derived from the input privacy of HPRA. Recall Definition 6, an HPRA scheme is called input private if for all and , where , and the following distributions are identical:where is the signatures of from and is the signatures of from .
Recall Definition 3; an MVC scheme is called privacy against the first client if the view of the first client when executing with clients holding inputs is distributed identically from the view of the first client when running with clients holding inputs .
Since the first client has no other opportunity to access information from all other entities when performing , except when running the algorithm : obtains an encoded output , which may reveal some information. As a result, it is only necessary to prove that the distributions below are identical:Let be the encoded inputs of , generated by and . And let be the encoded inputs of , generated by and . Without loss of generality, we set and , be any two vectors with the same first component such that at the same time. Intuitively speaking, both and directly call the algorithm , except that returns additionally; in other words, and . Furthermore, calls , and and are calculated exactly in the same way as in the definition of input privacy of HPRA, i.e., and . Because of the input privacy of HPRA, and are identical. As a result, privacy against the first client of MVC scheme is guaranteed.
Theorem 3. (privacy against the server). If is an output private HPRA scheme, then will be an scheme with the privacy against the server property.
Proof. If there is a PPT adversary for which privacy against the server of (Definition 4) on function does not hold, then a PPT adversary that breaks the output privacy of (Definition 8) can be constructed. is given inputs and access to an oracle . We follow the assumption of MVC that all the clients are honest but curious, and we do not consider corrupted client situation. In detail, the following holds:(i)(1)The challenger carries out , and selects a random bit and then returns and to .(2)For , queries the oracles and obtains , . also queries the oracle to yield , and queries .(3) then sets , for , , , and sends them to . Let be the function on which can break the MVC soundness.(4) initializes a counter .(5)When queries the encryption oracle with inputs , answers the queries as follows:(a)Set .(b)Record .(c)Query the oracle and obtain .(d)Let and return to .(ii)When outputs , , picks a random bit and works as follows: Queries and gets . Returns the challenge ciphertext to .(iii)While gives a bit to , outputs , if ; otherwise, outputs .Intuitively speaking, when , outputs a successful guess of which one of the inputs is signed, then guesses that its challenge string given by must be a signature and outputs a guess of . Otherwise, while if does not succeed, guesses that its challenge string given by must be random and generates a guess bit of . When the privacy against the server (Definition 3) of against does not hold, we haveWithout loss of generality, let be bigger than .
As is encrypted by when , then the view of when runs as a subroutine by is indistinguishable to the view of in experiment . As a result,Because is randomly picked by , , we haveA string of random numbers is encrypted by when , then the view of when runs as a subroutine by is indistinguishable to the view of in an experiment of guessing random numbers. Thus,Considering the above two equations, because the challenger chooses randomly, , if adversary can break the privacy against the server and can determine whether its challenge string is a true signature or a random string with probability: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.
4. 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 over based on a concrete HPRA scheme 4 in [3].
4.1. Bilinear Map
Let , , and be cyclic groups of prime order . Let be generators of groups and , respectively, and a paring is a bilinear map if the following features hold:(i)Bilinearity: for any and .(ii)Nondegeneracy: .(iii)Computability: there is an efficient algorithm to compute for any inputs , .
For simplicity, assuming there is a symmetric bilinear map such that . Let be a bilinear group generation algorithm, and the output is the generator of and with a bilinear pairing : .
4.2. Overview of a Detailed HPRA Scheme
Scheme 4 in [3] is said to be an input private, -unforgeable, and output private HPRA scheme. They 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 on ciphertexts.
For more details, to achieve the output privacy and the homomorphism, they employ an ElGamal-like encryption scheme: encode message into the exponent and encrypt . One can decrypt and get and then additionally compute to obtain , 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 ’s signature with a random element . Unfortunately, because of some flaws in this scheme, even if the aggregator performs honestly, the evaluation result still cannot pass ; 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 with a random element instead of blinding signer of with a random element and prevented verifying guesses for signed messages as well. It has been proven that the revised HPRA scheme still maintains input privacy, -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).
4.3. The Construction
We describe clients where each client holds an -length input and a tag which is related to the set of inputs. Here, is a linear function represented by its coefficient . It is worth noting that when the inputs of are vectors, e.g., given -length input vectors , we define 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: “” stands for first-level ciphertext, which is not allowed to re-encrypt, “” stands for second-level ciphertext, which is allowed to be re-encrypted, and “” means that this ciphertext has already been re-encrypted. In this instantiation, we describe the process for one time period to simplify.
We fix a hash function : , which can later be used as a public random oracle. We also choose and publish the public parameter :(1).(a)On inputting public parameter , client randomly chooses a vector , and yields an identifier and a public/private key pair set:(b)The first client randomly chooses , and obtains an MAC key and the auxiliary information :(c)Client obtains the re-encryption key .(d)Client sets and outputs:(2).(a)On inputting public parameter , client randomly chooses , and produces an identifier and a public/private key pair set:(b)For , client obtains the re-encryption key .(c)Client sets and outputs:(3).(a)On inputting , public parameter , MAC key , and function , for , client obtains aggregation key .(b) sets and outputs:(4). Client randomly chooses , parses as , parses as , and randomly chooses .(a)Client computes :(b)Client computes the encryption which consists of components, denoted as . The first component: The following components to are covered by and random number , such that for all : The -th component in contains the information of random number instead of an element in : Client sets the last component , in order to remark the state of the cipher text: is a second-level ciphertext:(c)Sets and outputs .(5). For , client parses as , parses as , and randomly chooses .(a)Client computes:(b)Client computes the encryption which consists of components, denoted as The first component: The following components to are information of covered by and a random number , such that for all : The -th component in contains the information of a random number instead of : Client sets the last component to remark the state of the ciphertext: is a second-level ciphertext.(c)Sets , outputs , and denotes .(6). Parses as , parses as , parses for as , parses as .(a)For , the server computes a re-encryption of the client ’s ciphertext which consists of components, denoted as . The server first calculates pairings between and each component of and set the -st to -th components to be the pairing result, that is, for all : For , the server directly sets Server sets to remark the state of the ciphertext, where the is a re-encrypted ciphertext.(b)After the server finished the above for each , where , the server begins to evaluate the function on these re-encrypt ciphertext, and the evaluation is denoted as . For and , the server calculates the -th power of . Puts all these powered components together and considers it as a matrix, and the server gets a -length vector by adding the components of the matrix in each column such that for all : The server sets the last component in order to remark the state of the ciphertext, where the new vector denoted as is a re-encrypted ciphertext.(c)The server computes with , where(d)The server sets and outputs .(7). Parses as , as , let denote the result of evaluated by the server, and let denote the random element evaluated by the server.(a)If the last component of is label “,” the first client decrypts and obtains and otherwise. For , the server calculates and as follows:(b)Solving the discrete log problem and return if the following equation holds and otherwise:
4.4. Correctness
We now present the proof of the correctness, if the server runs honestly, the result will pass . We start with showing an honest server do return expected , according to the equation (29), for :and, for in equation (29), we can also do the same calculation as above and find .
Client requires an alternative decryption strategy for the vector components , as is uniformly chosen in and can thus not be efficiently recovered, when decrypting the vector components , and client cannot directly obtain the plaintext. Fortunately, obtaining is unnecessary, and it is sufficient to unblind the signature by (resp., ). 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 re-emphasize that is randomly chosen from and do not mix it up with the generator of group The left-hand side of the equation (30) is equal toand 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.
5. 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. The 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 over the field for some prime with .
5.1. Client Computation
Following the theoretical analysis, the length of the input vector, the maximum size of the input vector element (any element in the input vector of client is smaller than ), and the number of clients in total largely influence the runtime of the algorithms. We give some notations for the basic cost units of our protocol: represents the runtime of a multiplication in . represents the runtime of an exponentiation in . represents the runtime of a pairing in . represents the runtime of solving a discrete log problem. . The key generation process includes both and . 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 of input vector element to a fixed size bits and observe how the total number and the length of the input vector affect the performance:(i)When 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 .(iii)Compared to , can determine the runtime to a greater extent. . We did not conduct the experimental analysis of function encoding process which only contains , and as shown in Table 1, the runtime changes uniformly with respect to the total number of the clients. . We did not conduct the experimental analysis of clients’ encoding process which only contains , as shown in Table 1, and the runtime changes uniformly with respect to the length of the input vector. The algorithm , 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 . is the size of the input number of Pollard’s kangaroo algorithm, which is mainly determined by the maximum size 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 to as it has relatively small influence on runtime, and the algorithm performance on different and is given in Figure 5 with -type axis:(i)When remains constant, the runtime of verification process increases along with .(ii)When remains constant, the runtime of verification process increases along with .(iii)The increase in 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.
5.2. Server Computation
As server only carries out , the experiments of the server’s runtime focus on the parameters influence on the efficiency of . We fix to bits for simplicity, and the results plotted in Figure 6 and Table 1 show the server’s runtime in relation to the total number of the clients and the input vector length :(i)When is fixed, the server’s runtime increases along with the length .(ii)When is fixed, the server’s runtime increases along with total number of the clients.
5.3. Analysis and Comparison
5.3.1. Efficiency Analysis
The 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 is the expected length of the evaluation results of the linear combinations of the clients’ input vector with the maximum element size . We hope that the runtime of any client in the scheme will be less than that of the server; however, client runs most algorithms on the client side. Here, we denote the computational complexity of as :
By the above inequality, one can indicate that when becomes sufficiently large and 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 grows. Although the runtime of both sides is , the coefficient of on the server side is obviously larger and hence more sensitive to the increase in . We fixed to and let be rather small, i.e., bits. These theoretical analyses correspond well with the experimental results shown in Figure 7.
5.3.2. Performance Relative to Prior Scheme
Parno et al. [4] built a model to estimate the performance of FHE + GC-based 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 matrices and as test application, and each component in and is at most bits. As the multiplication of two matrices can be viewed as linear combinations of vectors with length , we set both the clients’ number and the length of the input vectors to , and let the maximum size of input vector elements equal to 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. Throughout the results, it can be observed that our scheme significantly improves performance and can be considered applicable in a practical setting.
6. 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. The 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.
Appendix
A. Details of the Modification to Scheme 4 in [3]
Intuitively speaking, Scheme 4 in [3] combines their HPRA scheme, Scheme 2 without output privacy with a homomorphic proxy re-encryption scheme (HPRE), and Scheme 3 to construct an output private scheme which consists of nine algorithms as follows:(i) fix an for class and from Scheme 2 such that , run and output .(ii) run , and output .(iii): carry out , and output .(iv) parse as , choose , and output , where(v) parse as and as . Obtain and and return .(vi) parse as and as , obtain , and return .(vii): for , parse as and as . Output , where(viii): parse as (, ) and as , get and return if the following holds and otherwise:
Because one can verify guesses for the signed messages only according to the signatures, the signature of signer is blinded with a random element by setting . According to the definition of and , we know that returns if and only if the following equation holds:
We can see that , where , is multiplied on the left-hand side of equation (A.4) to eliminate the effect of the random elements . Here, we offer more details on the calculation of both sides of equation (A.4). For the sake of simplicity, takes , and then, the left-hand side is equal to
The right-hand side of the equation (A.4) is equal to
The two sides of equation (A.4) are not equal, thus Scheme 4 does not meet the correctness definition. The equation will be equal if the last term on the left-hand side becomes . However, this is unreasonable, as is part of the -th signer’s private key while is run by the receiver.
To fix this flaw, we blind the input of with a random element by the set , instead of blinding the signature of with a random element , and prevent the verification of guesses for signed messages as well. In this way, the evaluation of items related to random elements and items related to inputs are consistent, which makes the item related to on the left side of equation (A.4) become and removes . In detail, we modify , , and as follows:
(i) parse as , select , and output , where(ii): for parse as , as . Return , where(iii): parse as (, ) and as , get , and return if the equation as follows holds and otherwise:
B. Proof of Security
We have already proved the correctness in Section 5, so we omit it here. Now we need to prove that this modified HPRA still maintains input privacy, -unforgeability, and output privacy.
In fact, input privacy, aggregator unforgeability, and output privacy are not affected by the modification. Our blinding approach extends the vector with the element ; i.e., the second input of changes from to , which certainly does not affect these properties. The input privacy of the output private HPRA can be reduced to the input privacy of Scheme 2 [3].
The -unforgeability is the only property that may be affected, more precisely, aggregator unforgeability. Since signing an input vector or signing an extending input vector with and random element , do not influence the signer unforgeability.
The -unforgeability of the output private HPRA can be reduced to the aggregator unforgeability of Scheme 2 when T = “, which can be further reduced to the assumption [3]. Here, we re-certify following the original proof in [3]. We first give the definition of eBCDH assumption.
Definition 9. (eBCDH). The extended bilinear computational Diffie–Hellman assumption holds relative to ; if for all PPT adversaries , there is a negligible function such thatIf there is an efficient algorithm breaking -unforgeability, then we can design an algorithm that breaks the eBCDH assumption. maintains two sets: and , both are initially empty. obtains an related to the security parameter and executes the modified algorithm to obtain as follows:(i): for , select and set . Fix and output .(ii)Then, starts on inputting and , where simulates the oracles as follows:(iii) if return . Otherwise, choose , set , and return .(iv): choose and set . Then, return .(v) work as the original oracl except: randomly choose , and for all , choose . If for any , abort. Otherwise, for all , set and , compute , and return and .(vi): if , , , and return . Otherwise, set . If finally returns a valid forgery with , we know that it is of the following form:Then, we letand output as solution. The simulation above can be considered indistinguishable to the original security game: all the values are identically distributed, while the signature is uniquely determined by the responses of the random oracle and the key also indistinguishable to a real signature. Thus, if there is an efficient algorithm breaking aggregator unforgeability, we can construct an efficient algorithm which turns into an efficient eBCDH solver, which is in conflict with eBCDH assumption.
Data Availability
No data were used to support this study.
Disclosure
A preliminary version of this paper appears in the Proceedings of the 6th International Conference on Information Systems Security and Privacy, 2020, under the title “A Homomorphic Proxy Re-Authenticators Based Efficient Multi-Client Non-Interactive Verifiable Computation Scheme.”
Conflicts of Interest
The author declares that there are no conflicts of interest.