Improved Signature Schemes for Secure Multi-party Computation with Certified Inputs

Abstract

The motivation for this work comes from the need to strengthen security of secure multi-party protocols with the ability to guarantee that the participants provide their truthful inputs in the computation. This is outside the traditional security models even in the presence of malicious participants, but input manipulation can often lead to privacy and result correctness violations. Thus, in this work we treat the problem of combining secure multi-party computation (SMC) techniques based on secret sharing with signatures to enforce input correctness in the form of certification. We modify two currently available signature schemes to achieve private verification and efficiency of batch verification and show how to integrate them with two prominent SMC protocols.

1 Introduction

Secure multi-party computation (SMC) deals with protecting confidentiality of private data during computation in distributed or outsourced settings. This is a mature research field with a variety of techniques for securely evaluating arbitrary functions by two or more computational parties who are not permitted to have access to the inputs in the clear. Recent rapid advances in this field significantly reduced SMC overhead, and we are witnessing growing deployment of SMC solutions in practice [3, 4, 25].

A standard formulation of SMC defines the problem as evaluating some function f on k ($\ge 1$) private inputs $\mathsf{in}_1, {\ldots }, \mathsf{in}_k$ from different sources by m ($\ge 2$) computational parties and producing s ($\ge 1$) outputs which get revealed to the designated parties. The security objective is that no information about the private data is revealed to any party beyond the agreed upon output (or no information at all if a party receives no output). Standard security definitions model the participants as semi-honest (who correctly follow the prescribed computation, but might analyze the messages they receive in the attempt to learn unauthorized information) or malicious (who can arbitrary deviate from the computation in the attempt to learn unauthorized information). Output correctness guarantees must also hold in these respective models. These definitions, however, provide no guarantees with respect to what inputs are entered into the computation. That is, a malicious participant can modify its real input in the attempt to harm security or correctness. For example, the participant can perturb his input in such a way that all output recipients receive incorrect information, but he can compensate for the error and learn the correct result. Or, alternatively, the participant can modify his input in such a way as to learn the maximum amount of information about private data of others’, beyond what would be available if the computation was run on truthful inputs ([2] gives an example of this attack in the context of computing with genomic data). These attacks are beyond the scope of standard SMC security models and cannot be mitigated.

In this work, we study enforcement of correct (i.e., truthful) inputs being used in SMC via input certification. That is, at the time of computation initiation, a party supplying input accompanies it by a certificate and proves that the data input into the computation is identical to what has been certified. It goes without saying that the certificate and its verification must maintain data confidentiality. There are many types of data which is generated or can be verified by an authority (such as the government, a medical facility, etc.) who can issue private certification to the user at that time.

The problem of enforcing input correctness via certification has been studied for specific SMC applications (e.g., anonymous credentials [8] or set operations [10, 15]) and, more recently, for general functions [2, 24, 33]. However, all of the efforts we are aware of for the general case have been for secure two-party computation based on garbled circuits (GCs). It is an interesting problem to study because GC evaluation does not naturally combine with signature or certification techniques, but we also believe that this problem deserves attention beyond GCs. For this reason, in this work we treat the problem of input certification in the multi-party setting based on secret sharing.

Because both secret sharing and signature schemes exhibit algebraic structure, the use of signatures appears to be a natural choice in enabling input certification in secret sharing based SMC. We note that, unlike many other conventional uses of signatures, this problem setting requires that signature verification is performed privately, without revealing any information about the signed message to the verifier. Another important consideration is that in many SMC applications the size of the input is large (consider, e.g., genomic data). Because signatures are built using rather expensive public-key techniques, which in the privacy-preserving setting often need to be combined with zero-knowledge proofs, we are interested in improving signature verification time using batch verification of multiple signatures.

In this work we study two types of signatures in the context of this problem: (i) CL-signatures [6, 7] which were designed for anonymity applications and achieve both message privacy and unlinkability of multiples showings of the same signature and (ii) conventional ElGamal signatures [17]. After formulating the necessary security guarantees of private signature verification, we show that signature showing in [7] can be simplified to meet our definition of message privacy and construct a batch verifier for the resulting signature. In the case of ElGamal signatures, we first modify a provably secure ElGamal signature scheme from [29] to achieve private verification and consequently construct a batch verifier for the resulting algorithm. Our batch verifiers use the small exponents technique [1] to randomize multiple signatures to ensure that batch verification can succeed only when all individual signatures are valid.

Another component of this work deals with combining the developed signature schemes with SMC techniques secure in the malicious model. Toward this goal, we identify two prominent constructions of SMC based on secret sharing: (i) Damgård-Nielsen solution [13] of low communication complexity where the number of corrupted parties is below m/3 and (ii) SPDZ [14] with a very fast online phase and tolerating any number of corruptions. We show how to modify their input phase to use our signatures with an additional optimization of utilizing a single commitment to multiple signatures instead of using individual commitments.

Finally, we implement our ElGamal-based signature scheme and SPDZ-based use of certified inputs for a varying number of messages (SMC inputs) and show that they result in efficient performance. The techniques are general enough to be applicable to other signature algorithms (such as ElGamal-based DSA and others).

2 Related Work

The only publications on certified inputs for SMC that we are aware of were mentioned above (i.e., techniques for specific applications [8, 10, 15] and techniques for GCs [2, 24, 33]). There is also work on using game theory to incentivize rational players to enter their inputs truthfully (see, e.g., [22, 31] among others), but such techniques are complementary to this work and can be used for inputs which cannot be feasibly certified.

The first systematic treatment of batch signature verification appeared in [1], although interest in batch verification of signatures and other cryptographic operations in general goes further back. More recent techniques for batch verification include [5, 18] among others, although none of them target private verification (defined in Sect. 3.1) which is central to this work.

A related concept is that of aggregate signatures. It allows a number of different signatures to be aggregated into a single short signature to save bandwidth in resource-constrained environments. Aggregate signature schemes were developed for CL signatures on which we build in this work [26]. There are, however, two central differences from our work: (i) aggregate signatures have strictly weaker security guarantees than batch verification [5] because verification of an aggregate signature can succeed even if the individual signatures included in it do not verify, and (ii) message privacy was not considered. Guo et al. [21] use privacy features of CL signatures and construct an aggregate CL signature, but the difference in the security guarantees still stands.

Privacy-preserving signature schemes have been studied in other contexts. Examples include anonymous signatures [32], confidential signatures [16], and pseudorandom signatures [19]. There is a connection between these concepts (especially, confidential signatures) and our notion of signatures with privacy, but these prior concepts provide message confidentiality guarantees only for high-entropy message spaces.

3 Preliminaries

3.1 Definitions

We next describe notation and definitions used in the rest of the paper. A function $\epsilon : \mathbb {N} \rightarrow \mathbb {R}_{\ge 0}$ is negligible (denoted, $\mathsf {negl}$) if for every positive polynomial $p(\cdot )$ there exists an integer N such that for all $\kappa >N$ $\epsilon (\kappa )< \frac{1}{p(\kappa )}$. The notation $G = \langle g \rangle$ means that g generates group G. We rely on groups with pairings, which we review next.

Definition 1

(Bilinear map). A one-way function $e : G \times G \rightarrow \mathbf {G}$ is a bilinear map if it is:

• (Efficient) G and $\mathbf {G}$ are groups of the same prime order q and there exists an efficient algorithm for computing e.

• (Bilinear) For all $g, h \in G$ and $a, b \in \mathbb {Z}_q$, $e(g^a,h^b) = e(g,h)^{ab}$.

• (Non-degenerate) If g generates G, then e(g, g) generates $\mathbf {G}$.

We assume that there is a trusted setup algorithm $\mathsf {Setup}$ that, on input a security parameter $1^\kappa$, outputs the setup for group $G = \langle g \rangle$ of prime order $q \in \varTheta (2^\kappa )$ that has a bilinear map e, and e(g, g) generates $\mathbf {G}$ of order q. That is, $(q, G, \mathbf {G}, g, e) \leftarrow \mathsf{Setup}(1^\kappa )$.

Definition 2

(Signature scheme). A signature scheme consists of three algorithms:

• $\mathsf {KeyGen}$ is a probabilistic polynomial-time (PPT) algorithm that, on input a security parameter $1^\kappa$, generates a public-private key pair (pk, sk).

• $\mathsf {Sign}$ is a PPT algorithm that, on input a secret key sk and message m from the message space, outputs signature $\sigma$.

• $\mathsf {Verify}$ is a deterministic polynomial-time algorithm that, on input a public key pk, a message m, and a signature $\sigma$, outputs a bit.

Security of a signature scheme is defined as difficulty of existential forgery under a chosen-message attack by any PPT adversary, which we provide in Appendix A.

Batch verification [1] is a method for verifying a set of signatures on different messages signed by the same or different signers, which is intended to be more efficient than verifying them independently. In this work, we are primarily interested in batch verification of signatures produced by the same signer. Batch verification is defined as:

Definition 3

(Batch verification of signatures [5]). Let $\varPi = (\mathsf {KeyGen}, \mathsf{Sign}$, $\mathsf{{Verify}})$ be a signature scheme and $\kappa$ be a security parameter. Let $(pk_{1}, sk_{1})$, ..., $(pk_{n}, sk_{n})$ be key pairs of n signers $P_{1}, \ldots , P_{n}$ produced by $\mathsf {KeyGen}(1^{\kappa })$ and $PK=\{pk_{1}, \ldots , pk_{n} \}$. Let $\mathsf {Batch}$ be a PPT algorithm that takes a set of tuples $(pk_i, m_i, \sigma _i)$ and outputs a bit. Then $\mathsf {Batch}$ is a batch verification algorithm if the following holds:

• If $pk_i \in PK$ and $\mathsf {Verify}(pk_i, m_{i}, \sigma _{i}) = 1$ for all $i \in [1, n]$, then $\mathsf {Batch}((pk_1, m_{1}, \sigma _{1})$, ..., $(pk_n, m_{n}, \sigma _{n}))=1$.

• If $pk_i \in PK$ for all $i \in [1, n]$ and $\mathsf {Verify}(pk_i, m_{i}, \sigma _{i})=0$ for at least one $i \in [1, n]$, then $\mathsf {Batch}((pk_1, m_{1}, \sigma _{1}), \ldots$, $(pk_n, m_{n}, \sigma _{n}))=1$ with probability at most $2^{-\kappa }$.

In our constructions, we rely on zero-knowledge proofs of knowledge (ZKPKs) and commitments. A ZKPK is a two-party protocol between a prover and a verifier, during which the prover convinces the verifier that a certain statement is true without revealing anything else about the values used in the statement. Informally, a ZKPK should satisfy the following properties: (i) completeness: if the statement is true, then an honest verifier will be convinced of the statement’s validity after interacting with an honest prover; (ii) soundness: if the statement is false, then no cheating prover can convince an honest verifier that the statement is true, except with a negligible probability (in the security parameter); and (iii) zero-knowledge: if the statement is true, then no cheating verifier can learn anything other than the fact that the statement is true. We are interested in simple statements over discrete logarithms such as those described, e.g., in [9, 11].

A commitment scheme allows one to commit to message m in such a way that the commitment reveals no information about m and, given a commitment on m, it is not feasible to open it to a value other than m. In other words, once the value m has been committed to, it cannot be changed and kept private until the user reveals it. These properties are known as hiding and binding. A commitment scheme is defined by $\textsf {Commit}$ and $\textsf {Open}$ algorithms, and we omit their formal specification here. We only note that $\textsf {Commit}$ is a randomized algorithm and for that reason we use notation com(m, r) to denote a commitment to m using randomness r.

As mentioned before, in this work we are interested in signature schemes which allow for private verification of signature validity without revealing any information about the signed message. We refer to such schemes as signature schemes with privacy and refer to the corresponding verification process as private verification to distinguish it from the conventional signature verification process. This property implies that the signature itself reveals no information about the signed message. In the rest of this subsection, we provide the necessary definitions for signature schemes with privacy. We start by re-defining the traditional formulation of a signature scheme as follows:

Definition 4

(Signature scheme with privacy). A signature scheme with privacy consists of the following polynomial-time algorithms:

• $\mathsf {KeyGen}$ is a PPT algorithm that, on input a security parameter $1^\kappa$, generates a public-private key pair (pk, sk).

• $\mathsf {Sign}$ is a PPT algorithm that, on input a secret key sk and message m from the message space, outputs signature $\sigma$ and optional auxiliary data $x_\sigma$.

• $\mathsf {PrivVerify}$ is a possibly interactive algorithm, in which the prover and the verifier hold a public key pk, the prover has access to m and $(\sigma , x_\sigma )$ output by $\textsf {Sign}$, supplies a message encoding $x_m$ and a (possibly modified) signature $\tilde{\sigma }$ to the verifier, and the verifier outputs a bit.

With this definition, we allow for two possibilities: either $x_\sigma$ produced during signing can be used to form $x_m$ used during verification, or $x_\sigma$ is empty and anyone with access to $\sigma$ and m can compute a suitable (possibly randomized) $x_m$ for signature verification.

To ensure unforgeability, $\textsf {PrivVerify}$ must verify signature $\tilde{\sigma }$ similar to the way $\textsf {Verify}$ would and must enforce that the prover knows the message m (encoded in $x_m$) to which the $\tilde{\sigma }$ corresponds. Because in this work $x_m$ always takes the form of a commitment to m, com(m, r), we explicitly incorporate this in our security definition.

The security (unforgeability) experiment of a signature with privacy is similar to the conventional definition (see $\textsf {ForgeSig}$ in Appendix A) with two conceptual differences: (i) After producing the challenge pair $(\tilde{\sigma }^*, x_{m^*})$, the adversary $\mathcal {A}$ is required to prove in zero-knowledge that $x_{m^*}$ corresponds to a message, a signature on which has not been queried before. (ii) The signature forging experiment now invokes modified verification algorithm $\textsf {PrivVerify}$ instead of $\textsf {Verify}$. The signature is verified against a committed value $x_{m^*} = com(m^*, r)$, but the prover is also required to prove the knowledge of message $m^*$ itself encoded in the commitment. Thus, we obtain the following:

Experiment $\mathsf {ForgePrivSig}_{\mathcal {A}, \varPi }(\kappa )$:

• 1. The challenger creates a key pair $(pk, sk) \leftarrow \mathsf {Gen}(1^\kappa )$ and gives pk to $\mathcal {A}$.

• 2. $\mathcal {A}$ has oracle access to $\mathsf {Sign_{sk}}(\cdot )$. For each message m that $\mathcal {A}$ queries the oracle, m is stored in list $\mathcal {Q}$ and $\mathcal {A}$ learns $(\sigma , x_\sigma ) = {\textsf {Sign}}_{sk}(m)$.

• 3. The challenger and $\mathcal {A}$ engage in $\textsf {PrivVerify}$, as part of which $\mathcal {A}$ reveals the challenge pair $(x_{m^*}, \tilde{\sigma }^*)$. $\mathcal {A}$ proves in ZK that it knows the opening of the commitment $x_{m^*} = com(m^*, r)$ and that $m^* \not \in \mathcal {Q}$.

• 4. Output 1 if $\mathsf {PrivVerify}$ returns 1 and all other checks succeed; otherwise, output 0.

To model private verification, we define the following message indistinguishability experiment for a signature scheme with privacy $\varPi = ({\textsf {KeyGen}}, \mathsf{Sign}, \mathsf{PrivVerify})$:

Experiment $\mathsf {MesInd}_{\mathcal {A}, \varPi }(\kappa )$:

• 1. The challenger creates a key pair $(pk, sk) \leftarrow \mathsf {KeyGen}(1^\kappa )$ and gives pk to $\mathcal {A}$.

• 2. $\mathcal {A}$ has oracle access to $\mathsf {Sign}_{sk}(\cdot )$ and learns the algorithm’s output for messages of its choice. $\mathcal {A}$ eventually outputs a pair $(m_0, m_1)$.

• 3. The challenger draws a random bit $b \in \{0, 1\}$. Upon $\mathcal {A}$’s request, it executes $(\sigma _b, x_{\sigma _b}) \leftarrow \mathsf{Sign}_{sk}(m_b)$. It computes $x_{m_b}$ and returns $(\tilde{\sigma }_b, x_{m_b})$ where $\tilde{\sigma }_b$ is derived from $\sigma _b$. If $x_{m_b}$ and/or $\tilde{\sigma }_b$ are probabilistic, $\mathcal {A}$ can request multiple encodings $(\tilde{\sigma }^{(i)}_b, x^{(j)}_{m_b})$ for the same signature and $i, j \in \mathbb {N}$. These signature verification queries are repeated the desired number of times.

• 4. $\mathcal {A}$ eventually outputs a bit $b'$. The experiment outputs 1 if $b = b'$, and 0 otherwise.

Definition 5

(Private verification). A signature scheme $\varPi =(\mathsf {KeyGen}, \mathsf {Sign}$, $\mathsf {PrivVerify})$ is said to achieve private verification if for all PPT adversaries $\mathcal {A}$ there is a negligible function $\mathsf {negl}$ such that $Pr [\mathsf {MesInd}_{\mathcal {A}, \varPi } (\kappa )=1] \le \frac{1}{2} + \mathsf {negl}(\kappa ).$

On the relationship of private verification and proving possession of a signature in zero-knowledge. Prior work on using signatures in privacy-preserving contexts [6, 7] allows for proving possession of a signature in ZK. Their definition implies that no information about the signed message is revealed and two instances of proving knowledge of a signature cannot be linked to each other. Our definition of private verification is weaker in the sense that we do not attempt to hide whether the same or different signature is verified at two different times, but fully protect the signed data itself. Unlinkability of signature showings is generally not needed in our application, where a user can use its data (e.g., DNA data) in multiple computations and does not need to hide the fact that the same data was used (which can be determined from the computation itself). Thus, we only protect information about the signed values and this difference allows for faster signature verification while still maintaining the necessary level of security.

When we consequently discuss batch verification of signatures with privacy, we modify the interface of $\textsf {Batch}$ to match that of $\textsf {PrivVerify}$.

3.2 Signature and Commitment Schemes

In this work, we build on Camenisch-Lysyanskaya signature Scheme A from [7] (CL Scheme A for short), defined as follows:

• Key generation: On input $1^\kappa$, execute $(q, G, \mathbf {G}, g, e) \leftarrow \mathsf {Setup}(1^\kappa )$, choose random $x, y \in \mathbb {Z}_{q}$ and compute $X=g^x, Y=g^y$. Set $sk=(x,y)$ and $pk=(q, G, \mathbf {G}, g, e, X, Y)$.

• Signing: On input message $m \in \mathbb {Z}_q$, secret key $sk=(x,y)$ and public key $pk=(q, G, \mathbf {G}, g, e, X, Y)$, choose random $a \in G$ and output $\sigma = (a, b, c)=(a, a^{y}, a^{x+mxy})$.

• Verification: On input message m, $pk=(q, G, \mathbf {G}, g, e, X, Y)$, and signature $\sigma =(a, b, c)$, check whether $e(a,Y)=e(g,b)$ and $e(X,a)\cdot e(X,b)^{m}=e(g,c)$. If both equalities hold, output 1; otherwise, output 0.

• Proof of signature: The prover and verifier have $pk = (q, G, \mathbf {G}, g, e$, X, Y). The prover also has $m \in \mathbb {Z}_{q}$ and the corresponding signature $\sigma = (a, b, c) = (a, a^{y}, a^{x+mxy})$.

  • 1. The prover chooses random $r', r'' \in \mathbb {Z}_{q}$, computes blinded signature $\tilde{\sigma } = (a^{r''}, b^{r''}, c^{r''r'}) = (\tilde{a}, \tilde{a}^{y}, (\tilde{a}^{x+mxy})^{r'}) = (\tilde{a}, \tilde{b}, \hat{c})$, and sends it to the verifier.

  • 2. Let $\mathbf {v}_{x}=e(X, \tilde{a})$, $\mathbf {v}_{xy}=e(X, \tilde{b})$, and $\mathbf {v}_{s}=e(g, \hat{c})$. The prover and verifier engage in the following ZKPK: ${PK}\{(\mu ,\rho ): \mathbf {v}_{x}^{-1}=\mathbf {v}_{xy}^{\mu } \mathbf {v}_{s}^{\rho }\}$.

  • 3. The verifier accepts if it accepts the proof above and $e(\tilde{a}, Y)=e(g,\tilde{b})$.

Unforgeability of CL Scheme A is shown under the LRSW assumption [27], while demonstrating the zero-knowledge property of proving possession of a signature uses no additional assumptions other than hardness of discrete logarithm.

We also build on ElGamal signature scheme [17]. Because the original construction allows for existential forgeries, we use its provably secure variant by Pointcheval and Stern [29, 30]. The setup assumes an $\alpha$-hard prime number p for some fixed $\alpha$, defined as having $p-1 = qR$ where q is prime and $R \le |p|^{\alpha }$. This is necessary for the difficulty of discrete logarithm and is more general than requiring the use of prime order q. This signature scheme uses a hash function H and is shown to be unforgeable in the random oracle model (i.e., H is modeled as a random oracle).

• Key generation: On input a security parameter $1^\kappa$, choose a large $\alpha$-hard prime p and a generator g of $\mathbb {Z}_p^*$. Then choose random $x \in \mathbb {Z}_{p-1}$ and compute $y=g^x \bmod p$. Set $sk=x$ and $pk=(p, g, y)$.

• Signing: On input message m, secret key $sk=x$ and public key $pk=(p, g, y)$, choose random $k \in \mathbb {Z}^{*}_{p-1}$, compute $t=g^k \bmod p$ and $s \equiv (H(m||t)-xt)k^{-1} \pmod {p-1}$, where || denotes concatenation, then output $\sigma =(t, s)$.

• Verification: On input message m, public key $pk=(p,g,y)$, and signature $\sigma =(t, s)$, check whether $1<t<p$ and $g^{H(m, t)} \equiv y^{t} t^{s} \pmod {p}$. If both conditions hold, output 1; otherwise, output 0.

Lastly, we also utilize well-known Pedersen commitment scheme [28] based on discrete logarithm. The setup consists of a group G of prime order q and two generators g and h. To commit to message $m \in \mathbb {Z}_{q}$, we choose random $r \in \mathbb {Z}_{q}$ and set $com(m,r) = g^m h^r$. To open the commitment, the user reveals r. This commitment scheme is information-theoretically hiding and computationally binding (when the discrete logarithm of h to the base g is not known to the user) under the discrete logarithm assumption.

4 Constructions Based on CL Signatures

In this section, we discuss constructions based on CL signatures. We start by demonstrating that CL signatures with protocols satisfy our notion of signatures with privacy and discuss the cost of verifying multiple signatures using that construction. We consequently proceed with simplifying CL Scheme A’s verification and construct the corresponding batch verifier. The next section treats ElGamal signatures.

4.1 CL Scheme A

Recall that a signature scheme with privacy is defined as $\varPi = (\mathsf{KeyGen}, \mathsf{Sign}, \mathsf{PrivVerify})$. To use CL Scheme A in our context, we leave $\textsf {KeyGen}$ and $\textsf {Sign}$ unmodified, except that $\textsf {KeyGen}$ additionally computes $h = g^u$ for a random $u \in \mathbb {Z}_q$ and stores it in the public key, i.e., $pk = (q, G, \mathbf {G}, g, h, e, X, Y)$. $\textsf {PrivVerify}$ is realized as follows:

• $\textsf {PrivVerify}$: The prover holds signature $\sigma = (a, b, c)$ on private message $m \in \mathbb {Z}_q$ and both parties hold pk. The prover computes $x_m = com(m, r) = g^m h^r$ using random $r \in \mathbb {Z}_q$ and sends $x_m$ to the verifier. The remaining steps are the same as in the proof of signature in Scheme A above, except that the ZKPK in step 2 is modified to: ${PK}\{(\mu ,\rho ,\gamma ): x_m = g^{\mu } h^{\gamma } \wedge \mathbf {v}_{x}^{-1}=\mathbf {v}_{xy}^{\mu } \mathbf {v}_{s}^{\rho } \}$.

Note that the signing algorithm is not modified and in the verification protocol we only extend the ZKPK statement. Because the original proof of signature protocol was shown to be proof of knowledge and the signature was shown to be unforgeable, this scheme satisfied signature unforgeability. We also achieve the private verification property:

Theorem 1

CL Scheme A above is a signature scheme with privacy.

Because of space constraints, the proofs of this and most other theorems are provided in the full version.

To facilitate close comparison of different algorithms, we spell out the computation used in the ZKPK of $\textsf {PrivVerify}$ above. This will allow us to determine the exact number of operations (such as modulo exponentiations and pairing function evaluations). In this ZKPK, the prover first chooses random $v_{1}, v_{2}, v_{3} \in \mathbb {Z}_{q}$, computes $T_{1}=g^{v_{1}} h^{v_{3}}, T_{2}=\mathbf {v}_{xy}^{v_{1}} \mathbf {v}_{s}^{v_{2}}$, and sends $T_{1}$, $T_{2}$ to the verifier. The verifier chooses a challenge $e \in \mathbb {Z}_{q}$ at random and sends it to the prover. The prover responds by sending $r_{1}=v_{1}+em \bmod q$, $r_{2}=v_{2}+ er' \bmod q$, and $r_{3}=v_{3}+er \bmod q$. Finally, the verifier accepts if $g^{r_{1}} h^{r_{3}}=T_{1} x_m^e$ and $\mathbf {v}_{xy}^{r_{1}} \mathbf {v}_{s}^{r_{2}}=T_{2}\mathbf {v}_{x}^{-e}$.

When certified inputs are used in SMC, we need to evaluate the time of signature verification and integration into an SMC protocol. Thus, we consider signature issuance as a one-time cost and concentrate on verification. Then to use this scheme with secure computation, the cost of (independent) private verification of n signatures is 3n modulo exponentiations (mod exp) for signature randomization, 2n mod exp for creating commitments (n of which are for messages and are thus short), and 10n mod exp and 5n pairings for proving the knowledge of signatures. This gives us 15n mod exp (n of which are short) and 5n pairings and serves as the baseline for our comparisons.

4.2 Modified CL Scheme A

We next introduce a simplification to CL Scheme A of the previous subsection to allow for more efficient private verification in the context of SMC. To construct a signature scheme with privacy $\varPi = ({\textsf {KeyGen}}, \mathsf{Sign}, \mathsf{PrivVerify})$, we retain $\mathsf {KeyGen}$ and $\mathsf {Sign}$ algorithms of the previous subsection (i.e., the public key is augmented with h), but modify the verification algorithm $\mathsf {PrivVerify}$ as follows:

• $\mathsf {PrivVerify}$: The prover has private message $m \in \mathbb {Z}_{q}$ and the corresponding signature $\sigma =(a, b, c)=(a, a^{y}, a^{x+mxy})$; both parties hold $pk = (q, G, \mathbf {G}, g, h, e, X, Y)$.

  • 1. The prover forms a commitment to m as $x_m = com(m, r) = g^m h^r$ using randomly chosen $r \in \mathbb {Z}_q$ and sends $x_m$ to the verifier.

  • 2. The prover chooses random $r' \in \mathbb {Z}_{q}$, computes randomized signature $\tilde{\sigma }:=(a, b, c^{r'}) = ({a}, {b}, \tilde{c})$, and communicates it to the verifier.

  • 3. Let $\mathbf {v}_{x}=e(X, {a})$, $\mathbf {v}_{xy}=e(X, {b})$, and $\mathbf {v}_{s}=e(g, \tilde{c})$. The prover and verifier execute ZKPK: ${PK}\{(\mu ,\rho ,\gamma ): x_m = g^\mu h^\gamma \wedge \mathbf {v}_{x}^{-1}=\mathbf {v}_{xy}^{\mu } \mathbf {v}_{s}^{\rho }\}$.

  • 4. If the verifier accepts the proof in step 2 and $e({a}, Y)=e(g,{b})$, output 1; otherwise, output 0.

In this verification, part of signature randomization is removed, which means that the verifier will be able to link two showings of the same signature together. This change, however, does not affect the unforgeability property of the scheme. The privacy property can be stated as follows:

Theorem 2

Modified CL Scheme A above is a signature scheme with privacy.

Proof

Let $\mathcal {A}$ be a PPT adversary attacking our modified CL Scheme A. Recall that $\mathcal {A}$ has the ability to query the signing oracle and obtain signature on messages of its choice. Once $\mathcal {A}$ submits the challenge $(m_0, m_1)$, it will be given pairs $(\tilde{\sigma }^{(i)}_b, x^{(j)}_{m_b})$, where b is a random bit, $\tilde{\sigma }^{(i)}_b = (a, a^y, a^{r'_i(x+m_bxy)}) = (a, b, \tilde{c}^{(i)})$ for random $r'_i \in \mathbb {Z}_q$, and $x^{(j)}_{m_b} = g^{m_b} h^{r_j}$ for random $r_j \in \mathbb {Z}_q$, for any combination of i and j and the number of queries polynomial in $\kappa$. In other words, $\mathcal {A}$ has access to a signature with different randomizations (using $r'_i$s) and different commitments to $m_b$ (using $r_j$s for randomness).

Before we proceed with further analysis, note that the ZKPK in $\mathsf {PrivVerify}$ is zero-knowledge and thus does not reveal information about $m_b$ to $\mathcal {A}$. Furthermore, other signatures on $m_0$ and $m_1$ that $\mathcal {A}$ can obtain using its access to the signing oracle do not contribute additional information (and use unrelated randomness) and thus do not help in answering the challenge. It thus remains to analyze $\tilde{c}^{(i)}$ and $x^{(j)}_{m_b}$ values. Now note that each $\tilde{c}^{(i)}$ and $x^{(j)}_{m_b}$ are random elements in G because $r'_i, r_j$ are chosen uniformly and independently at random. This means that if we modify $\mathcal {A}$’s view to replace $m_b$ in $\tilde{c}^{(i)}$s and $x^{(j)}_{m_b}$s with a random value, this modified view will be identically distributed to that of the original $\mathcal {A}$’s view. In more detail, suppose that we modify the signature scheme to use a random value z instead of the actual message and the commitment is formed consistently to use the same z as well. Let call the resulting scheme $\varPi '$. Clearly, we have that $\mathbf {Pr}[\mathsf {MesInd}_{\mathcal {A}, \varPi '}(\kappa )=1] = \frac{1}{2}.$ Also, because the views of $\mathcal {A}$ are identical in the security experiments for $\varPi$ and $\varPi '$, we obtain that $|\mathbf {Pr}[\mathsf {MesInd}_{\mathcal {A}, \varPi '}(\kappa )=1] - \mathbf {Pr}[\mathsf {MesInd}_{\mathcal {A}, \varPi }(\kappa )=1]| = 0$. This means that $\mathcal {A}$ cannot learn any information about $m_b$ during verification in $\varPi$ and the security property follows. $\Box$

When we use this scheme for secure computation, we reduce the randomization cost by 2n mod exp. Thus the cost of private verification of n signatures is 13n mod exp (n of which are short) and 5n pairings.

4.3 Batch Verification of Modified CL Scheme A

The next step is to design batch verification for verifying n signatures. Because for our application we are primarily interested in verifying multiple signatures issued by the same signer (e.g., information about one’s genome represented as a large number of individual values), we present batch verification of signatures issued using the same key. We use a version of the small exponent test [1] that instructs the verifier to choose security parameter $l_b$ such that the probability of accepting a batch that contains an invalid signature is at most $2^{-l_b}$ (e.g., $l_b$ is set to 60 or 80 in prior work).

• $\mathsf {Batch}$: The prover holds signatures $\sigma _i = (a_i, b_i, c_i)$ on messages $m_i \in \mathbb {Z}_q$ for $i = 1, \ldots , n$, and both parties hold $pk = (q, G, \mathbf {G}, g, h, e, X, Y)$.

  • 1. The prover forms commitments $x_{m_i} = com(m_i, r_i) = g^{m_i} h^{r_i}$ using randomly chosen $r_i \in \mathbb {Z}_q$ for $i = 1, {\ldots }, n$ and sends them to the verifier.

  • 2. The prover chooses random $r'_i \in \mathbb {Z}_{q}$, computes blinded signatures $\tilde{\sigma }_i = (a_i, b_i, c_i^{r'_i}) = ({a}_i, {b}_i, \tilde{c}_i)$ for $i = 1, \ldots , n$, and sends them to the verifier.

  • 3. The verifier chooses and sends random $\delta _1, \ldots , \delta _n \in \{0, 1\}^{l_b}$ to the prover.

  • 4. The parties compute $\hat{\mathbf {v}}_{x} = e(X, \prod _{i=1}^n {a}_i^{\delta _i})$, $\hat{\mathbf {v}}_{xy_i}=e(X, {b}_i^{\delta _i})$ and $\hat{\mathbf {v}}_{s_i}=e(g, \tilde{{c}_i}^{\delta _i})$ for $i = 1, {\ldots }, n$, and engage in the ZKPK: ${PK}\big \{(\mu _1, \ldots , \mu _n, \rho _1, \ldots , \rho _n$, $\gamma _1, \ldots , \gamma _n): \hat{\mathbf {v}}_{x}^{-1} = \prod _{i=1}^n \hat{\mathbf {v}}_{xy_i}^{\mu _i} \hat{\mathbf {v}}_{s_i}^{\rho _i} \wedge x_{m_1} = g^{\mu _1} h^{\gamma _1} \wedge \cdots \wedge x_{m_n} = g^{\mu _n} h^{\gamma _n}\big \}$.

  • 5. If this proof passes and $e(\prod _{i=1}^n a_i^{\delta _i}, Y) = e(g, \prod _{i=1}^n b_i^{\delta _i})$, the verifier outputs 1; otherwise, the verifier outputs 0.

Theorem 3

$\mathsf {Batch}$ above is a batch verifier for Modified CL Scheme A.

Proof

First, we show that success of $\mathsf{{PrivVerify}}$ on $(pk, m_i, \sigma _i)$ for all $i \in [1, n]$ implies that $\mathsf {Batch}$ also outputs 1 on $pk, (m_1, \sigma _1), {\ldots }, (m_n, \sigma _n)$. When all $\mathsf {PrivVerify}$ output 1, for each $i = 1, {\ldots }, n$ $\mathbf {v}_{x}^{-1} = \mathbf {v}_{xy}^{m_{i}}\mathbf {v}_{s}^{r_{i}}$, which is expanded as $e(X, a_{i})^{-1} = e(X, b_{i})^{m_{i}} \cdot e(g, \tilde{c_{i}})^{r_i}$. Then $e(X, a_{i}^{\delta _i})^{-1} = e(X, b_{i}^{\delta _i})^{m_{i}} \cdot e(g, \tilde{c_{i}}^{\delta _i})^{r_i}$ for all i and consequently $\prod \limits _{i=1}^n e(X, a_{i}^{\delta _i})^{-1} = \prod \limits _{i=1}^n e(X, b_{i}^{\delta _i})^{m_{i}} e(g, \tilde{c_{i}}^{\delta _i})^{r_i}$. Because $\prod \limits _{i=1}^n e(X, a_{i}^{\delta _i}) = e(X, \prod \limits _{i=1}^n a_i^{\delta _i})$, we obtain equivalence with $\hat{\mathbf {v}}_{x}^{-1}= \prod \limits _{i=1}^n \hat{\mathbf {v}}_{xy_i}^{m_i} \hat{\mathbf {v}}_{s_i}^{r_i}$.

To show the other direction, assume that $\mathsf {Batch}$ accepts. We know that $\tilde{c_{i}}, a_i, b_i \in G$, thus $\tilde{c_{i}}=g^{\gamma _{i}}, a_i=g^{s_{i}}, b_i=g^{t_{i}}$ for some $\gamma _{i}, a_i, b_i \in \mathbb {Z}_{q}$. Then

$$\begin{aligned} \hat{\mathbf {v}}_{x}^{-1}= & {} \prod _{i=1}^n \hat{\mathbf {v}}_{xy_i}^{m_i} \hat{\mathbf {v}}_{s_i}^{r_i} = \prod _{i=1}^n e(X, b_{i}^{\delta _i})^{m_{i}} \cdot e(g, \tilde{c_{i}}^{\delta _i})^{r_i} = \prod _{i=1}^n e(X, g^{t_i \delta _i})^{m_{i}} \cdot e(g, g^{\gamma _i \delta _i})^{r_i} \\= & {} \prod _{i=1}^n e(g, g)^{x t_i \delta _i m_i} \cdot e(g, g)^{\gamma _i \delta _i r_i} = \prod _{i=1}^n e(g, g)^{\delta _i(x t_i m_i+\gamma _i r_i)} \end{aligned}$$

Because $\hat{\mathbf {v}}_{x}^{-1} = e(X, \prod \limits _{i=1}^n a_{i}^{\delta _i})^{-1} = e(g^x, \prod \limits _{i=1}^n g^{s_i \delta _{i}})^{-1} = \prod \limits _{i=1}^n e(g, g)^{-xs_i \delta _{i}}$, $e(g,g)^{-x\sum _i s_i \delta _i}=e(g, g)^{\sum _i \delta _{i} (x t_i m_i+\gamma _i r_i)}$ and consequently $\sum _i x s_i \delta _{i} + \sum _i \delta _{i}(x t_i m_i+\gamma _i r_i) \equiv 0 \pmod q$. Let us set $\beta _{i}=x(s_i + t_i m_i) + \gamma _i r_i$, then

$$\begin{aligned} \sum \nolimits _{i=1}^n \delta _{i} \beta _{i} \equiv 0 \pmod q \end{aligned}$$

(1)

Now suppose that $\mathsf {Batch}$ returned 1, while for at least one i $\mathsf {PrivVerify}$ returns 0 on the corresponding input $(pk, m_i, \sigma _i)$. Without loss of generality, let $i=1$. This means that $e(X, a_1)^{-1} \not = e(X, b_1)^{m_1} \cdot e(g, \tilde{c}_1)^{r_1}$ and consequently $\beta _{1} = x(s_1 + t_1 m_1) + \gamma _1 r_1 \ne 0$. Because G and $\mathbf {G}$ are cyclic groups of prime order q, $\beta _{1}$ has an inverse $\alpha _{1}$ such that $\beta _{1} \alpha _{1} \equiv 1 \pmod q$.

We re-write Eq. (1) as $\delta _{1} \beta _{1} +\sum _{i=2}^n \delta _{i} \beta _{i} \equiv 0 \pmod q$, and substitute $\beta _1$ with $\alpha _1^{-1}$ to obtain $\delta _{1} \alpha _{1}^{-1} + \sum _{i=2}^n \delta _{i} \beta _{i} \equiv 0 \pmod q$. This gives us

$$\begin{aligned} \delta _{1} \equiv - \alpha _{1} \sum \nolimits _{i=2}^{n} \delta _{i} \beta _{i} \pmod q \end{aligned}$$

(2)

Let E be an event such that $\mathsf{{PrivVerify}}(pk, m_1, \sigma _1)=0$, but $\mathsf{{Batch}}(pk, (m_1, \sigma _1), \ldots$, $(m_n, \sigma _n))=1$. Also, let vector $\triangle =(\delta _2, \ldots , \delta _n)$ and $|\triangle |$ denote the number of possible values of $\triangle$. By Eq. (2), when $\triangle$ is fixed, there exists only one value of $\delta _{1}$ that results in event E happening. In other words, for a fixed $\triangle$ the probability of E given a randomly chosen $\delta _{1}$ is $\mathrm {Pr} [\mathrm {E}\, |\, \triangle ']=2^{-l_{b}}$. Thus, we can bound the probability of E for randomly chosen $\delta _{1}$ by summing over all possible choices of $\triangle$, i.e., $\mathrm {Pr} [\mathrm {E}] \le \sum _{i=1}^{|\triangle |} (\mathrm {Pr} [\mathrm {E}\,|\,\triangle ] \cdot \mathrm {Pr} [\triangle ])$. We obtain $\mathrm {Pr} [\mathrm {E}] \le \sum _{i=1}^{2^{l_{b}(n-1)}} (2^{-l_{b}} \cdot 2^{-l_{b}(n-1)}) = \sum _{i=1}^{2^{l_{b}(n-1)}} (2^{-l_{b} n}) = 2^{-l_{b}}$. $\Box$

As before, we spell out the ZKPK computation in the $\mathsf {Batch}$ protocol: The prover chooses random $v_i, v'_i, v''_i \in \mathbb {Z}_{q}$ and computes $\mathrm {T}_i = g^{v_i} h^{v''_i}$ for $i = [1, n]$ as well as , and sends $\mathrm {T}_{i}$s and $\mathrm {T}$ to the verifier. After receiving challenge $e \in \mathbb {Z}_{q}$ from the verifier, the prover responds with $u_i = v_i + e m_i \bmod q$, $u'_i = v'_i + e r'_i \bmod q$, and $u''_i = v''_i + e r_i \bmod q$ for all i. The verifier accepts if $g^{u_i} h^{u''_i} = \mathrm {T}_i x_{m_i}^e$ for $i=1, \ldots , n$ and .

The cost of using this construction for n certified inputs in SMC is n mod exp for signature randomization, 2n mod exp for creating commitments (n of which are short), $12n+1$ mod exp (3n of which are short) and $2n+3$ pairings for the ZKPK. This gives us $15n+1$ mod exp (4n of which are short) and $2n+3$ pairings and significantly reduces the number of pairing operations, which we consider to be the costliest operation, compared to private verification of individual messages.

The way inputs are entered in the SMC constructions considered in Sect. 6, a single commitment to all inputs of a participant is permissible. Thus, instead of using separate commitments for each $m_i$, we could form a single commitment to n messages $com(m_1, \ldots , m_n, r) = g_1^{m_1} \cdots g_n^{m_n} h^r$ and modify the ZKPK to use it instead of the individual commitments. This reduces the cost of forming commitments to n short and one regular mod exp, and the cost of ZKPK is reduced by $3n-3$ mod exp (i.e., only one $v''$ needs to be formed and we compute only one $T_i$ instead of n of them). This gives us the total of $11n+5$ mod exp (4n of which are short) and $2n+3$ pairings.

5 Construction Based on ElGamal Signature

In this section, we show how to modify (provably secure) ElGamal signature scheme to achieve private verification and consequently provide a batch verifier for the resulting construction.

5.1 Modified ElGamal Scheme

Our starting point was provably secure ElGamal [29] described in Sect. 3.2. To enable private verification, the idea is to use signatures on commitments to messages instead of on messages themselves. We also modify the setup to work in a group of prime order q, i.e., a subgroup of $\mathbb {Z}^*_p$, instead of entire $\mathbb {Z}^*_p$. This simplifies the design and opens up additional possibilities, without compromising security guarantees. In particular, the small exponent test used for batch verification is not applicable to groups of non-prime order [1]. Our signature scheme $\varPi = (\mathsf{{KeyGen}}, \mathsf{Sign}, \mathsf {PrivVerify})$ is given as:

• $\mathsf {KeyGen}$: On input a security parameter $1^\kappa$, choose a group G of large prime order q and its generator g. Then choose random $x, u \in \mathbb {Z}_q$ and compute $y=g^x$ and $h = g^u$. Set $sk=x$, $pk=(q, G, g, y, h)$.

• $\mathsf {Sign}$: On input message m, secret key $sk = x$ and public key $pk = (q, G, g, y, h)$, choose random $k, r \in \mathbb {Z}_q$ and compute $t = g^k$, $x_m = com(m, r) = g^{m} h^r$, and $s \equiv (H(x_m || t) - xt) k^{-1} \pmod q$. The algorithm outputs $\sigma =(t, s)$ and $x_\sigma = r$. The recipient computes $com(m, x_\sigma )$ and verifies the signature on $com(m, x_\sigma )$.

• $\mathsf {PrivVerify}$: The prover has private m and $x_\sigma$, the corresponding signature $\sigma = (t, s)$ on $x_m$, where $x_m = g^m h^{x_\sigma }$, and both parties hold pk. The prover gives the verifier $\sigma$ and $x_m$ and they engage in the following ZKPK: ${PK}\{(\mu ,\gamma ): x_m = g^{\mu } h^\gamma \}$. If this proof passes and the equality $g^{H(x_m || t)} = y^t t^s$ holds, the verifier outputs 1; otherwise, the verifier outputs 0.

Note that in this scheme the signer chooses g, h and thus will be able to open a commitment com(m, r) to a message different from m (but the users will not be able to do so). If this poses a security risk, h will need to be produced by an independent party or parties so that the signer does not know the discrete logarithm of h to the base g.

This signature scheme remains unforgeable, and we prove it using the standard definition (Definition 6) with $\mathsf {ForgePrivSig}$ experiment that accommodates privacy as described in Sect. 3.1. The intuition is that the prover now has a signature on a commitment, but has to demonstrate the knowledge of the commitment opening, i.e., the message itself, and the use of groups of prime order only simplifies the analysis in [29]. We state unforgeability and privacy properties next, with their proofs available in the full version.

Theorem 4

Modified ElGamal signature scheme is existentially unforgeable against an adaptive chosen-message attack in a random oracle model.

Theorem 5

Modified ElGamal scheme is a signature scheme with privacy.

The ZKPK in this $\mathsf {PrivVerify}$ proceeds similar to prior ZK proofs, where the prover chooses $v_1, v_2 \in \mathbb {Z}_{q}$, computes $T=g^{v_1} h^{v_2}$, and sends T to the verifier. After receiving the challenge e from the verifier, the prover responds by sending $r_1 = v_1 + em \bmod q$, $r_2 = v_2 + er \bmod q$, and the verifier accepts if $g^{r_1} h^{r_2}=x_{m}^{e} T$. The cost of using this construction in SMC is 5 mod exp for the ZKPK and 3 for signature verification, giving us 8 mod exp. (If the user does not store commitment $x_m$, its re-computation is another 1 regular and 1 short mod exp.)

Table 1. Performance of private verification for a single signature and a batch of size n. It is assumed that commitments are stored pre-computed.

5.2 Batch Verification of Modified ElGamal Signatures

Our batch verifier for the modified ElGamal signature is given next. It uses the same security parameter $l_b$ as before.

• $\mathsf {Batch}$: The prover holds commitments $x_{m_i}= com(m_i, {x_\sigma }_i) = g^{m_i} h^{{x_\sigma }_i}$ on messages $m_i \in \mathbb {Z}_q$ using randomness $x_{\sigma _i} \in \mathbb {Z}_q$ and signatures $\sigma _i = (t_i, s_i)$ on $x_{m_i}$ for $i = 1, \ldots , n$. Both parties hold $pk = (q, G, g, y, h)$.

  • 1. The prover sends signatures $\sigma _i$ and commitments $x_{m_i}$ to the verifier for $i = 1, \ldots , n$.

  • 2. The prover and verifier engage in the following ZKPK: ${PK}\{(\mu _1, \ldots , \mu _n$, $\gamma _1, \ldots , \gamma _n): x_{m_1} = g^{\mu _1} h^{\gamma _1} \wedge \cdots \wedge x_{m_n} = g^{\mu _n} h^{\gamma _n}\}$. If the proof fails, the verifier outputs 0 and aborts.

  • 3. The verifier chooses $\delta _1, \ldots , \delta _n \in \{0, 1\}^{l_b}$ at random, computes $u_1 = \sum _{i=1}^n H(x_{m_i} || t_i) \delta _i$ and $u_2 = \sum _{i=1}^n t_i \delta _i$, and checks whether $g^{u_1} = y^{u_2} \prod _{i=1}^{n} {t_i^{s_i \delta _i}}$. If the check succeeds, the verifier outputs 1, and 0 otherwise.

Theorem 6

$\mathsf {Batch}$ above is a batch verifier for the modified ElGamal scheme.

The ZKPK in $\mathsf {Batch}$ above consists of n invocations of the ZKPK in modified ElGamal’s $\mathsf {PrivVerify}$. Thus, the cost of batch verification of n messages is 5n mod exp for the ZKPK and $n+2$ mod exp for signature verification, or $6n+2$ mod exp total. (If the commitments are to be re-computed, we add n regular and n short mode exp.)

Now recall that the way messages are input into SMC allows us to use a single commitment to all n messages. For our modified ElGamal this optimization results in great savings because this means that we can use only a single signature. Thus, the signer now issues a signature on $x_m = com(m_1, \ldots , m_n, r)$ and $x_\sigma$ still contains the randomness r. This significantly simplifies the $\mathsf {Batch}$ algorithm above because only 1 signature and 1 commitment are communicated in step 1, step 2 only involves the proof of knowledge of the discrete logarithm representation of $x_m$, and step 3 consists of verifying a single signature without the use of $\delta _i$s. This has significant performance improvement implications, with the cost of step 2 reduced to $2n+3$ mod exp and the overall cost of $\mathsf {Batch}$ reduced to $2n+6$ mod exp (if the commitment is to be re-computed, we add 1 regular and n short mod exp).

Table 1 summarizes performance of our constructions.

6 Using Certified Inputs in Secure Computation

Having described our private verification protocols, we now address the question of integrating them with SMC techniques based on secret sharing in the presence of malicious adversaries. For that purpose, we have chosen two prominent constructions of Damgård and Nielsen [13] and SPDZ [14] and discuss them consequently. These were chosen based on their attractive performance and distinct security guarantees that they provide: when the computation is performed by m parties, the former solution tolerates fewer than m/3 corruptions, while the latter can handle any number of corrupt parties. Our solution uses signatures with privacy to guarantee that inputs entered into secure computation are identical to those generated or observed by an authority, but in general certification could take different forms.

As far as security properties go, the privacy guarantees of SMC in the presence of malicious adversaries must hold as in the standard formulation of the problem (see, e.g., [20] for a formal definition). We additionally require that it is not feasible for a participant to enter (certified) inputs into the computation without possessing a signature on them. Because of space considerations, we defer formal definitions and analysis of these properties to the full version of the paper.

In what follows, we denote the computational parties as $P_1, {\ldots }, P_m$ and assume that they are connected by pairwise secure channels. These constructions use (m, t)-threshold linear secret sharing, and we denote a secret shared version of x by [x].

6.1 Damgård-Nielsen Scalable and Unconditionally Secure Multiparty Computation

The construction of Damgård-Nielsen [13] is unconditionally secure (assuming secure channels) in the presence of at most $t < m/3$ malicious participants. It was the first to achieve unconditional security with communication complexity where the part that depends on the circuit size is only linear in m. The computation proceeds in two stages: offline pre-computation that generates random multiplication triples and other random values and the online phase which is executed once the inputs become available.

As far as input into the computation (during the online phase) goes, let x denote party $P_\ell$’s input into the secure computation for some $\ell$ (the same will apply to all other parties holding inputs; participants with input who are not computational parties can be accommodated as well). To secret-share x among the parties, $P_\ell$ computes $\delta = x + r$, where r is a random value chosen during pre-computation in such a way that the parties hold shares of r [r] and the value of r is known in the clear to $P_\ell$ (i.e., [r] was opened to $P_\ell$). Both the shares [r] and the value r that $P_\ell$ possesses are guaranteed to be correct in the presence of malicious participants. Then once $P_\ell$ computes $\delta$, $P_\ell$ broadcasts it to all parties who compute $[x] = \delta - [r]$ and use [x] in consecutive computation.

To enable the use of certified inputs, we need to modify the above input sharing procedure to guarantee that x that $P_\ell$ uses in computing $\delta$ was indeed certified. Then to ensure that correct x is input into the computation, the parties could compute a commitment to r and verify (in zero-knowledge) that $\delta$ corresponds to the sum of r and x. This could be implemented by having the parties broadcast commitments to their shares of r and interpolating them to compute a commitment to r. In that case, reconstructing a reliable commitment to r presents the main challenge because any participant can be malicious. If the input owner $P_\ell$ is honest, it can verify correctness of commitments from other parties and discard incorrect transmissions. Dealing with malicious $P_\ell$, however, is more difficult because $P_\ell$ can influence through its share the value of r in the commitment which the parties reconstruct. Then because validity of $P_\ell$’s share cannot be verified, $P_\ell$ can adjust its share to modify the reconstructed r by the amount it wants to change x from its certified version, getting around the certification process.

To solve the issue, we chose to proceed with directly entering input x into the computation as opposed to supplying the delta. To accomplish this, we utilize one of the building blocks from [13] for dealing consistent shares of a value (which is input x in our case). It has a mechanism for resolving conflicts and upon successful termination provides a set of parties holding consistent shares. We use this set to form a commitments to shares of x and interpolate them to reconstruct a commitment to x.

Because each $P_\ell$ often enters multiple inputs into the computation, we will associate inputs $x_1, {\ldots }, x_n$ with party $P_\ell$. In what follows, we describe the version with a single commitment to all $x_i$s which allows for improved performance. The case of a single certified input x will follow from that construction. Also, when $P_\ell$’s inputs are certified by multiple authorities, this procedure is performed for each public key separately. Because the solution uses (Pedersen) commitments, we assume that a group setup (G, q) where the discrete logarithm problem is hard with generators $g_1, {\ldots }, g_n, h$ is available to the parties. All signature schemes that we considered in this work already use commitments, and therefore we will assume that this setup comes from the public key of the corresponding signature scheme.

In what follows, we use notation $[y]_j$ to denote the jth share of y held by party $P_j$. As in [13], we assume that operations on secret shares take place in a field $\mathbb {F}$ and secret shares correspond to the evaluation of a polynomial of degree t on different points. For concreteness, we set $\mathbb {F} = \mathbb {F}_p$ for a prime p ($q \gg p$). The computation is then as follows:

Input: The parties collectively hold the public key pk of the certification authority. $P_\ell$ has private input $x_1, {\ldots }, x_n$, $c_x = com(x_1, {\ldots }, x_n, \hat{r})$, and signatures with privacy $\sigma _1, {\ldots }, \sigma _n$ on $x_1, {\ldots }, x_n$, respectively.¹

Output: $[x_1], {\ldots }, [x_n]$ are available to the parties and their certification has been verified.

• 1. The parties execute the protocol for $P_\ell$ to deal consistent shares of $x_1, \ldots , x_n$ and another value $\alpha$ that $P_\ell$ randomly chooses from $\mathbb {F}_p$ (as specified in Fig. 7 from [13]). If $P_\ell$ is honest, there are at least $2t+1$ parties who hold consistent shares of each $x_i$ and we denote this set by S. (Otherwise, the protocol fails and the parties restart it as specified in [13].)

• 2. $P_\ell$ broadcasts commitments $com([x_1]_j, {\ldots }, [x_n]_j, [\alpha ]_j) = g_1^{[x_1]_j} \cdots g_n^{[x_n]_j} h^{[\alpha ]_{j}}$ and each $P_j \in S$ verifies that the jth commitment is consistent with its shares.

• 3. The parties compute interpolation coefficients $\beta _j$ (in $\mathbb {F}_p$) for each $P_j \in S$ and then compute $c'_x = com(x'_1, {\ldots }, x'_n, \alpha ') = \prod _{P_j \in S} com([x_1]_j, {\ldots }, [x_n]_j, \alpha _j)^{\beta _j}$. Note that $x_i = \sum _{P_j \in S} \beta _j [x_i]_j$ (in $\mathbb {F}_p$) for each i.

• 4. $P_\ell$ computes $\alpha ' = \sum _{P_j \in S} \beta _j [\alpha ]_j$ (in $\mathbb {Z}_q$) and $x'_i = \sum _{P_j \in S} \beta _j [r_i]_j$, $s_i = \lfloor x'_i/p \rfloor$ (over integers) for $i = 1, {\ldots }, n$. It creates commitment $c_s = com(s_1, {\ldots }, s_n, \tilde{r}) = g_1^{s_1} \cdots g_n^{s_n} h^{\tilde{r}}$ and broadcasts it to the other parties.

• 5. $P_\ell$ broadcasts $c_x, \sigma _1, {\ldots }, \sigma _n$ and the parties execute $\mathsf{{Batch}}(pk, x_1, \sigma _1, {\ldots }, x_n, \sigma _n)$ with $P_\ell$ playing the role of the prover.

• 6. The parties additionally execute $\mathrm {PK}\big \{(x_1, {\ldots }, x_n, x'_1, {\ldots }, x'_n, s_1, {\ldots }, s_n, \alpha ', \hat{r}, \tilde{r}): c_x = g_1^{x_1} \cdots g_n^{x_n} h^{\hat{r}} \wedge c'_x = g_1^{x'_1} \cdots g_n^{x'_n} h^{\alpha '} \wedge c_s = g_1^{s_1} \cdots g_n^{s_n} h^{\tilde{r}} \wedge \, \bigwedge _{i=1}^n \big ( x'_i = x_i + s_i p \big ) \big \}$ where $P_\ell$ plays the role of the prover.

Because different moduli are used for exponents in G and arithmetic in $\mathbb {F}_p$, to guarantee correctness, we need to compensate for reduction modulo p for field operations. To accomplish that, we interpolate each $x_i$ over integers and thus have that $x'_i = x_i + s_i p$ for some unique integer $s_i$, which is the relationship that $P_\ell$ proves in step 6. This computation requires that $|q| > 2t|p|$, which is the case in practice for typical values of q, t, and p (i.e., threshold t is usually low and set to 1–2, |p| is set to accommodate integers of 64 or fewer bits, and |q| is at least in hundreds to guarantee security).

Note that step 6 already includes a PK of the discrete logarithm representation of $com(x_1, {\ldots }, x_n, \hat{r})$ and thus the same ZKPK in $\mathsf {Batch}$ is no longer executed in step 6.

6.2 SPDZ

The second solution that we study is built on SPDZ [14]. This is an SMC protocol that achieves security in the presence of any number of malicious parties $t < m$ (and thus offers stronger security guarantees than the previous solution) and has a fast online phase. This construction enters private inputs into the computation similar to the way [13] did. That is, to secret share input $x_i$, the input owner $P_\ell$ uses a random value $r_i$ computed during the preprocessing phase known only to $P_\ell$ and the parties jointly holding $[r_i]$. $P_\ell$ then computes and broadcasts $\delta _i = x_i - r_i$ (in $\mathbb {F}_p$) and the players compute $[x_i] = [r_i] + \delta _i$. The difference is that now additive secret sharing (i.e., $(m-1)$-out-of-m) is used instead of threshold secret sharing and each secret-shared value y also uses a secret-shared MAC $\gamma (y)$ in the form of $\alpha (y+\tau )$, where $\alpha$ is a global secret key and $\tau$ is public, to authenticate its value. In other words, a secret shared value [y] is represented by each party $P_i$ holding $\langle \tau , [y]_i, [\gamma (y)]_i \rangle$, where $[y]_1 + {\ldots } + [y]_n = y$ and $[\gamma (y)]_1 + {\ldots } + [\gamma (y)]_m = \alpha (y + \tau )$. The value of $\alpha$ is opened at the end of secure computation and is used to verify consistency of certain values used during computation, before the parties can learn the result (see [14] for detail).

Unlike the solution considered in Sect. 6.1, we could proceed with the approach where the parties compute the input as $x_i = r_i + \delta _i$, reconstruct a commitment to $r_i$, and use it to verify the relationship between $x_i$ and $r_i$. Verification of correct $r_i$ used in the commitment is deferred to the end of the computation where the value of $\alpha$ is opened. Then if the parties determine that the commitment to $r_i$ was correctly formed, they proceed with reconstructing the output. The inputs of the procedure remain unchanged and the computation proceeds as follows:

• 1. Each $P_j$ (including $P_\ell$) chooses random $\alpha '_j \in \mathbb {Z}_q$, sends its shares $[r_1]_j, {\ldots }$, $[r_n]_j$ and $\alpha '_j$ to $P_\ell$, and also broadcasts $com([r_1]_j, {\ldots }, [r_n]_j, \alpha '_j) = g_1^{[r_1]_j} \cdots g_n^{[r_n]_j} h^{\alpha '_{j}}$.

• 2. $P_\ell$ verifies that $\sum _{j=1}^m [r_i]_j = r_i$ (in $\mathbb {F}_p$) for each $i = 1, {\ldots }, n$ and that the received commitments are consistent with $[r_i]_j$s and $\alpha '_j$s.

• 3. The parties compute $c_r' = com(r'_1, {\ldots }, r'_n, \alpha ') = \prod _{j=1}^m com([r_1]_j, {\ldots }, [r_n]_j, \alpha '_j)$.

• 4. Each $P_j$ (including $P_\ell$) chooses random $\alpha ''_j \in \mathbb {Z}_q$ and broadcasts $com([\gamma (r_1)]_j, {\ldots }$, $[\gamma (r_n)]_j, \alpha ''_j) = g_1^{[\gamma (r_1)]_j} \cdots g_n^{[\gamma (r_n)]_j} h^{\alpha ''_{j}}$.

• 5. The parties compute $c_\gamma ' = com(\gamma '_1, {\ldots }, \gamma '_n, \alpha '') = \prod _{j=1}^m com([\gamma (r_1)]_j, {\ldots }, [\gamma (r_n)]_j, \alpha ''_j)$.

• 6. $P_\ell$ computes $\delta _i = x_i - r_i$ (in $\mathbb {F}_p$) and broadcasts $\delta _i$ for $i = 1, {\ldots }, n$.

• 7. $P_\ell$ computes $\alpha ' = \sum _{j=1}^m \alpha _j$ (in $\mathbb {Z}_q$) and $r'_i = \sum _{j=1}^m [r_i]_j$, $s_i = \lfloor (r'_i + \delta _i - x_i)/p \rfloor$ (over integers) for $i = 1, {\ldots }, n$. It creates commitment $c_s = com(s_1, {\ldots }, s_n, \tilde{r}) = g_1^{s_1} \cdots g_n^{s_n} h^{\tilde{r}}$ and broadcasts it to the other parties.

• 8. $P_\ell$ broadcasts $c_x = com(x_1, {\ldots }, x_n, \hat{r}), \sigma _1, {\ldots }, \sigma _n$ and the parties execute $\mathsf{{Batch}}(pk$, $x_1, \sigma _1, {\ldots }, x_n, \sigma _n)$ with $P_\ell$ playing the role of the prover.

• 9. The parties additionally execute $\mathrm {PK}\big \{(x_1, {\ldots }, x_n, r'_1, {\ldots }, r'_n, s_1, {\ldots }, s_n, \alpha ', \hat{r}, \tilde{r}): c_x = g_1^{x_1} \cdots g_n^{x_n} h^{\hat{r}} \wedge c_r' = g_1^{r'_1} \cdots g_n^{r'_n} h^{\alpha '} \wedge c_s = g_1^{s_1} \cdots g_n^{s_n} h^{\tilde{r}} \wedge \, \bigwedge _{i=1}^n \big ( r'_i = x_i - \delta _i + s_i p \big ) \big \}$ where $P_\ell$ plays the role of the prover.

As before, the ZKPK of $x_1, \ldots , x_n, \hat{r}$ is redundant and no longer executed in $\mathsf {Batch}$.

Then once the computation is complete and the value of $\alpha$ is opened (but prior to reconstructing the output of the computation from the shares), the parties perform additional computation and checks:

• 1. Each $P_j$ sends $\alpha ''_j$ and $[\gamma (r_i)]_j$ for $i = 1, \ldots , n$ to $P_\ell$.

• 2. $P_\ell$ checks that each $com([\gamma (r_1)]_j, {\ldots }, [\gamma (r_n)]_j, \alpha ''_j)$ is consistent with $[\gamma (r_i)]_j$s and $\alpha ''_j$ and aborts otherwise.

• 3. $P_\ell$ computes $\alpha ' = \sum _{j=1}^m \alpha _j$ (in $\mathbb {Z}_q$), $\gamma '_i = \sum _{j=1}^m [\gamma (r_i)]_j$, $u_i = \lfloor r'_i/p \rfloor$, $w_i = \lfloor \gamma '_i/p \rfloor$ (over integers) for $i = 1, {\ldots }, n$. $P_\ell$ creates commitments $c_u = com(u_1, \ldots$, $u_n, z) = g_1^{u_1} \cdots g_n^{u_n} h^z$, $c_w = com(w_1, \ldots , w_n, z') = g_1^{w_1} \cdots g_n^{w_n} h^{z'}$ and broadcasts them to other parties.

• 4. $P_\ell$ proves the following statement $\mathrm {PK}\big \{r'_1, \ldots , r'_n, \gamma '_1, \ldots , \gamma '_n, u_1, \ldots , u_n, w_1, \ldots$, $w_n, \alpha ', \alpha '', z, z': c_r' = g_1^{r'_1} \cdots g_n^{r'_n} h^{\alpha '} \wedge c_\gamma ' = g_1^{\gamma '_1} \cdots g_n^{\gamma '_n} h^{\alpha ''} \wedge c_u = g_1^{u_1} \cdots g_n^{u_n} h^z \wedge c_w = g_1^{w_1} \cdots g_n^{w_n} h^{z'} \wedge \, \bigwedge _{i=1}^n \big ( \gamma '_i = \alpha (r'_i - u_ip + \tau _i) + w_ip\big ) \big \}$, where $\tau _i$ was the public value in $r_i$’s MAC.

7 Performance Evaluation

Before we conclude, we provide a brief performance evaluation of the developed techniques. We have implemented the modified ElGamal with private verification that uses a single commitment to n messages (and thus a single signature). Additionally, we have implemented SPDZ-based input of certified inputs into SMC using the same signature. All programs were written in C using OpenSSL’s elliptic curve implementation with a 224-bit modulus (equivalent to a 2048-bit modulus in the standard setting) and SHA-256 as the hash function. The experiments were run on an 8-core 2.1 GHz machine with a Xeon E5-2620 processor and 64 GB of memory running CentOS using a single thread and the times were averaged over at least 20 executions. The results are given in Table 2.

Table 2. Performance of batch signatures and using certified inputs in SMC.

The table shows the time of $\mathsf {Sign}$, cumulative computation of $\mathsf {Batch}$ (the prover and verifier work), and communication amount in $\mathsf {Batch}$ (which is $n+4$ group elements, with a 28-byte group element in our experiments). Recall that the ZKPK of $\mathsf {Batch}$ becomes a part of the ZKPK used during entering certified inputs into SMC and is not executed separately then. For the SPDZ-based solution of Sect. 6.2, we used a setup with $m=3$ computational parties and $|p|=32$. We report computation time of input party $P_\ell$ and all other parties (who do identical work) as well as the amount of communication sent by $P_\ell$ and other parties, respectively. A broadcast message is counted multiple times using direct transmissions to each party and an EC point is counted as 1 group element.

In our construction, $P_\ell$ does a slightly larger amount of work per input $x_i$ than other parties, which is reflected in Table 2 for large n. When, however, n is small, the constant terms (e.g., batch verification carried out by everyone except $P_\ell$) noticeably contribute to the overall time making $P_\ell$’s time slightly faster. But in all cases, each party’s work is not substantially higher than the work of private signature verification itself.

An improvement to SPDZ [12] reports for p near $2^{32}$ in the malicious model (without certified input) 7.5–134 thousand multiplications per second (for 1 to 50 operations in parallel) during the online phase. This is about 7.5–130 $\upmu$s per multiplication (including communication), while our work associated with input certification is about 400 $\upmu$s with on the order of hundred bytes of communication per message, which in not drastically higher than that of an online multiplication (all of which can be improved with parallel execution using multiple cores). For many computations, the number of multiplications is significantly greater than the number of inputs, which means that the cost of computation will exceed that of entering and verifying inputs in our solution. Furthermore, offline work per multiplication triple in SPDZ is significantly higher at 28.7 ms per triple. All of this suggests that the performance of our solution is quite good and is not expected to be the bottleneck in secure computation.

8 Conclusions

In this work, we showed how to modify CL and ElGamal signature schemes to achieve efficient private batch verification for use in SMC with certified inputs and integrate them with two secret-sharing-based protocols. Our results demonstrate that the techniques are efficient even for a large number of inputs and the ideas behind private verification are rather general to have a potential application to other signature schemes.

A Additional Background

Let $\varPi =(\mathsf {KeyGen}, \mathsf {Sign}, \mathsf {Verify})$ be a signature scheme and consider the following experiment:

Experiment $\mathsf {ForgeSig}_{\mathcal {A}, \varPi }(\kappa )$:

• 1. The challenger creates a key pair $(pk, sk) \leftarrow \mathsf {Gen}(1^\kappa )$ and gives pk to $\mathcal {A}$.

• 2. $\mathcal {A}$ has oracle access to $\mathsf {Sign_{sk}}(\cdot )$. For each message m that $\mathcal {A}$ queries the oracle, m is stored in list $\mathcal {Q}$ and $\mathcal {A}$ learns $\sigma = \mathsf{{Sign}}_{sk}(m)$. $\mathcal {A}$ eventually outputs a pair $(m^*, \sigma ^*)$.

• 3. The experiment outputs 1 if both $\mathsf {Verify}_{pk}(m^*, \sigma ^*) = 1$ and $m^* \notin \mathcal {Q}$. Otherwise, it outputs 0.

Definition 6

(Security of a signature scheme [23]). A signature scheme $\varPi =(\mathsf {Gen}$, $\mathsf {Sign}, \mathsf {Verify})$ is existentially unforgeable under an adaptive chosen-message attack if for all PPT adversaries $\mathcal {A}$ there is a negligible function $\mathsf {negl}$ such that $Pr [\mathsf {ForgeSig}_{\mathcal {A}, \varPi } (\kappa )=1] \le \mathsf {negl}(\kappa ).$