Next Article in Journal
Secure Boot for Reconfigurable Architectures
Previous Article in Journal
Chaotic Quantum Key Distribution
Open AccessArticle

Practical and Provably Secure Distributed Aggregation: Verifiable Additive Homomorphic Secret Sharing

Department of Computer Science and Engineering, Chalmers University of Technology, 41296 Gothenburg, Sweden
*
Author to whom correspondence should be addressed.
Information Security and Cryptology—ICISC 2019 Conference, Seoul, Korea, 4–6 December 2019.
Cryptography 2020, 4(3), 25; https://doi.org/10.3390/cryptography4030025
Received: 29 July 2020 / Revised: 10 September 2020 / Accepted: 16 September 2020 / Published: 21 September 2020
(This article belongs to the Special Issue Techniques and Protocols to Preserve and Enhance Privacy)

Abstract

Often clients (e.g., sensors, organizations) need to outsource joint computations that are based on some joint inputs to external untrusted servers. These computations often rely on the aggregation of data collected from multiple clients, while the clients want to guarantee that the results are correct and, thus, an output that can be publicly verified is required. However, important security and privacy challenges are raised, since clients may hold sensitive information. In this paper, we propose an approach, called verifiable additive homomorphic secret sharing (VAHSS), to achieve practical and provably secure aggregation of data, while allowing for the clients to protect their secret data and providing public verifiability i.e., everyone should be able to verify the correctness of the computed result. We propose three VAHSS constructions by combining an additive homomorphic secret sharing (HSS) scheme, for computing the sum of the clients’ secret inputs, and three different methods for achieving public verifiability, namely: (i) homomorphic collision-resistant hash functions; (ii) linear homomorphic signatures; as well as (iii) a threshold RSA signature scheme. In all three constructions, we provide a detailed correctness, security, and verifiability analysis and detailed experimental evaluations. Our results demonstrate the efficiency of our proposed constructions, especially from the client side.
Keywords: function secret sharing; homomorphic secret sharing; verifiable computation; public verifiability function secret sharing; homomorphic secret sharing; verifiable computation; public verifiability

1. Introduction

The rise of communication technologies has formed multiple smart electronic devices (e.g., cell phones, sensors, wearables) with network connection, which produce a big amount of data every day. Remote, often untrusted, cloud servers are employed to store and process these data to be used by third parties, such as research institutions, hospitals, or electricity companies. Many applications (e.g., environmental monitoring, updating parameters in machine learning, statistics about electricity consumption) require joint computations on data coming from multiple clients. For example, using smart metering, data that are collected from sensors/clients can be used to compute statistics for the electricity consumption, while environmental sensors collect data that can be used to measure emissions and data collected from mobile phones can be aggregated and processed to appropriately update parameters in machine learning models for accurate user profiling.
Although decentralization has been a recent trend, we have witnessed a steady rise of massively distributed but not decentralized systems. When multiple clients outsource a joint computation using their joint inputs, multiple servers can be employed in order to avoid single points of failure and perform a reliable joint computations on the clients’ inputs. Although this distributed cloud-assisted environment is very appealing and offers exceptional advantages, it is also followed by serious security and privacy challenges. Thus, in this work, we present the formal and practical analysis of verifiable additive homomorphic secret sharing (VAHSS), a novel cryptographic primitive introduced [1], which allows for multiple clients to outsource the joint addition of their inputs to multiple untrusted servers, providing guarantees that the clients’ inputs remain secret as well as that the computed result is correct (i.e., verifiability property). More precisely, this paper is an extended version of the preliminary article [1].
We address the problem of cloud-assisted computing characterized by the following constraints: (i) multiple servers are recruited to perform joint additions on the inputs of n clients; (ii) the inputs of the clients need to remain secret; (iii) the servers are untrusted; (iv) no communication between the clients is possible; and, (v) anyone should be able to confirm that the computed result is correct (i.e., public verifiability property). More precisely, let us consider n clients (as illustrated in Figure 1), which hold n individual secret inputs x 1 , x 2 , x n , and they want to deploy the joint computation of the function f ( x 1 , x 2 , , x n ) = x 1 + x 2 + + x n on their joint inputs by releasing shares of their inputs to multiple untrusted servers (the latter denoted by s j for j [ m ] ). We denote the share of a client c i given to the server s j by x i j . Tsaloli et al. [2] addressed the problem of computing the joint multiplications of n inputs corresponding to n clients and introduced the concept of verifiable homomorphic secret sharing (VHSS). More precisely, VHSS allows to jointly perform the computation of a function f ( x 1 , x 2 , , x n ) = y , including no communication between the clients, and allowing anyone to get a proof π that the computed result is correct, i.e., providing to anyone a pair (y, π ) which confirms the correctness of y (i.e., public verification). However, the possibility to achieve verifiable homomorphic secret sharing for other functions (e.g., addition) has been left open.
In this paper, we revisit the concept of verifiable homomorphic secret sharing (VHSS) and we explore the possibility to achieve verifiable additive homomorphic secret sharing. Our research shows that the latter is possible and we propose three concrete constructions that employ m servers to jointly compute the additions of n clients’ inputs securely and privately, while, additionally, ensuring public verifiability. The proposed constructions can be utilized, for example, to compute statistics over electricity consumption when data are collected from multiple clients, in order to remotely monitor and determine a diagnosis for multiple patients according to their collected data, as well as to measure environmental conditions while using multiple sensors’ data that come from environmental sensors (e.g., temperature, humidity). We have substantially extended the preliminary article [1] and added a detailed evaluation (both theoretical and experimental) of the three proposed VAHSS constructions. In the submitted paper, we present a detailed analysis for each of the constructions based on different conditions, providing both theoretical and experimental results.
Our Contribution. We address the problem of computing joint additions with privacy and security guarantees as the main requirements. More precisely, we treat the problem of verifiable multi-client aggregation that involves the following parties: (i) n clients, which hold secret inputs x 1 , x 2 , , x n , respectively; (ii) m untrusted servers to whom the sum computation is outsourced; and, (iii) any verifier that would like to confirm that the computed sum is correct. We present, for the first time, three concrete constructions of verifiable additive homomorphic secret sharing (VAHSS).
We employ three different primitives (i.e., homomorphic hash functions, linearly homomorphic signatures, and threshold signatures) as the baseline for the generation of partial proofs (values that are used to confirm the correctness of the computed sum). The partial proofs are computed by either the servers or the clients. These characteristics lead to three different instantiations of VAHSS. Additionally, we have altered the original VHSS definition to capture the different scenarios on the proofs’ generation; therefore, allowing for the employment of VHSS in several application settings.
Our constructions rely on casting Shamir’s secret sharing scheme over a finite field F as an n-client, m-server, and t-perfectly secure additive homomorphic secret sharing (HSS) for the function that sums n field elements. Firstly, employing homomorphic collision-resistant hash functions [3,4] and incorporating them to the additive HSS, we design a construction, such that each server produces a partial proof. Next, a linearly homomorphic signature scheme [5] is combined with the additive HSS, which results in an instantiation where each client generates a partial proof. Ultimately, the employment of a threshold RSA signature scheme [6] in additive HSS allows a subset of servers to generate partial proofs that correspond to each client. In all three proposed constructions, we have provided detailed correctness, security, and verifiability analysis. Furthermore, we provide an evaluation of the three proposed constructions, in which we describe the cost of the required operations for each of the employed algorithms as well as present a detailed experimental evaluation. More precisely, we evaluate the performance of all three proposed VAHSS constructions and compare and illustrate how the employed algorithms perform, depending on the amount of the clients that participate during the computation and the required computation time for the verification process.
Organization.Section 2 gives an overview about the current state-of-the-art in homomorphic secret sharing and verifiable computation. Later, Section 3 provides the background on verifiable homomorphic secret sharing and definitions that are necessary for the rest of the paper. We provide our VHSS constructions in Section 4. Furthermore, in Section 5 we give a theoretical analysis of the costs for the constructions and provide details of our implementation results. We present a discussion about the constructions and their costs in Section 6. Finally, we provide our final considerations in Section 7.

2. Related Work

Homomorphic Secret Sharing. The key idea of threshold secret sharing schemes [7] is the ability to split a secret x into multiple shares (denoted by, for example, x 1 , x 2 , , x m ) while maintaining the following properties: (i) any subset greater than the threshold number of shares is enough to reconstruct the secret x, and (ii) any smaller subset allows no inference of information related to the secret x. Homomorphic secret sharing (HSS) [8] can be seen as the secret-sharing analog of homomorphic encryption. In particular, HSS is employed in order to locally evaluate functions on shares of secret inputs (or just one input), by appropriately combining locally computed values with the shares of the secret(s) as input. At the same time, an HSS system ensures that the shares of the output are short. The first instance of additive HSS that is considered in the literature [9] is computed in some finite Abelian group. Nevertheless, HSS gives no guarantee that the computed result is correct i.e., no verifiability is provided.
Verifiable Function Secret Sharing. To better realize function secret sharing (FSS) [10], one can consider it as a natural extension of distributed point functions (DPF). More precisely, FSS is a method to create shares for a function f, coming from a given function family F , that are additively combined to give f. To visualize this, consider m functions f 1 , , f m , as described by the corresponding keys k 1 , , k m . These functions are the shares of f, such that f ( x ) = f 1 ( x ) + + f m ( x ) , for any input x. The notion of verifiable FSS (VFSS) [11] is introduced by Boyle et al. In particular, VFSS consists of interactive protocols that verify the consistency of some function f F with keys ( k 1 * , , k m * ) , which are generated by a potentially malicious user. However, VFSS [11] is applicable in the setting of multiple servers and one client. On the contrary, VHSS can be applied when multiple clients (multi-input) outsource the joint computation to multiple servers. Moreover, in VFSS, verification refers to confirming that the shares f 1 , , f m are consistent with some f; while, in VHSS, the goal of the verification is to ensure that the final result is correct.
Publicly Auditable Secure Multi-party Computation. Secure multi-party computation (MPC) protocols are linked with outsourced computations. In MPC protocols [12,13,14], non-interactive zero-knowledge (NIZK) proofs are generally used in order to achieve public verifiability. Baum et al. [15] introduced the notion of publicly auditable MPC protocols that are applicable when multiple clients and servers are involved. Given that publicly auditable MPC is based on the SPDZ protocol [12,13] and NIZK proofs, while it also employs Pedersen commitments (for enhancing each shared input x), it can be viewed as a generalization of the classic formalization of secure function evaluation. In the work of Baum et al. [15], anyone that has access to the published (in a bulletin board) transcript of the protocol can confirm that the computed result is correct (correctness property); while, the protocol provides privacy guarantees and requires at least one honest party. We should note that publicly auditable MPC protocols are very expressive regarding the class of functions being computed, but they often require heavy computations. To formalize auditable MPC, an extra non-corruptible party is introduced in the standard MPC model, namely the auditor. On the other hand, in VAHSS, we do not require any additional non-corruptible party as well as we do not employ expensive cryptographic primitives, such as NIZK proofs.

3. Preliminaries

Our concrete instantiations for the additive VHSS problem are based on the VHSS definition that was proposed in [2]. However, we propose a slightly modified version of the VHSS definition to capture cases when partial proofs (used to verify the correctness of the final result) are computed either from the clients or the servers, which is reflected later in our instantiations. More precisely, depending on the construction, the execution of the PartialProof algorithm is performed by either the clients or the servers. We added the Setup algorithm to allow for the generation of keys and we modified the PartialProof algorithm accordingly to allow the different scenarios.
Definition 1 (Verifiable Homomorphic Secret Sharing (VHSS)).
An n-client, m-server, t-secure verifiable homomorphic secret sharing scheme for a function f : X Y , is a seven-tuple of PPT algorithms (Setup, ShareSecret, PartialEval, PartialProof, FinalEval, FinalProof, Verify), which are defined as follows:
  • ( p p , s k ) Setup( 1 λ ): On input 1 λ , where λ is the security parameter, a secret key s k , to be used by a client, and some public parameters p p .
  • ( share i 1 , , share i m , τ i ) ShareSecret( 1 λ , i , x i ): The algorithm takes as input 1 λ , i { 1 , , n } which is the index for the client c i and x i which denotes a vector of one (i.e., x i X ) or more secret values that belong to each client and should be split into shares. The algorithm outputs m shares share i j (denoted also by x i j X when x i = x i ) for each server s j , as well as, if necessary, a publicly available value τ i ( τ i , when computed, can be included in the list of public parameters p p ) related to the secret x i .
  • y j PartialEval( j , ( x 1 j , x 2 j , , x n j ) ): On input j { 1 , , m } , which denotes the index of the server s j , and x 1 j , x 2 j , , x n j , which are the shares of the n secret inputs x 1 , , x n that the server s j has, the algorithm PartialEvaloutputs y j Y .
  • σ k PartialProof( s k , p p , s e c r e t v a l u e s , k ): on input, the secret key s k , public parameters p p , secret values (based on which the partial proofs are generated), denoted by secret values ; and, the corresponding index k (where k is either i or j), a partial proof σ k is computed. Note that k is a variable; thus, k = i when PartialProof generates proofs per client or k = j if it generates proofs per server.
  • y FinalEval ( y 1 , y 2 , , y m ) : On input y 1 , y 2 , , y m , which are the shares of f ( x 1 , x 2 , , x n ) that the m servers compute, the algorithmFinalEvaloutputs y, the final result for f ( x 1 , x 2 , , x n ) .
  • σ FinalProof( p p , σ 1 , , σ | k | ): on input public parameters p p and the partial proofs σ 1 , σ 2 , , σ | k | , the algorithmFinalProofoutputs σ, which is the proof that y is the correct value. Note that | k | = n , if the partial proofs are computed per client or | k | = m , if they are computed per server.
  • 0 / 1 Verify( p p , σ , y ): On input the final result y, the proof σ, and, when needed, public parameters p p , the algorithmVerifyoutputs either 0 or 1.
Correctness, Security, Verifiability. The algorithms (Setup, ShareSecret, PartialEval, PartialProof, FinalEval, FinalProof, and Verify) should satisfy the following correctness, verifiability, and security requirements:
  • Correctness: for any secret input x 1 , , x n , for all m-tuples in the set { ( share i 1 , , share i m ) , τ i } i = 1 n coming from ShareSecret , for all y 1 , , y m computed by PartialEval , σ 1 , , σ | k | computed from PartialProof , and for y and σ generated by FinalEval and FinalProof , respectively, the scheme should satisfy the following correctness requirement:
    Pr Verify ( p p , σ , y ) = 1 = 1 .
  • Verifiability: let T be the set of corrupted servers with | T | m (note that, for | T | = m , the verifiabililty property holds; however, we do not have a secure system). Denote, by A , any PPT adversary and consider n secret inputs x 1 , , x n F . Any PPT adversary A who controls the shares of the secret inputs for any j, such that s j T can cause a wrong value to be accepted as f ( x 1 , x 2 , , x n ) with negligible probability.
    We define the following experiment Exp VHSS Verif . ( x 1 , , x n , T , A ) :
    1.
    For all i { 1 , , n } , generate ( share i 1 , , share i m , τ i ) ShareSecret( 1 λ , i , x i ) and publish τ i .
    2.
    For all j, such that s j T , give share 1 j share 2 j share n j to the adversary.
    3.
    For the corrupted servers s j T , the adversary A outputs modified shares y j and σ k . Subsequently, for j, such that s j T , we set y j = Partial - Eval ( j , ( x 1 j , , x n j ) ) and σ k = PartialProof ( s k , p p , secret values , k ) . Note that we consider modified σ k only when computed by the servers.
    4.
    Compute the modified final value y = FinalEval ( y 1 , y 2 , , y m ) and the modified final proof σ = FinalProof ( p p , σ 1 , , σ | k | ) .
    5.
    If y f ( x 1 , x 2 , , x n ) and Verify ( p p , σ , y ) = 1 , then output 1 else 0.
    We require that for any n secret inputs x 1 , x 2 , , x n F , any set T of corrupted servers and any PPT adversary A it holds:
    Pr [ Exp VHSS Verif . ( x 1 , x 2 , , x n , T , A ) = 1 ] ε , for some negligible ε .
  • Security: let T be the set of the corrupted servers with | T | < m . Consider the following semantic security challenge experiment:
    1.
    The adversary A 1 gives ( i , x i , x i ) A 1 ( 1 λ ) to the challenger, where i [ n ] , x i x i and | x i | = | x i | .
    2.
    The challenger picks a bit b { 0 , 1 } uniformly at random and computes ( share ^ i 1 , , share ^ i m , τ ^ i ) ShareSecret ( 1 λ , i , x ^ i ) where the secret input x ^ i = { x i , if b = 0 x i , otherwise .
    3.
    Given the shares from the corrupted servers T and τ ^ i , the adversary distinguisher outputs a guess b D ( ( share ^ i j ) j s j T , τ ^ i ) .
    Let Adv ( 1 λ , A , T ) : = Pr [ b = b ] 1 / 2 be the advantage of A = { A 1 , D } in guessing b in the above experiment, where the probability is taken over the randomness of the challenger and of A . A VHSS scheme is t-secure if, for all T { s 1 , , s m } with | T | t , and all PPT adversaries A , it holds that Adv ( 1 λ , A , T ) ε ( λ ) for some negligible ε ( λ ) .
In our solution, we employ a simple variant of the (Strong) RSA based signature that was introduced by Catalano et al. [16], which can be seen as a linearly homomorphic signature scheme on Z N .
Definition 2
(Linearly Homomorphic Signature [5]). A linearly homomorphic signature scheme is a tuple of PPT algorithms ( HKeyGen ,   HSign ,   HVerify ,   HEval ) defined, as follows:
  • HKeyGen ( 1 λ , k ) takes as input the security parameter λ and an upper bound k for the number of messages that can be signed in each dataset. It outputs a secret signing key s k and a public key v k . The public key defines a message space M , a signature space S , and a set F of admissible linear functions, such that any f : M n M is linear.
  • HSign ( s k , f i d , m i , i ) algorithm takes as input the secret key s k , a dataset identifier f i d , and the i-th message m i to be signed, and outputs a signature σ i .
  • HVerify ( v k , f i d , m , σ , f ) algorithm takes as input the verification key v k , a dataset identifier f i d , a message m, a signature σ and a function f. It outputs either 1 if the signature corresponds to the message m or 0 otherwise.
  • HEval ( v k , f i d , f , σ 1 , , σ n ) algorithm takes as input the verification key v k , a dataset identifier f i d , a function f F , and a tuple of signatures σ 1 , , σ n . It outputs a new signature σ.
We use homomorphic hash functions in order to achieve verifiability. Below, we provide the definition of such a function. More precisely, we employ a homomorphic hash function satisfying additive homomorphism [4].
Definition 3
(Homomorphic Hash Function [3]). A homomorphic hash function h : F N G q , where F is a finite field and G is a multiplicative group of prime order q, is defined as a collision-resistant hash function that satisfies the homomorphism in addition to the properties of a universal hash function u h : ( 0 , 1 ) * ( 0 , 1 ) l .
1.
One-way: it is computationally hard to compute h 1 ( x ) .
2.
Collision-free: it is computationally hard to find x , y F N ( x y ) , such that h ( x ) = h ( y ) .
3.
Homomorphism: for any x , y F N , it holds h ( x y ) = h ( x ) h ( y ) , where is either + or · .
For completeness, we also provide the definition of a secure pseudorandom function PRF.
Definition 4 (Pseudorandom Function (PRF)).
Let S be a distribution over { 0 , 1 } and F s : { 0 , 1 } m { 0 , 1 } n be a family of functions indexed by strings s in the support of S. We say that { F s } is a pseudorandom function family if, for every PPT adversary D, there exists a negligible function ϵ, such that:
| Pr [ D F s ( · ) = 1 ] Pr [ D R ( · ) = 1 ] | ϵ ,
where s is distributed according to S and R is a function sampled uniformly at random from the set of all functions from { 0 , 1 } m to { 0 , 1 } n .

4. Verifiable Additive Homomorphic Secret Sharing

In this section, we present three different instantiations to achieve verifiable additive homomorphic secret sharing (VAHSS). More precisely, we consider n clients with their secret values x 1 , , x n respectively, and m servers s 1 , , s m that perform computations on shares of these secret values. Firstly, the clients split their secret values into shares, which reveal nothing about the secret value itself and, then, they distribute the shares to each of the m servers. Each server performs some calculations in order to publish a value, which is related to the final result f ( x 1 , , x n ) = x 1 + + x n . Subsequently, partial proofs are generated in a different way, depending on the instantiation proposed. The partial proofs are values, such that their combination results in a final proof, which confirms the correctness of the final computed value f ( x 1 , , x n ) . Note that, for all of the proposed constructions, the clients do not need to communicate with each other, which often is the case in settings where the clients are wireless devices spread in different regions and are not in the communication range of each other (e.g., sensors measuring electricity consumption or environmental conditions). However, the clients could potentially collude with some of the servers, without compromising the security of our constructions as long as at least two clients remain honest.

4.1. Construction of VAHSS Using Homomorphic Hash Functions

In this section, we aim to compute the function value y, which corresponds to f ( x 1 , , x n ) = x 1 + + x n as well as a proof σ that y is correct. We combine an additive HSS for the algorithms that are related to the value y and hash functions for the generation of the proof σ . Let c 1 , , c n denote n clients and x 1 , , x n their corresponding secret inputs. Let, for any { i } i = 1 , , n , θ i 1 , , θ i m be distinct non-zero field elements and λ i 1 , , λ i m be field elements (“Lagrange coefficients"), such that, for any univariate polynomial p i of degree t over a finite field F = F N , we have:
p i ( 0 ) = j = 1 m λ i j p i ( θ i j )
Each client c i generates shares of the secret x i , denoted by x i 1 , , x i m , respectively, and gives the share x i j to each server s j . The servers, in turn, compute a partial sum, denoted by y j , and publish it. Anyone can then compute y = y 1 + + y m , which corresponds to the function value y = f ( x 1 , , x n ) = x 1 + + x n . We suggest that every client c i uses a homomorphic collision-resistant function H : x g x proposed by Krohn et al. [4] to generate a public value τ i , which reveals nothing about x i (under the discrete logarithm assumption). Afterwards, the servers compute values σ 1 , , σ m , which will be appropriately combined so that they give the proof σ that we are interested in. The value y comes from the combination of partial values y j , which are computed by the m servers. More precisely, our solution is composed of the following algorithms:
1.
ShareSecret( 1 λ , i , x i ): for elements { a i } i { 1 , , t } F selected uniformly at random, pick a t-degree polynomial p i of the form p i ( X ) = x i + a 1 X + a 2 X 2 + + a t X t . Notice that the free coefficient of p i is the secret input x i . Let H : x g x (with g a generator of the multiplicative group of F ) be a collision-resistant homomorphic hash function [3]. Let R i be the output of a pseudorandom function (PRF) F : { 0 , 1 } l 1 × { 0 , 1 } l 2 F where R i = F k ( i , f i l e i ) for a key k { 0 , 1 } l 1 given to the clients and a timestamp f i l e i associated with client i such that ( i , f i l e i ) { 0 , 1 } l 2 . For i = n , we require F R n = ϕ ( N ) i = 1 n 1 R i ϕ ( N ) i = 1 n 1 R i . Subsequently, compute τ i = H ( x i + R i ) , define x i j = λ i j p i ( θ i j ) (given thanks to the Equation (1)) and output ( x i 1 , x i 2 , , x i m , τ i ) = ( λ i 1 · p i ( θ i 1 ) , , λ i m · p i ( θ i m ) , H ( x i + R i ) ).
2.
PartialEval ( j , ( x 1 j , x 2 j , , x n j ) ): given the j-th shares of the secret inputs, compute the sum of all x i j = λ i j · p i ( θ i j ) for the given j and i [ n ] . Output y j with y j = λ 1 j · p 1 ( θ 1 j ) + + λ n j · p n ( θ n j ) = i = 1 n λ i j · p i ( θ i j ) .
3.
PartialProof( j , ( x 1 j , x 2 j , , x n j ) ): given the j-th shares of the secret inputs, compute and output the partial proof σ j = g i = 1 n x i j = g y j = H ( y j ) .
4.
FinalEval( y 1 , y 2 , , y m ): add the partial sums y 1 , , y m together and output y (where y = y 1 + + y m ).
5.
FinalProof( σ 1 , , σ m ): given the partial proofs σ 1 , σ 2 , , σ m , compute the final proof σ = j = 1 m σ j . Output σ .
6.
Verify( τ 1 , , τ n , σ , y ): check whether σ = i = 1 n τ i i = 1 n τ i = H ( y ) holds. Output 1 if the check is satisfied or 0 otherwise.
Each client runs the ShareSecret algorithm to compute and distribute the shares of x i to each of the m servers and a public value τ i , which is needed for the verification. Subsequently, each server s j has the shares given from the n clients and runs the PartialEval algorithm to output the public values y j related to the final function value. Furthermore, each server runs the PartialProof algorithm and it produces the value σ j . Finally, any user or verifier is able to run the FinalEval algorithm to obtain y and the FinalProof algorithm to get the proof σ . Lastly, Verify algorithm ensures that y and σ match and, thus, y = f ( x 1 , , x n ) is correct. Table 1 illustrates our construction.
  • Correctness: In order to prove the correctness of this construction, we need to prove that Pr Verify ( τ 1 , , τ n , σ , y ) = 1 = 1 . By construction it holds that:
    y = j = 1 m y j = j = 1 m i = 1 n λ i j · p i ( θ i j ) = i = 1 n j = 1 m λ i j · p i ( θ i j ) = i = 1 n p i ( 0 ) = i = 1 n x i
    Additionally, by construction, we have:
    σ = j = 1 m σ j = j = 1 m H ( y j ) = j = 1 m g y j = g j = 1 m y j = g y = H ( y )
    and i = 1 n τ i = i = 1 n g x i + R i = g i = 1 n x i g i = 1 n R i = g i = 1 n x i g i = 1 n 1 R i + R n = g i = 1 n x i g ϕ ( N ) i = 1 n 1 R i ϕ ( N ) = g i = 1 n x i = g x 1 + + x n = s e e E q u a t i o n ( 2 ) g y = H ( y )
    Combining the last two results, we get that σ = i = 1 n τ i i = 1 n τ i = H ( y ) holds. Therefore, the algorithm Verify outputs 1 with probability 1.
  • Security: See [17] for a proof that the selected hash function H of our construction is a secure collision-resistant hash function under the discrete logarithm assumption.
    We will now prove that Adv ( 1 λ , A , T ) ε ( λ ) for some negligible ε ( λ ) .
Proof. 
Game 0: consider m 1 corrupted servers. Subsequently, | T | = m 1 . Without a loss of generality, let the first m 1 servers be the corrupted ones. Therefore, the adversary A has ( m 1 ) n shares from the corrupted servers and no additional information.
For any fixed i with i { 1 , , n } , it holds that j = 1 m share ^ i j = x ^ i and, hence:
j = 1 m 1 share ^ i j + share ^ i m = x ^ i share ^ i m = x ^ i j = 1 m 1 share ^ i j
The adversary holds j = 1 m 1 share ^ i j . Furthermore, the adversary holds the public value τ ^ i = g x ^ i + R i . Because R i is the output of a PRF, then τ ^ i is also a pseudorandom value.
Game 1: consider that the adversary holds the same shares j = 1 m 1 share ^ i j and τ ^ i is now a truly random value.
Firstly, share ^ i m Y is just a value, which implies nothing to the adversary regarding whether it is related to x i or x i . Moreover, Game 0 and Game 1 are computationally indistinguishable due to the security of the PRF. Thus, any PPT adversary has the probability 1 / 2 to decide whether x ^ i is x i or x i and so, Adv ( 1 λ , A , T ) ε ( λ ) for some negligible ε ( λ ) . □
  • Verifiability: In this construction, for y = x 1 + x 2 + + x n , if y x 1 + + x n and Verify ( τ 1 , , τ n , σ , y ) = 1 , then the verifiability follows:
    Verify ( τ 1 , , τ n , σ , y ) = 1 σ = i = 1 n τ i i = 1 n τ i = H ( y ) i = 1 n τ i = H ( y ) ( see Equation ( 3 ) ) H ( y ) = H ( y )
    which is a contradiction since y y and H is collision-resistant. Therefore,
    Pr [ Exp VHSS Verif . ( x 1 , , x n , T , A ) = 1 ] ε , as desired .

4.2. Construction of VAHSS with Linear Homomorphic Signatures

Our goal is always to compute f ( x 1 , , x n ) = x 1 + + x n = y as well as a proof σ that y is correct. We compute y while using additive HSS and we employ a linearly homomorphic signature scheme, presented in [5] as a simple variant of Catalano et al. [16] signature scheme, for the generation of the proof. All of the clients hold the same signing and verification key. This could be the case if the clients are sensors of a company collecting information (e.g., temperature, humidity) that is useful for some calculations. Because the sensors/clients belong to the same company, sharing the same key might be necessary to facilitate configuration. In applications, scenarios where clients should be set up with different keys, a multi-key scheme [18] could be used. However, in our construction, the clients can use the same signing key to sign their own secret value. In fact, they sign x i , R , where x i , R = x i + R i with R i chosen from each client, as described in the Section 4.1. The signatures, which are denoted by σ 1 , , σ n , are public and, when combined, they form a final signature σ , which verifies the correctness of y. Our instantiation constitutes of the following algorithms:
1.
Setup( 1 k , N ): let N be the product of two safe primes each one of length k / 2 . This algorithm chooses two random (safe) primes p ^ , q ^ each one of length k / 2 , such that gcd ( N , ϕ ( N ^ ) ) = 1 with N ^ = p ^ · q ^ . Subsequently, the algorithm chooses g , g 1 , h 1 , , h n in Z N ^ * at random. Subsequently, it chooses some (efficiently computable) injective function H : { 0 , 1 } * { 0 , 1 } l with l < k / 2 . It outputs the public key v k = ( N , H , N ^ , g , g 1 , h 1 , , h n ) to be used by any verifier; and, the secret key s k = ( p ^ , q ^ ) to be used for signing the secret values.
2.
ShareSecret( 1 λ , i , x i ): for elements { a i } i { 1 , , t } F selected uniformly at random, pick a t-degree polynomial p i of the form p i ( X ) = x i + a 1 X + a 2 X 2 + + a t X t . Notice that the free coefficient of p i is the secret input x i . Subsequently, define x i j = λ i j p i ( θ i j ) (given using the Equation (1)) and output ( x i 1 , x i 2 , , x i m ) = λ i 1 · p i ( θ i 1 ) , λ i 2 · p i ( θ i 2 ) , , λ i m · p i ( θ i m ) ) .
3.
PartialEval( j , ( x 1 j , x 2 j , , x n j ) ): given the j-th shares of the secret inputs, compute the sum of all x i j = λ i j · p i ( θ i j ) for the given j and i [ n ] . Output y j with y j = λ 1 j · p 1 ( θ 1 j ) + + λ n j · p n ( θ n j ) = i = 1 n λ i j · p i ( θ i j ) .
4.
PartialProof( s k , v k , f i d , x i , R , i ): Parse the verification key v k to get N , H , N ^ , g , g 1 and h 1 , , h n . For the (efficiently computable) injective function H that is chosen from Setup, map f i d to a prime: H ( f i d ) e . We denote the i-th vector of the canonical basis on Z n by e i . Choose random elements s i and solve, using the knowledge for p ^ and q ^ , the equation: x e N = g s i j = 1 n h j f j ( i ) g 1 x i , R mod N ^ , where f j ( i ) denotes the j-th coordinate of the vector f ( i ) . Notice that, for our function e i , the equation becomes x e N = g s i h i g 1 x i , R mod N ^ . Set x i ˜ = x . Output σ i , where σ i = ( e , s i , f i d , x i ˜ ) is the signature for x i w.r.t. the function f ( i ) = e i .
5.
FinalEval( y 1 , y 2 , , y m ): add the partial sums y 1 , , y m together and output y (where y = y 1 + + y m ).
6.
FinalProof( v k , f ^ , σ 1 , σ 2 , , σ n ): given the public verification key v k , the signatures σ 1 , , σ n , let f ^ = ( α 1 , , α n ) . Define f = ( i = 1 n α i f ( i ) f ) / e N , where f = i = 1 n α i f ( i ) mod e N . Set s = i = 1 n α i s i mod e N , s = ( i = 1 n α i s i s ) / e N and x ˜ = i = 1 n x i ˜ α i g s j = 1 n h j f j mod N ^ . For f ^ = ( 1 , , 1 ) , compute x ˜ = i = 1 n x i ˜ g s j = 1 n h j f j mod N ^ . Output σ where σ = ( e , s , f i d , x ˜ ) .
7.
Verify( v k , f , σ , y ): compute e = H ( f i d ) . Check that y , s Z e N and x ˜ e N = g s j = 1 n h j f j g 1 y holds. Output: 1 if all checks are satisfied or 0 otherwise.
All n clients get the secret key s k from Setup and hold their secret value x 1 , , x n , respectively. Each client runs ShareSecret to split its secret value x i into m shares and PartialProof in order to produce the partial signature (for the secret x i ) σ i . The values σ i ’s are not generated by the servers, since, in that case, malicious compromised servers would not be detected. Subsequently, each client distributes the shares to each of the m servers and publishes σ i . Each server s j computes and publishes the partial function value y j by running PartialEval . Any verifier is able to get the function value y = f ( x 1 , , x n ) from the FinalEval and the proof σ from the FinalProof . The Verify algorithm outputs 1 if and only if y = x 1 + + x n . Table 2 reports an illustration of our solution.
  • Correctness: To prove the correctness of our construction, we need to prove that Pr Verify ( v k , f , σ , y ) = 1 = 1 . It holds that:
    x ˜ e N = ( i = 1 n x i ˜ g s i = 1 n h j f j ) e N = i = 1 n x i ˜ e N g s e N i = 1 n h j f j e N = i = 1 n ( g s i j = 1 n h j f j ( i ) g 1 x i , R ) g s e N i = 1 n h j f j e N = g i = 1 n s i g s e N · i = 1 n j = 1 n h j f j ( i ) i = 1 n h j f j e N · g 1 i = 1 n x i , R = g i = 1 n s i g s e N · i = 1 n j = 1 n h j f j ( i ) i = 1 n h j f j e N · g 1 i = 1 n x i · g 1 i = 1 n R i
    = s e e E q u a t i o n ( 3 ) g i = 1 n s i s e N j = 1 n h j i = 1 n f j ( i ) f j e N g 1 i = 1 n x i = g s j = 1 n h j f j g 1 i = 1 n x i
    Thanks to the Equation (2), it also holds that y = i = 1 n x i . Subsequently, x ˜ e N = g s · j = 1 n h j f j · g 1 y and, thus, Verify ( v k , σ , y , f ) = 1 with probability 1.
  • Security: The security of the signatures easily results from the original signature scheme that was proposed by Catalano et al. [16]. Moreover, Adv ( 1 λ , A , T ) ε ( λ ) for some negligible ε ( λ ) as we have proven in the Section 4.1. We should note that, since in this construction no τ i values are incorporated, the arguments related to the pseudorandomness of τ i are not necessary.
  • Verifiability: Verifiability is by construction straightforward since the final signature σ FinalProof ( v k , f ^ , σ 1 , , σ n ) is obtained using the correctly computed (by the clients) σ 1 , , σ n and, thus, σ = σ in this case. Therefore, if y x 1 + + x n while y = x 1 + + x n and Verify ( v k , σ , y , f ) = 1 , then:
    Verify ( v k , σ , y , f ) = 1 Verify ( v k , σ , y , f ) = 1 x ˜ e N = g s j = 1 n h j f j g 1 y ( see Equation ( 4 ) ) g s j = 1 n h j f j g 1 i = 1 n x i = g s j = 1 n h j f j g 1 y i = 1 n x i = y
    which is a contradiction!
    Therefore, Pr [ Exp VHSS Verif . ( x 1 , , x n , T , A ) = 1 ] ε .

4.3. Construction of VAHSS with Threshold Signature Sharing

We propose a scheme, where the clients generate and distribute shares of their secret values to the m servers and the servers mutually produce shares of the final value y similarly to the previous constructions. However, in order to generate the proof σ that confirms the correctness of y, our scheme employs the ( t , n ) -threshold RSA signature scheme proposed in [6], so that a signature σ is successfully generated, even if t 1 servers are corrupted. Our proposed scheme (illustrated in the Table 3) acts in accordance with the following algorithms:
1.
Setup ( 1 k , N ): Let N = p · q be the RSA modulus, such that p = 2 p + 1 and q = 2 q + 1 , where p , q are large primes. Choose the public RSA key e i , such that e i n t and then pick the private RSA key d i , so that e i d i 1 mod ( p q ) . Output the public key e i and the private key d i .
2.
ShareSecret( 1 λ , i , x i , d i , ): for elements { a i } i { 1 , , t } F selected uniformly at random, pick a t-degree polynomial p i of the form p i ( X ) = x i + a 1 X + a 2 X 2 + + a t X t . Notice that the free coefficient of p i is the secret input x i . Subsequently, define x i j = λ i j p i ( θ i j ) (given thanks to the Equation (1)). Let A i be an m × t full-rank public matrix with elements from F = Z r * for a prime r. Let d = ( d i , r 2 , , r t ) be a secret vector from F t , where d i is the private RSA key and r 2 , , r t F are randomly chosen. Let a i j be the entry at the i-th row and j-th column of the matrix A i . For all j [ m ] , set ω i j = a j 1 d i + a j 2 r 2 + + a j t r t F to be the share that is generated from the client c i for the server s j . It is now formed an m × t system A i d = ω i . Let H : x i g x i (with g a generator of the multiplicative group of F ) be a collision-resistant homomorphic hash function [3]. Let R i be randomly selected values, as described in the Section 4.1. Output the public matrix A i , the ( x i ’s) shares ( x i 1 , x i 2 , , x i m ) = λ i 1 · p i ( θ i 1 ) , λ i 2 · p i ( θ i 2 ) , , λ i m · p i ( θ i m ) ) , the shares of the private key ω i = ( ω i 1 , , ω i m ) , and H ( x i + R i ) .
3.
PartialEval( j , ( x 1 j , x 2 j , , x n j ) ): given the j-th shares of the secret inputs, compute the sum of all x i j = λ i j · p i ( θ i j ) for the given j and i [ n ] . Output y j with y j = λ 1 j · p 1 ( θ 1 j ) + + λ n j · p n ( θ n j ) = i = 1 n λ i j · p i ( θ i j ) .
4.
PartialProof( ω 1 , , ω n , H ( x 1 + R 1 ) , , H ( x n + R n ) , A 1 , , A n , N ): For all i [ n ] , run the algorithm PartialProof i ( ω i , H ( x i + R i ) , A i , i , N ) , where:
  • PartialProof i ( ω i , H ( x i + R i ) , A i , i , N ) : Let S = { s 1 , s 2 , , s t } be the coalition of t servers ( t < m ) (w.l.o.g. take the first t ), forming the system A i S d = ω iS . Let the t × t adjugate matrix of A i S be:
    C i S = c 11 c 21 c t 1 c 1 t c 2 t c t t
  • Denote the determinant of A i S by Δ i S . It holds that:
    A i S C i S = C i S A i S = Δ i S I t
    where I t stands for the t × t identity matrix. Compute the partial signature of x i : σ i j = H ( x i + R i ) 2 c j 1 ω i j mod N . Output σ i = ( σ i 1 , , σ i t ) .
PartialProof outputs σ 1 , , σ n .
5.
FinalEval( y 1 , y 2 , , y m ): add the partial sums y 1 , , y m together and output y (where y = y 1 + + y m ).
6.
FinalProof( e 1 , , e n , H ( x 1 + R 1 ) , , H ( x n + R n ) , σ 1 , , σ n , N ): for all i { 1 , , n } run the algorithm FinalProof i ( e i , H ( x i + R i ) , σ i , N ) where:
  • FinalProof i ( e i , H ( x i + R i ) , σ i , N ): Combine the partial signatures by computing σ i ¯ = j S σ i j mod N . Compute σ i = σ i ¯ α i H ( x i + R i ) β i mod N with α i , β i integers, such that
    2 Δ i S α i + e i β i = 1 .
  • Output σ i , i.e., the signature that corresponds to the secret x i .
FinalProof outputs σ = i = 1 n σ i e i .
7.
Verify( H ( x 1 + R 1 ) , , H ( x n + R n ) , σ , y ): check whether σ = i = 1 n H ( x i + R i ) H ( y ) = i = 1 n H ( x i + R i ) holds. Output 1 if the check is satisfied or 0 otherwise.
After the initialization with the Setup , each client c i gets its public and private RSA keys, e i and d i , respectively. Subsequently, each c i runs ShareSecret to compute and distribute the shares of x i to each of the m servers, and form a public matrix A i , shares of the private key ( ω i 1 , , ω i m ) and the hash of the secret input and a randomly chosen value, H ( x i + R i ) , to be used for the signatures’ generation. H ( x i + R i ) is a publicly available value. Subsequently, each server runs PartialEval to generate public values y j related to the final function value. A set of a coalition of the servers runs PartialProof and obtains the partial signatures. For instance, σ 1 is the vector that contains the partial signatures of x 1 , σ 2 is the vector that contains the partial signatures of x 2 and so on. Anyone is able to run FinalEval to get y and FinalProof to get σ , which is the final signature that corresponds to the secret inputs x 1 , , x n . Finally, the Verify algorithm succeeds if and only if the final value y is correct.
  • Correctness: to prove the correctness of our construction, we need to prove that Pr Verify ( H ( x 1 + R 1 ) , , H ( x n + R n ) , σ , y ) = 1 = 1 . For convenience, here, denote H ( x i + R i ) by H i . By construction:
    σ = i = 1 n σ i e i = i = 1 n ( σ i ¯ α i H i β i ) e i = i = 1 n ( j S σ i j α i H i β i ) e i = i = 1 n ( H i β i j S H i 2 c j 1 ω i j α i ) e i = i = 1 n H i β i e i H i j S 2 c j 1 ω i j α i e i = s e e E q u a t i o n ( 5 ) i = 1 n H i β i e i H i 2 Δ i S d i α i e i = i = 1 n H i 2 Δ i S α i + β i e i ( mod N ) = s e e E q u a t i o n ( 6 ) i = 1 n H i = i = 1 n H ( x i + R i ) and also ,
    i = 1 n H ( x i + R i ) = i = 1 n g x i + R i = s e e E q u a t i o n ( 3 ) H ( y )
    Therefore, Verify ( H ( x 1 + R 1 ) , , H ( x n + R n ) , σ , y ) = 1 with probability 1, as desired.
  • Security: the security of the signatures follows from the fact that the threshold signature scheme, which is employed in our construction, is secure, for | T | t 1 , under the static adversary model given that the standard RSA signature scheme is secure [6]. Additionally, for | T | m 1 , Adv ( 1 λ , A , T ) ε ( λ ) for some negligible ε ( λ ) , as we have proven in Section 4.1. Therefore, our construction is secure for | T | min { t 1 , m 1 } .
  • Verifiability: for Verify ( H ( x 1 + R 1 ) , , H ( x n + R n ) , σ , y ) = 1 and y y we have:
    Verify ( H ( x 1 + R 1 ) , , H ( x n + R n ) ) , σ , y ) = 1 σ = i = 1 n H ( x i + R i ) H ( y ) = i = 1 n H ( x i + R i ) H ( y ) = i = 1 n H ( x i + R i ) ( see Equation ( 7 ) ) H ( y ) = H ( y )
    which is a contradiction! Thus,
    Pr [ Exp VHSS Verif . ( x 1 , , x n , T , A ) = 1 ] ε .

5. Evaluation

In this section, we provide the evaluation of our proposed constructions. First, we perform a theoretical analysis and present the amount of operations required to implement each construction. Next, we provide a detailed experimental evaluation; we describe the experimental setup and provide the required computational time for each of the presented transactions for different conditions, from both the client and the server side.

5.1. Theoretical Analysis

We now present the basic operations that are required in our constructions. Recall that we denote the number of clients by n and the number of servers by m. The threshold for generating shares of the secret clients’ inputs is denoted by t, while the threshold used in the proposed third VAHSS construction i.e., based on threshold signature sharing, for generating shares of the private RSA key, is denoted by t . All of the operations are reported per algorithm and, thus, considering the cost for each client or server, respectively. This means that if, for instance, n 1 additions correspond to the PartialEval algorithm in the table, this number represents the amount of operations that are required from each server that executes the PartialEval algorithm.
In our constructions, in the Sharesecret algorithm, each client generates m shares that are related to its secret inputs. Below, we present in detail how we calculate the cost for the client to compute these m shares. Each client needs m polynomial evaluations (denoted by P e v a l ) as well as the computation of the Lagrange coefficients (denoted by L c o e f f ), as shown in Equation (1). We consider Horner’s method [19] to calculate P e v a l , which gives t multiplications and t additions for a polynomial of degree t, as in our constructions. Furthermore, L c o e f f requires 2 multiplications, 1 computation of inverse, and 1 addition (in F ) for each factor out of m 1 . One additional multiplication is needed in order to form the right hand side of Equation (1). Therefore, the cost for generating m secret shares can be demonstrated, as follows:
S h a r e s c o s t = m P e v a l + L c o e f f + 1 m u l = m ( t a d d + t m u l ) + ( m 2 ) ( 1 m u l + 1 i n v + 1 a d d ) + 1 m u l = m t a d d + m t m u l + ( m 2 ) m u l + ( m 2 ) i n v + ( m 2 ) a d d + 1 m u l = ( m t + m 2 ) a d d + ( m t + m 1 ) m u l + ( m 2 ) i n v
This amount of operations is added in the Sharesecret algorithm costs. Let us now present the tables that summarize the cost of our constructions. In parentheses, we display by whom the algorithm is executed. Whenever not specified, the algorithm can be run from any verifier. Table 4 illustrates the costs for the VAHSS construction while using homomorphic hash functions (also found as VAHSS-HSS). Observe that there is no Setup algorithm in this construction. Table 5 shows the number of operations required in the VAHSS construction while using linear homomorphic signatures (also found as VAHSS-LHS). Finally, Table 6 gives the costs of the VAHSS construction while using threshold signature sharing (found also as VAHSS-TSS). Observe that the same variables are used to show the theoretical results. However, note that t appears in the VAHSS-TSS construction for the first time, denoting a different number than the threshold t that is used for generating shares of the secret inputs. Moreover, the algorithms are executed from either a client or server, depending on the construction presented.
Looking at Table 4, Table 5 and Table 6, we observe some differences regarding the costs that are expected in each algorithm. More precisely, we can see that the ShareSecret algorithm is always run by the clients. In this respect, the VAHSS-HSS and VAHSS-LHS constructions slightly differ, since a client needs to produce some additional public values in the VAHSS-HSS case. The VAHSS-TSS is more expensive, since the client also generates shares of its private RSA key. Furthermore, as we have mentioned, VAHSS-HSS requires no Setup, thus, it is computationally less expensive than the other two constructions from the client’s side. Subsequently, we can observe that the PartialEval and FinalEval algorithms are always run by the servers and are expected to have the same computational cost. The PartialProof algorithm is run either by the servers or the clients. In the VAHSS-HSS construction, the computation is low and is made by the servers, while, in the VAHSS-LHS, the execution is made by the clients and it is also low-cost. In the VAHSS-TSS solution, PartialProof is run by a coalition of servers and the cost depends on the amount of the servers that can be considered in the computation. Next, FinalProof is quite practical in all cases, but it is not particularly comparable since there are several parameters that can affect this cost. Finally, the verification process (Verify) has the same computational cost for the first and third construction, while it is slightly heavier for the VAHSS-LHS construction.

5.2. Prototype Analysis

In this section, we present our results from the experimental analysis regarding the performance of the three proposed VAHSS constructions. More precisely, we have implemented the following constructions: VAHSS based on homomorphic hash functions (VAHSS-HSS), VAHSS based on linear homomorphic signatures (VAHSS-LHS), and VAHSS based on threshold signature sharing (VAHSS-TSS) and compare them regarding their performance.
In our implementations, we used the programming language “C++” and the GMP Library (https://gmplib.org/) for handling big numbers and their arithmetic operations. Furthermore, we ran the experiments on Arch Linux Kernel 5.7.7 over a Dell Latitude 5300 with processor Intel i 5 - 8365 U CPU @ 1.60 GHz (micro architecture codename Whisky Lake), with 16 GB RAM, 32KiB L1d cache, 32KiB L1i cache, 256KiB L2 cache, and 6MiB L3 cache. In order to perform a fair comparison, we have selected the following common parameters for all of the implementations: group generator, number of clients, number of servers, and the finite field for the Shamir’s secret sharing.
We have used a benchmarking dataset for the experimental evaluation. More precisely, we have used the individual household electric power consumption dataset by the UC Irvine machine learning repository (https://archive.ics.uci.edu/ml/datasets/Individual+household+electric+power+consumption#). The values represent electricity consumption provided by smartmeters. We note that, since the values in the dataset are float numbers, we need to preprocess them in order to employ them in our constructions by multiplying all of the input values by 100. Below, we list the required computation cost (in time) for all different algorithms of the proposed constructions.
We test our constructions for 500 clients, 3 servers, and a 64 -bit prime number for forming the finite field F that is used for the secret inputs’ shares generation. Additionally, the primes that are used for the VAHSS-LHS and VAHSS-TSS constructions are randomly generated primes of 128 bits. The timing is measured and shown in microseconds. The Sharesecret, PartialEval, and PartialProof costs are represented by their median values. For instance, for the Sharesecret algorithm, each client generates a random polynomial to be used for the shares’ generation and, since we consider 500 clients, we need to take into account their different costs. Thus, we get all of the timings and sort them in order to obtain the 250th element of the list. Similarly, we also obtain the median values for PartialEval and PartialProof. Table 7 illustrates the time in microseconds for 500 clients for the three different constructions.
Our tests were extended to different amounts of clients, ranging between 500 and 1000, while we fixed the number of servers to 3. Moreover, we should note that we ran our experiments for several prime numbers of various sizes and no significant change was noticed; therefore, these results are omitted. Below, we provide the results for the algorithms, which performed noticeably different for different parameters, as illustrated by figures. Figure 2 shows the timing for executing the PartialEval and PartialProof algorithms in each of our constructions. More precisely, Figure 2a shows the VAHSS-HSS case, Figure 2b demonstrates the VAHSS-LHS case, while the VAHSS-TSS case is depicted in Figure 2c. The graphs show how the timing changes depending on the number of clients participating in the computation. Next, Figure 3 shows the time that is required for computing the Finalproof in each of the constructions, representing again how the performance varies according to a different amount of clients. Finally, Figure 4 shows the timing for executing the Verify algorithm given the outputs from each server and from the clients. We remind the reader that anyone may run the Verify algorithm in order to check the correctness of the resulted y value and obtain y itself.
For further details, the code is available in a github repository (https://github.com/tsaloligeorgia/AddVHSS).

6. Discussion

We have presented three verifiable additive homomorphic secret sharing (VAHSS) constructions and, then, provided their theoretical evaluation. Furthermore, we developed a prototype and compared the performance (required computation time) of the proposed constructions for each used algorithm, given different parameters and conditions, as shown in Section 5.2. To the best of our knowledge, no existing scheme achieves privacy-preserving distributed verifiable aggregation based on homomorphic operations.
As mentioned earlier, each construction relies on a different mathematical component and might be used in different application scenarios. More precisely, the constructions differ on how the partial evaluations (PartialEval) and the partial proofs (PartialProof) are generated and who performs each computation. For instance, in the VAHSS-HSS construction, clients are only needed to execute the Sharesecret algorithm for generating m shares, and the rest of the computations (required to produce the sum y and the proof σ ) are performed by the servers. Nevertheless, the VAHSS-LHS construction requires that each client deals with the Setup, ShareSecret, and PartialProof algorithms. In fact, in this case, the clients are the ones that generate the partial proofs instead of the servers, utilizing their private RSA key. Moreover, in the VAHSS-TSS construction, the client runs the Setup and ShareSecret, while the servers deal with the execution of the other algorithms. Additionally, the VAHSS-TSS solution is based on a threshold signature sharing scheme and, as a result, a coalition of servers is required to perform the PartialProof algorithm; not all of the m servers are needed.
The computation cost required by each construction is different, as demonstrated in Section 5. However, this does not necessarily imply that one construction is better than another. Actually, it shows that there is a trade-off to choose from. For example, if the employed devices to function as clients have power/process constraints, then the best option could be the construction VAHSS-HSS, since it requires fewer computations and, as a consequence, it is less expensive regarding power consumption. However, if the employed clients are devices with significant power resources and the application requires that the clients produce the partial proofs, then the best option would be the VAHSS-LHS construction.
Furthermore, the metric of the number of operations could be used to establish which flavor of VAHSS is more appropriate, depending on the application setting and, in this case, the VAHSS-HSS construction requires fewer operations on the client-side. The prototype implementation and evaluation reinforces the fact that the VAHSS-HSS construction presents better timing for most of the required operations. As an additional metric for comparison, we employ the communication overhead (required bandwidth) for each of the proposed constructions. More precisely, Figure 5, Figure 6 and Figure 7 show the required bandwidth usage for each construction. The figures give the number of bytes received and sent per client and per server. Figure 5 shows that the VAHSS-HSS construction uses fewer bytes per client than the other constructions, since it only needs to send the shares. In the VAHSS-LHS construction, the client needs to receive the secret key and verification key, and the clients generate and share the proofs. In the VAHSS-TSS case, there is a significant reduction in the required transferred data. However, it is still higher than the required communication overhead in the VAHSS-HSS construction, since it needs to output a matrix and receive two big prime numbers.
Application scenarios: Mobile phones, wearables, and other Internet-of-Things (IoT) devices are all connected to distributed network systems. These devices generate a lot of data that often need to be aggregated to compute statistics, or even employed for user modeling and personalization of clients/users. For instance, a direct application of our constructions could be the measurement of electricity consumption (as well as water or gas consumption) in a specific region. More precisely, if we consider that each household in a specific region has an electricity consumption that is equal to x i , then, by employing our proposed constructions, the electricity production company could check what is the required energy consumption (by computing the sum i = 1 n x i , where n denotes the number of households) in that specific region and adjust the electricity production accordingly. Furthermore, by employing the verifiability property, the electricity consumption company can detect possible leaks of faults in how the electrical energy is handled. In our prototype, we use the data on the consumption of electricity and, more precisely, the UC Irvine machine learning repository. Because this is one of the most representative settings, all three constructions are suitable to be employed in this application, depending on the resources of the employed sensors/clients in different households. If we consider that multiple companies are collaborating in this aggregation process, then the collected data could be aggregated by multiple servers that collaborate or not.
Another scenario, where our constructions could be suitable are health monitoring settings, where a health provider may want to measure the average physical activity levels or patient conditions (e.g., temperature) in specific regions in order to draw conclusions about the health conditions of parts of the population and accordingly adjust services. For instance, health insurance companies could offer discounts to families or neighborhoods, depending on their physical activity, while the verifiability property provides transparency and fairness guarantees regarding the provided services from the health insurance company (https://www.generaliglobalhealth.com/news/global-insights/insurtech/digital-technology-transforming-global-healthcare.html). Similarly, the proposed constructions would facilitate the aggregation process and collaboration between multiple hospitals that store confidential patient records and need to aggregate data in order to decide on the diagnosis and treatment of patients.
Besides, an important characteristic of our constructions is that the clients (from where the data are collected) do not need to communicate with each other. Thus, they could be easily employed in order to achieve reliable and verifiable environmental monitoring, when environmental sensors collecting appropriate measurements (e.g., temperature, humidity, CO 2 , ozone, etc.) are spread in large regions and the sensors are not in the communication range of each other. More precisely, consider the setting where monitoring the air quality of specific neighborhoods in a city is needed. By employing sensors that are spread in large regions, data can be collected and then use the VAHSS-HSS construction to sum the measurement of CO 2 . In this case, we do not rely only on one server, but on several servers to aggregate the measurements, while the verifiability property can be employed to guarantee the integrity of the aggregation process.

7. Conclusions

Major security and privacy challenges exist in the context of joint computations that are outsourced to untrusted cloud servers. Sensitive information of individuals might be leaked or malicious cloud servers might attempt to alter the aggregation results. In this work, we presented three concrete constructions for the verifiable additive homomorphic secret sharing (VAHSS) problem. We provided a solution based on homomorphic hash functions, a solution that uses linear homomorphic signatures and a construction based on a threshold signature sharing scheme. We proved all three constructions correct, secure, and verifiable. These constructions allow for any verifier to obtain the value y that is the sum of the clients’ secret inputs and confirm its correctness; without compromising the clients’ privacy or relying on trusted servers and without requiring any communication between the clients. We demonstrated the theoretical analysis of our work, showing the amount of computational cost that is required for each construction both from the clients’ and servers’ side. Subsequently, our experimental results illustrated how the different operations correspond to the required (computation) time with respect to the algorithms that are executed. Thus, the appropriate construction may be employed, depending on the available resources, requirements, and assumptions (e.g., communication between servers or no communication). We believe that our proposed VAHSS constructions can be employed in various applications that require the secure aggregation of data that were collected from multiple clients (e.g., smart metering, environmental monitoring, and health databases) and provide a practical and provably secure distributed solution, while avoiding single point of failures and any leakage of sensitive information.

Author Contributions

Conceptualization, G.T. and A.M.; implementations, G.B. and G.T.; writing—original draft preparation, G.T.; writing—review and editing, G.T., G.B. and A.M.; supervision, A.M. All authors have read and agreed to the published version of the manuscript.

Funding

This work was partially supported by the Wallenberg AI, Autonomous Systems and Software Program (WASP) funded by the Knut and Alice Wallenberg Foundation. Gustavo Banegas is funded by WASP expedition project Massive, Secure, and Low-Latency Connectivity for IoT Applications.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Tsaloli, G.; Mitrokotsa, A. Sum It Up: Verifiable Additive Homomorphic Secret Sharing. In Information Security and Cryptology—ICISC 2019; Seo, J.H., Ed.; Springer International Publishing: Cham, Switzerland, 2020; pp. 115–132. [Google Scholar]
  2. Tsaloli, G.; Liang, B.; Mitrokotsa, A. Verifiable Homomorphic Secret Sharing. In Proceedings of the 12th International Conference on Provable Security, ProvSec 2018, Jeju, Korea, 25–28 October 2018; pp. 40–55. [Google Scholar] [CrossRef]
  3. Yao, H.; Wang, C.; Hai, B.; Zhu, S. Homomorphic Hash and Blockchain Based Authentication Key Exchange Protocol for Strangers. In Proceedings of the International Conference on Advanced Cloud and Big Data (CBD), Lanzhou, China, 12–15 August 2018; pp. 243–248. [Google Scholar] [CrossRef]
  4. Krohn, M.; Freedman, M.; Mazieres, D. On-the-fly verification of rateless erasure codes for efficient content distribution. In Proceedings of the IEEE Symposium on Security and Privacy, Berkeley, CA, USA, 12 May 2004; pp. 226–240. [Google Scholar] [CrossRef]
  5. Catalano, D.; Marcedone, A.; Puglisi, O. Authenticating Computation on Groups: New Homomorphic Primitives and Applications. In Advances in Cryptology—ASIACRYPT 2014; Sarkar, P., Iwata, T., Eds.; Springer: Berlin/Heidelberg, Germany, 2014; pp. 193–212. [Google Scholar]
  6. Bozkurt, İ.N.; Kaya, K.; Selçuk, A.A. Practical Threshold Signatures with Linear Secret Sharing Schemes. In Progress in Cryptology—AFRICACRYPT 2009; Preneel, B., Ed.; Springer: Berlin/Heidelberg, Germany, 2009; pp. 167–178. [Google Scholar]
  7. Shamir, A. How to share a secret. Commun. ACM 1979, 22, 612–613. [Google Scholar] [CrossRef]
  8. Boyle, E.; Gilboa, N.; Ishai, Y. Group-Based Secure Computation: Optimizing Rounds, Communication, and Computation. In Advances in Cryptology—EUROCRYPT 2017; Springer International Publishing: Cham, Switzerland, 2017; Volume 10211, pp. 163–193. [Google Scholar] [CrossRef]
  9. Benaloh, J.C. Secret sharing homomorphisms: Keeping shares of a secret secret. In Conference on the Theory and Application of Cryptographic Techniques; Springer: Berlin, Germany, 1987. [Google Scholar]
  10. Boyle, E.; Gilboa, N.; Ishai, Y. Function Secret Sharing. In Advances in Cryptology—EUROCRYPT 2015; Springer: Berlin, Germany, 2015; Volume 9057, pp. 337–367. [Google Scholar] [CrossRef]
  11. Boyle, E.; Gilboa, N.; Ishai, Y. Function Secret Sharing: Improvements and Extensions. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security—CCS’16, Vienna, Austria, 24–28 October 2016; pp. 1292–1303. [Google Scholar] [CrossRef]
  12. Damgård, I.; Pastro, V.; Smart, N.; Zakarias, S. Multiparty Computation from Somewhat Homomorphic Encryption. In Advances in Cryptology—CRYPTO 2012; Safavi-Naini, R., Canetti, R., Eds.; Springer: Berlin/Heidelberg, Germany, 2012; pp. 643–662. [Google Scholar]
  13. Damgård, I.; Keller, M.; Larraia, E.; Pastro, V.; Scholl, P.; Smart, N.P. Practical Covertly Secure MPC for Dishonest Majority—Or: Breaking the SPDZ Limits. In Computer Security—ESORICS 2013; Crampton, J., Jajodia, S., Mayes, K., Eds.; Springer: Berlin/Heidelberg, Germany, 2013; pp. 1–18. [Google Scholar]
  14. Boyle, E.; Garg, S.; Jain, A.; Kalai, Y.T.; Sahai, A. Secure Computation against Adaptive Auxiliary Information. In Advances in Cryptology—CRYPTO 2013; Canetti, R., Garay, J.A., Eds.; Springer: Berlin/Heidelberg, Germany, 2013; pp. 316–334. [Google Scholar]
  15. Baum, C.; Damgård, I.; Orlandi, C. Publicly Auditable Secure Multi-Party Computation. In Security and Cryptography for Networks; Abdalla, M., De Prisco, R., Eds.; Springer International Publishing: Cham, Switzerland, 2014; pp. 175–196. [Google Scholar]
  16. Catalano, D.; Fiore, D.; Warinschi, B. Efficient Network Coding Signatures in the Standard Model. In Public Key Cryptography—PKC 2012; Fischlin, M., Buchmann, J., Manulis, M., Eds.; Springer: Berlin/Heidelberg, Germany, 2012; pp. 680–696. [Google Scholar]
  17. Bellare, M.; Goldreich, O.; Goldwasser, S. Incremental Cryptography: The Case of Hashing and Signing. In Advances in Cryptology—CRYPTO ’94; Desmedt, Y.G., Ed.; Springer: Berlin/Heidelberg, Germany, 1994; pp. 216–233. [Google Scholar]
  18. Schabhüser, L.; Butin, D.; Buchmann, J. Context Hiding Multi-key Linearly Homomorphic Authenticators. In Topics in Cryptology—CT-RSA 2019; Matsui, M., Ed.; Springer International Publishing: Cham, Switzerland, 2019; pp. 493–513. [Google Scholar]
  19. Dorn, W.S. Generalizations of Horner’s rule for polynomial evaluation. IBM J. Res. Dev. 1962, 6, 239–245. [Google Scholar] [CrossRef]
Figure 1. n clients outsourcing the joint addition of their joint inputs to m servers.
Figure 1. n clients outsourcing the joint addition of their joint inputs to m servers.
Cryptography 04 00025 g001
Figure 2. Time for PartialEval and PartialProof in our constructions. (a) Time for PartialEval and PartialProof in VAHSS-HSS. (b) Time for PartialEval and PartialProof in VAHSS-LHS. (c) Time for PartialEval and PartialProof in VAHSS-TSS.
Figure 2. Time for PartialEval and PartialProof in our constructions. (a) Time for PartialEval and PartialProof in VAHSS-HSS. (b) Time for PartialEval and PartialProof in VAHSS-LHS. (c) Time for PartialEval and PartialProof in VAHSS-TSS.
Cryptography 04 00025 g002
Figure 3. Time for FinalProof in our constructions. (a) Time for the FinalProof algorithm in VAHSS-HSS. (b) Time for the FinalProof algorithm in VAHSS-LHS. (c) Time for the FinalProof algorithm in VAHSS-TSS.
Figure 3. Time for FinalProof in our constructions. (a) Time for the FinalProof algorithm in VAHSS-HSS. (b) Time for the FinalProof algorithm in VAHSS-LHS. (c) Time for the FinalProof algorithm in VAHSS-TSS.
Cryptography 04 00025 g003
Figure 4. Time for running Verify for each of our constructions. (a) Time for the Verify algorithm in VAHSS-HSS. (b) Time for the Verify algorithm in VAHSS-LHS. (c) Time for the Verify algorithm in VAHSS-TSS.
Figure 4. Time for running Verify for each of our constructions. (a) Time for the Verify algorithm in VAHSS-HSS. (b) Time for the Verify algorithm in VAHSS-LHS. (c) Time for the Verify algorithm in VAHSS-TSS.
Cryptography 04 00025 g004
Figure 5. Bandwidth per serve and per client in bytes using VAHSS-HSS.
Figure 5. Bandwidth per serve and per client in bytes using VAHSS-HSS.
Cryptography 04 00025 g005
Figure 6. Bandwidth per serve and per client in bytes using VAHSS-LHS.
Figure 6. Bandwidth per serve and per client in bytes using VAHSS-LHS.
Cryptography 04 00025 g006
Figure 7. Bandwidth required per server and per client in bytes using VAHSS-TSS.
Figure 7. Bandwidth required per server and per client in bytes using VAHSS-TSS.
Cryptography 04 00025 g007
Table 1. Verifiable additive homomorphic secret sharing (VAHSS) using homomorphic hash functions.
Table 1. Verifiable additive homomorphic secret sharing (VAHSS) using homomorphic hash functions.
Secret Inputs
(Held by the Clients)
ServersPublic Values
s 1 s 2 s m
x 1 x 11 x 12 x 1 m τ 1
x 2 x 21 x 22 x 2 m τ 2
x n x n 1 x n 2 x n m τ n
Partial sums y 1 y 2 y m Total Sum: y
Partial proofs σ 1 σ 2 σ m Final Proof: σ
Table 2. VAHSS using linear homomorphic signatures.
Table 2. VAHSS using linear homomorphic signatures.
Secret Inputs
(Held by the Clients)
ServersPublic Values
s 1 s 2 s m v k
x 1 , s k x 11 x 12 x 1 m σ 1
x 2 , s k x 21 x 22 x 2 m σ 2
x n , s k x n 1 x n 2 x n m σ n
Partial sums (public) y 1 y 2 y m Final proof (public)
Total sum (public)y σ
Table 3. VAHSS with threshold signature sharing.
Table 3. VAHSS with threshold signature sharing.
Secret Inputs
(Held by the Clients)
Public ValuesServers
s 1 s 2 s m { s j 1 , , s j t }
x 1 , d 1 H ( x 1 + R 1 ) , e 1 , A 1 x 11 , ω 11 x 12 , ω 12 x 1 m , ω 1 m σ 1
x 2 , d 2 H ( x 2 + R 2 ) , e 2 , A 2 x 21 , ω 21 x 22 , ω 22 x 2 m , ω 2 m σ 2
x n , d n H ( x n + R n ) , e n , A n x n 1 , ω n 1 x n 2 , ω n 2 x n m , ω n m σ n
Partial sums (public) y 1 y 2 y m Final proof (public)
Total sum (public)y σ
Table 4. Number of operations of the VAHSS based on homomorphic hash functions (VAHSS-HSS) construction.
Table 4. Number of operations of the VAHSS based on homomorphic hash functions (VAHSS-HSS) construction.
OperationAdditionMultiplicationExponentiationRandom Sampling
Algorithm
ShareSecret (client) m t + m 1 m t + m m 1
PartialEval (server) n 1
PartialProof (server) n 1 1
FinalEval m 1
FinalProof m 1
Verify n 1 1
Table 5. Number of operations of the VAHSS based on linear homomorphic signatures (VAHSS-LHS) construction.
Table 5. Number of operations of the VAHSS based on linear homomorphic signatures (VAHSS-LHS) construction.
OperationAdditionMultiplicationExponentiationInverse ComputationRandom Sampling
Algorithm
Setup (client) n + 2
ShareSecret (client) m t + m 2 m t + m 1 m 2
PartialEval (server) n 1
PartialProof (client)3411
FinalEval m 1
FinalProofn n + 1 1
Verify n + 1 3
Table 6. Number of operations of the VAHSS based on threshold signature sharing (VAHSS-TSS) construction.
Table 6. Number of operations of the VAHSS based on threshold signature sharing (VAHSS-TSS) construction.
OperationAdditionMultiplicationExponentiationInverse ComputationRandom Sampling
Algorithm
Setup (client)11
ShareSecret (client) m t + m t 1 m t + m t + m 1 m 1 1
PartialEval (server) n 1
PartialProof (server) 2 t t
FinalEval m 1
FinalProof (server) t + n 2 n + 2
Verify n 1 1
Table 7. Timing (in microseconds) for each of our constructions.
Table 7. Timing (in microseconds) for each of our constructions.
ConstructionVAHSS-HSSVAHSS-LHSVAHSS-TSS
Algorithm
Setup0 1 2540310
Sharesecret300298299
PartialEval584776
PartialProof49107224,293
FinalEval 2 479979882
Final Proof550 3 53717,192
Verify1479091294
1 It does not require key generation; 2 Timing in nanoseconds; 3 Timing in nanoseconds.
Back to TopTop