1 Introduction

1.1 Distributed Generation of an RSA Composite

Generating an RSA composite N (a product of two primes p and q), and secret keying material (values related to \(\phi (N)\)) in a distributed manner is an important question in secure computation. Many cryptographic protocols require such a composite for which none of the parties know N’s prime factorization. A concrete example where such a protocol is very useful is threshold cryptography, where a number of parties exceeding some threshold is required to cooperate in order to carry out a cryptographic task such as computing a decryption or a signature; see [11, 20, 59, 62] for just few examples. Specifically, the public key of Paillier [55], which is one of the most widely used public key encryption schemes in secure computation, is an RSA composite. Paillier is an important building block due to the fact that it is an additively homomorphic cryptosystem, and is therefore extremely useful. Consequently, it is very important to design an efficient threshold variant for this construction. Another important application is using RSA composites as part of the common reference string (CRS) for secure computation in the UC setting [9], as demonstrated for any function in [45] or for concrete functions such as the Fiat–Shamir authentication protocol [31, 35], set intersection [44], and oblivious pseudorandom functions [44].

Typically, generating an RSA composite is comprised from two phases; generating a candidate and testing its validity (namely, that it is indeed a product of two primes). This task has proven particularly challenging mainly due to lack of an efficient secure implementation of the later phase. Therefore, most prior works assume that the composite is generated by a trusted dealer. In a breakthrough result, Boneh and Franklin [5] showed a mathematical method for choosing a composite and verifying that it is of the proper form. Based on this method they designed a protocol in the multiparty setting with security against semi-honest adversaries, assuming honest majority (where a semi-honest adversary follows the protocol’s instructions honestly but tries to learn secret information about the honest parties’ inputs from the communication). Two follow-up papers [32, 54] strengthened this result and obtained security against malicious adversaries (where a malicious adversary follows an arbitrary polynomial-time strategy). We note that the later result relies on a random oracle. Additional solutions for testing primality in the multiparty setting appear in [1, 25].

Security without assuming honest majority, and in particular in the two-party setting, posed additional barriers even for the semi-honest model. Cocks [16] initiated the study of the shared generation of the RSA composite in the two-party semi-honest model. Nevertheless, his proposed protocol was later found to be insecure [3, 17]. The problem was solved by Gilboa [36] who presented a protocol in the semi-honest model, adapting the [5] technique.

In the malicious setting, Blackburn et al. [3] started examining the setting of an arbitrary adversary, yet they did not provide a proof of security for their protocol. Concurrently, Poupard and Stern [56] proposed a solution that runs in time proportional to the size of the domain from which the primes are sampled, which is exponential in the security parameter. Poupard and Stern made attempts to reduce the running time by introducing various modifications. However, those are not proven, and as they leak some information, presenting a proof of security (if at all possible) will not be a trivial thing. A detailed explanation about this construction and a discussion about the proof complexity appear in “Appendix A.” This overview implies that all prior results do not offer an efficient and provable solution for the two-party malicious case.

1.2 Threshold Cryptosystems of Paillier

A threshold cryptosystem is typically involved with two related yet separable components; (1) a distributed generation of the public key and sharing of the corresponding secret key of the cryptosystem and (2) a decryption/signature computation from a shared representation of the secret key. Threshold schemes are important in settings where no individual party should know the secret key. Prior to this work, solutions for distributed discrete log-based key generation systems [38], and threshold encryption/decryption for RSA [39, 62], DSS [37] and Paillier [6, 23, 34] in the multiparty setting, have been presented. For some cryptosystems (e.g., ElGamal [30]) the techniques from the multiparty setting can be adapted to the two-party case in a relatively straightforward manner. However, a solution for a two-party threshold Paillier encryption scheme that is resistant against malicious attacks has proven more complex and elusive.

Elaborating on these difficulties, we recall that the RSA and Paillier encryption schemes share the same public/secret keys format of a composite N and its factorization. Moreover, the ciphertexts have a similar algebraic structure. Thus, it may seem that decryption according to Paillier should follow from the (distributed) algorithm of RSA, as further discussed in [12]. Nevertheless, when decrypting as in the RSA case (i.e., raising the ciphertext to the power of the inverse of N modulo the unknown order), the decrypter must extract the randomness of the ciphertext in order to complete the decryption. This property is problematic in the context of simulation-based security, because it forces to reveal the randomness of the ciphertext and does not allow cheating in the decryption protocol. We further recall that by definition, Paillier’s scheme requires an extra computation in order to complete the decryption (on top of raising the ciphertext to the power of the secret value) since the outcome from this computation is the plaintext multiplied with this secret value. In the distributive setting this implies that the parties must keep two types of shares. Due to these reasons it has been particularly challenging to design a complete threshold system for Paillier in the two-party setting without the help of a trusted party.

1.3 Our Contribution

In this work, we present the first fully simulatable and complete RSA key generation and Paillier [55] threshold scheme in the two-party malicious setting. Namely, we define the appropriate functionalities and prove that our protocols securely realize them. Our formalization further takes into account a subtle issue in the public key generation, which was initially noticed by Boneh and Franklin [5]. Informally, they showed that their protocol leaks a certain amount of information about the product, and proved that it does not pose any practical threat for the security. Nevertheless, it does pose a problem when simulating since the adversary can influence the distribution of the generated public key. We therefore also work with a slightly modified version of the natural definition for a threshold encryption functionality; see the formal definition in Sect. 4. In more details, our scheme is comprised of the following protocols:

  1. 1.

    A distributed generation of an RSA composite. We present the first fully simulatable protocol for securely computing a Blum integer composite as a product of two primes without leaking information about its factorization (in the sense of [5]). Our protocol follows the outlines of [5] and improves the construction suggested by [36] in terms of security level and efficiency; namely, we use an additional trial division protocol on the individual prime candidates which enables us to exclude many of them earlier in the computation. We note that [36] did not implement the trial division as part of his protocol; thus, our solution is the first for the two-party setting that employs this test. Here we take a novel approach of utilizing two different additively homomorphic encryption schemes that enable to ensure active security at a very low cost. In “Appendix C” we further show how to extend this protocol and the biprimality test to the multiparty setting with dishonest majority, presenting the first actively secure k parties for an RSA generation protocol that tolerates up to \(k-1\) corruptions.

  2. 2.

    A distributed biprimality test. We adopt the biprimality test proposed by [5] into the malicious two-party setting and provide a proof of security for this protocol. This test essentially verifies whether the generated composite is of the correct form (i.e., it is a product of exactly two primes of an appropriate length). We further note that the biprimality test by Damgård and Mikkelsen [25] has a better error estimate, yet it cannot be used directly in the two-party setting with malicious adversaries. In “Appendix B” we adapt their test into the two-party setting when the parties are semi-honest.

  3. 3.

    Distributed generations of the secret key shares. Motivated by the discussion above, we present a protocol for generating shares for a decryption key of the form \(d\equiv 1\bmod N\equiv 0\bmod \phi (N)\). Specifically, we take the same approach of Damgård and Jurik [23], except that in their threshold construction the shares are generated by a trusted party. We present the first concrete protocol for this task with semi-honest security and then show how to adapt it into the malicious setting.

  4. 4.

    A distributed decryption. Finally, we present a distributed protocol for decrypting according to the decryption protocol of Damgård and Jurik [23], but for two parties. Namely, each party raises the ciphertext to the power of its share and proves consistency. We remark that even though our decryption protocol is similar to that of [23], there are a few crucial differences: (i) First, since we only consider two parties, an additive secret sharing suffices. (ii) Secret sharing is done over the integers rather than attempting to perform a reduction modulo the secret value \(\phi (N)\cdot N\). (iii) Finally, the Damgård–Jurik decryption protocol requires N to be a product of safe primes to ensure hardness of discrete logarithms. To avoid this requirement, we ensure equality of discrete logarithms in different-order groups.

1.4 Efficiency

Distributed RSA composite.

We provide a detailed efficiency analysis for all our subprotocols in Sect. 6. All our subprotocols are round efficient due to parallelization of the generation and testing the potential RSA composite. This includes the biprimality test and trial division. Moreover, all our zero-knowledge proofs run in constant rounds and require constant number of exponentiations (except one that achieves constant complexity on the average). We further note that the probability of finding a random prime is independent of the method in which it is generated, but rather only depends on the density of the primes in a given range. We show that due to our optimizations we are able to implement the trial division which greatly reduces the number of candidates that are expected to be tested, e.g., for a 512 bit prime we would need to test about 31,000 candidates without the trial division, while the number of candidates is reduced to 484 with the trial division. We give a detailed description of our optimizations in Sect. 6.

The only alternative to distributively generate an RSA composite with malicious security is using generic protocols that evaluate a binary or an arithmetic circuit. In this case the circuit must sample the prime candidates first and test their primality, and finally compute their product. The size of a circuit that tests primality is polynomial in the length of the prime candidate. Furthermore, the best known binary circuit that computes the multiplication of two numbers of length n requires \(O(n\log n)\) gates. This implies a circuit of polynomial size in n, multiplied with \(O(n^2)\) which is the required number of trials for successfully sampling two primes with overwhelming probability. Moreover, generic secure protocols are typically proven in the presence of malicious attacks using the cut-and-choose technique, which requires sending multiple instances of the garbled circuit [50]. Specifically, the parties repeat the computation a number of times such that half of these computations are examined in order to ensure correctness. The best cut-and-choose analysis is due to [48] which requires that the parties exchange 40 circuits (with some additional overhead). This technique inflates the communication and computation overheads.

Protocols that employ arithmetic circuits [4, 28] work in the preprocessing model where the parties first prepare a number of triples of multiplications that is proportional to the circuit’s size, and then use them for the circuit evaluation in the online phase. Therefore, the number of triples is proportional to the size of the circuit that tests primality times the number of trials. On the other hand, our protocol presents a relatively simpler approach with a direct design of a key generation protocol without building a binary/arithmetic circuit first, which is fairly complicated for this task. This follows for the multiparty setting as well since our protocol is the first protocol that achieves security in the malicious setting.

Threshold Paillier. This phase is comprised out of two protocols. First, the generation of the multiplicative key shares, which is executed only once, and requires constant overhead and constant round complexity. The second protocol for threshold decryption is dominated by the invocation of a zero-knowledge proof which requires constant number of exponentiations for long enough challenge (see more discussion about this proof in Sect. 3.2, Item 5). For batch decryption the technique of Cramer and Damgård [10] can be used to achieve amortized constant overhead. Our protocols are the first secure protocols in the two-party malicious setting.

Additional practical considerations are demonstrated in Sect. 6.3.

1.5 Experimental Results

We further present an implementation of Protocol 4 with security against semi-honest adversaries. Our primary goal is to examine the overall time it takes to generate an RSA composite of length 2048 bits in case the parties do not deviate, and identify bottlenecks. The bulk of our implementation work is related to reducing the computational overhead of the trial division phase which is the most costly phase. Namely, based on our study of the resources required by the parties for generating a legal RSA composite, we concluded that the DKeyGen protocol is too expensive for real-world applications (at least 3 h running time). We therefore focused on algorithmic improvements of the performance of this phase, which lead to two optimizations: protocol BatchedDec and protocol LocalTrialDiv; details below. In addition, to improve the overhead relative to the ElGamal PKE, we implement this scheme on elliptic curves using the MIRACL library [51] and use the elliptic curve P-192 [52] based on Ecrypt II yearly report [29]; see [53, 61] for more practical information. A brief background on elliptic curves in found in Sect. 7.1.1.

BatchedDec protocol The underlying idea of the first optimization is due to the performance analysis of the decryption operation carried out within our composite generation protocol (executed within the trial division protocol). Specifically, we observed that the decryption operation is the most expensive cryptographic operation. To improve this overhead we modified the decryption protocol in order to let the parties collect the results of several trial division rounds and decrypt all the results at once when needed. This implementation improved the overhead by much and required 40 min on the average in order to generate a 2048 bits RSA composite.

LocalTrialDiv protocol The second optimization is focused on reducing the usage of expensive cryptographic operations by taking alternative cheaper approaches. This protocol variant permits to securely compute a 2048 bits RSA composite in 15 min on the average.

Security for our two optimizations follows easily. Our detailed results are found in Sect. 7.

2 Preliminaries

We denote the security parameter by n. A function \(\mu (\!\cdot \!)\) is negligible in n (or just negligible) if for every polynomial \(p(\!\cdot \!)\) there exists a value m such that for all \(n>m\) it holds that \(\mu (n)<\frac{1}{p(n)}\). Let \(X=\left\{ X(n,a)\right\} _{n\in {\mathbb N},a\in {\{0,1\}}^*}\) and \(Y=\left\{ Y(n,a)\right\} _{n\in {\mathbb N},a\in {\{0,1\}}^*}\) be distribution ensembles. Then, we say that X and Y are computationally indistinguishable, denoted \(X{\mathop {\equiv }\limits ^\mathrm{c}}Y\), if for every non-uniform probabilistic polynomial-time distinguisher D there exists a negligible function \(\mu (\!\cdot \!)\) such that for every \(a\in {\{0,1\}}^*\),

$$\begin{aligned} |\Pr [D(X(n,a))=1]-\Pr [D(Y(n,a))=1]|<\mu (n) \end{aligned}$$

We adopt the convention whereby a machine is said to run in polynomial time if its number of steps is polynomial in its security parameter. We use the shorthand ppt to denote probabilistic polynomial time.

2.1 Hardness Assumptions

Our constructions rely on the following hardness assumptions.

Definition 2.1

(DDH) We say that the decisional Diffie–Hellman (DDH) problem is hard relative to\({\mathbb G}=\{{\mathbb G}_n\}\) if for any PPT algorithm \(\mathcal{A}\) there exists a negligible function \(\mathsf{negl}\) such that

$$\begin{aligned} \Big |\Pr \left[ \mathcal{A}({\mathbb G},q,g,g^x,g^y,g^z)=1\right] -\Pr \left[ \mathcal{A}({\mathbb G},q,g,g^x,g^y,g^{xy})=1\right] \Big | \le \mathsf{negl}(n), \end{aligned}$$

where q is the order of \({\mathbb G}\) and the probabilities are taken over the choices of g and \(x,y,z\in {\mathbb Z}_q\).

Definition 2.2

(DCR) We say that the decisional composite residuosity (DCR) problem is hard if for any PPT algorithm \(\mathcal{A}\) there exists a negligible function \(\mathsf{negl}\) such that

$$\begin{aligned}&\Big |\Pr \left[ \mathcal{A}(N,z)=1|z=y^N\bmod N^2\right] \\&\quad -\Pr \left[ \mathcal{A}(N,z)=1|z=(N+1)^r\cdot y^N\bmod N^2\right] \Big | \le \mathsf{negl}(n), \end{aligned}$$

where N is a random n-bit RSA composite, r is chosen at random in \({\mathbb Z}_N\), and the probabilities are taken over the choices of Ny and r.

2.2 Public Key Encryption Schemes

We begin by specifying the definitions of public key encryption and IND-CPA security. We conclude with a definition of homomorphic encryption, specifying two encryption schemes that meet this definition.

Definition 2.3

(PKE) We say that \(\Pi =(\mathsf{Gen}, \mathsf{Enc}, \mathsf{Dec})\) is a public key encryption scheme if \(\mathsf{Gen}, \mathsf{Enc}, \mathsf{Dec}\) are polynomial-time algorithms specified as follows:

  • \(\mathsf{Gen}\), given a security parameter n (in unary), outputs keys (pksk), where pk is a public key and sk is a secret key. We denote this by \((pk,sk)\leftarrow \mathsf{Gen}(1^n)\).

  • \(\mathsf{Enc}\), given the public key pk and a plaintext message m, outputs a ciphertext c encrypting m. We denote this by \(c\leftarrow \mathsf{Enc}_{pk}(m)\); and when emphasizing the randomness r used for encryption, we denote this by \(c\leftarrow \mathsf{Enc}_{pk}(m;r)\).

  • \(\mathsf{Dec}\), given the public key pk, secret key sk and a ciphertext c, outputs a plaintext message m s.t. there exists randomness r for which \(c = \mathsf{Enc}_{pk}(m;r)\) (or \(\bot \) if no such message exists). We denote this by \(m \leftarrow \mathsf{Dec}_{pk,sk}(c)\).

For a public key encryption scheme \(\Pi =(\mathsf{Gen}, \mathsf{Enc}, \mathsf{Dec})\) and a non-uniform adversary \(\mathcal{A}=(\mathcal{A}_1,\mathcal{A}_2)\), we consider the following IND-CPA game:

$$\begin{aligned}&(pk,sk)\leftarrow \mathsf{Gen}(1^n).\\&(m_0,m_1,history)\leftarrow \mathcal{A}_1(pk)\text{, } \text{ s.t. } |m_0|=|m_1|.\\&c\leftarrow \mathsf{Enc}_{pk}(m_b)\hbox { , where}\ b\in _R{\{0,1\}}.\\&b'\leftarrow \mathcal{A}_2(c,history).\\&\mathcal{A} \text{ wins } \text{ if } b'=b\text{. } \end{aligned}$$

Denote by \(\mathsf{Adv}_{\Pi ,\mathcal{A}}(n)\) the probability that \(\mathcal{A}\) wins the IND-CPA game.

Definition 2.4

(IND-CPA) A public key encryption scheme \(\Pi =(\mathsf{Gen}, \mathsf{Enc}, \mathsf{Dec})\) is semantically secure, if for every non-uniform adversary \(\mathcal{A}=(\mathcal{A}_1,\mathcal{A}_2)\) there exists a negligible function \(\mathsf{negl}\) such that \(\mathsf{Adv}_{\Pi ,\mathcal{A}}(n) \le \frac{1}{2} + \mathsf{negl}(n).\)

An important tool that we exploit in our construction is homomorphic encryption over an additive group as defined below.

Definition 2.5

(Homomorphic PKE) A public key encryption scheme \((\mathsf{Gen}, \mathsf{Enc}, \mathsf{Dec})\) is homomorphic if for all n and all (pksk) output by \(\mathsf{Gen}(1^n)\), it is possible to define groups \({\mathbb M}, {\mathbb C}\) such that:

  • The plaintext space is \({\mathbb M}\), and all ciphertexts output by \(\mathsf{Enc}_{pk}\) are elements of \({\mathbb C}\).

  • For any \(m_1, m_2 \in {\mathbb M}\) and \(c_1, c_2 \in {\mathbb C}\) with \(m_1 = \mathsf{Dec}_{sk}(c_1)\) and \(m_2 = \mathsf{Dec}_{sk}(c_2)\), it holds that

    $$\begin{aligned} \{pk,c_1,c_1 \!\cdot \! c_2\} \equiv \{pk,\mathsf{Enc}_{pk}(m_1),\mathsf{Enc}_{pk}(m_1 + m_2)\} \end{aligned}$$

    where the group operations are carried out in \({\mathbb C}\) and \({\mathbb M}\), respectively, and the encryptions of \(m_1\) and \(m_1 + m_2\) use independent randomness.

Any additive homomorphic scheme supports the multiplication of a ciphertext by a scalar by computing multiple additions.

2.2.1 The Paillier Encryption Scheme

The Paillier encryption scheme [55] is an example of a public key encryption scheme that meets Definition 2.5. We focus our attention on the following, widely used, variant of Paillier due to Damgård and Jurik [23]. Specifically, the generation algorithm chooses two equal length primes p and q and computes \(N = pq\). It further picks an element \(g\in \mathbb {Z}^*_{N^{s+1}}\) such that \(g=(1+N)^j r^N\bmod N^{s+1}\) for a known j relatively prime to N and \(r^N\). Let \(\lambda \) be the least common multiple of \(p-1\) and \(q-1\), then the algorithm chooses d such that \(d\bmod N\in \mathbb {Z}_N^*\) and \(d=0\bmod \lambda \). The public key is Ng, and the secret key is d. Next, encryption of a plaintext \(m\in \mathbb {Z}_{N^s}\) is computed by \(g^m r^{N^s}\bmod N^{s+1}\). Finally, decryption of a ciphertext c follows by first computing \(c^d\bmod N^{s+1}\) which yields \((1+N)^{jmd \bmod N^s}\), and then computing the discrete logarithm of the result relative to \((1+N)\) which is an easy task.

In this work we consider a concrete case where \(s=1\). Thereby, encryption of a plaintext m with randomness \(r\in _R{\mathbb Z}_N^*\) (\({\mathbb Z}_N\) in practice) is computed by,

$$\begin{aligned} E_N(m, r) = (N+1)^m\cdot r^N\bmod N^2\text {.} \end{aligned}$$

The security of Paillier is implied by the decisional composite residuosity (DCR) assumption.

2.2.2 Additively Homomorphic ElGamal Variant

In our protocols we further use an additively homomorphic variation of ElGamal encryption [30]. Namely, let \({\mathbb G}\) be a group generated by g of prime order Q, in which the decisional Diffie–Hellman (DDH) problem is hard. A public key is then a pair \(pk=(g,h)\) and the corresponding secret key is \(s = \log _g(h)\), i.e., \(g^s = h\). Encryption of a message \(m\in \mathbb {Z}{}_{Q}\) is defined as \(\mathsf{Enc}_{pk}(m;r) = \left( g^{r}, h^{r}\cdot g^{m}\right) \) where r is picked uniformly at random in \(\mathbb {Z}{}_{Q}\). Decryption of a ciphertext \(\left( \alpha , \beta \right) \) is then performed as \(\mathsf{Dec}_{sk}(\alpha ,\beta ) = \hbox { }\ \beta \cdot \alpha ^{-s}\). Note that decryption yields \(g^m\) rather than m. As the discrete log problem is hard, we cannot in general hope to determine m. Fortunately, we only need to distinguish between zero and nonzero values, hence the lack of “full” decryption is not an issue. We abuse notation and write \(c\cdot c'\) to denote the componentwise multiplication of two ciphertexts c and \(c'\), computed by \((\alpha \cdot \alpha ',\beta \cdot \beta ')\), where \(c=\left( \alpha , \beta \right) \) and \(c'=(\alpha ',\beta ')\).

We require that the parties run a threshold version for ElGamal for generating a public key and additive shares for the secret key, as well as a distributive decryption protocol. The key generation construction can be easily obtained based on the Diffie–Hellman protocol [22]. Specifically, each party \(P_i\) picks a random share \(s_i\in _R\mathbb {Z}{}_{Q}\) and forwards \(g^{s_i}\) to the other party. The parties then engage in a pair of zero-knowledge proofs of knowledge \(\pi _{\scriptscriptstyle \mathrm {DL}}\) (specified in Sect. 3.1), for proving the discrete logarithm of each share relative to g. The public key is defined by \(h=g^{s_0+s_1}\). Furthermore, a distributive decryption follows easily where given a ciphertext \(\left( g^{r}, h^{r}\cdot g^{m}\right) \) each party raises \(g^r\) to the power of its share, and then proves consistency using \(\pi _{\scriptscriptstyle \mathrm {DH}}\) (where the proof is specified in Sect. 3.1). The parties then use \(g^{r(s_0+s_1)}\) to decrypt c. We denote the distributed key generation functionality by \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGGEN}}:(s_0,s_1)\mapsto (g^{s_0+s_1},g^{s_0+s_1})\) and the protocol for this functionality by \(\pi _{\scriptscriptstyle \mathrm {EGGEN}}\), whereas the distributed decryption functionality is denoted by \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGDEC}}:((s_0,c),(s_1,c))\mapsto (\mathsf{Dec}_{s_0+s_1}(c),\mathsf{Dec}_{s_0+s_1}(c))\) and the protocol for this functionality by \(\pi _{\scriptscriptstyle \mathrm {EGDEC}}\).

2.3 Integer Commitment Schemes

In order to ensure correct behavior of the parties (and do so efficiently), our key generation protocol utilizes integer commitments which rely on the fact that the committer does not know the order of the group \({\mathbb G}\), denoted by \(|{\mathbb G}|\), from which it picks the committed elements. Therefore, it cannot decommit into two different values, such as m and \(m + |{\mathbb G}|\). This property is crucial for ensuring that the parties’ shares are indeed smaller than some threshold. An example of such a commitment is the Paillier-based scheme of Damgård and Nielsen [26, 27], which is comprised of the following two algorithms:

  1. 1.

    Setup. The receiver, R, generates a Paillier key N, i.e., an RSA modulus. It then picks r at random in \(\mathbb {Z}_{N^2}^*\), computes \(g = r^{N}\), and sends Ng to the committing party, C, along with zero-knowledge proofs that N is an RSA modulus and that g is a Paillier encryption of zero. See [42] for a discussion regarding a zero-knowledge proof for the validity of an RSA composite. Moreover, proving that an element g is an encryption of zero is carried out easily by proving that g has an Nth root [23].

  2. 2.

    Commit/Open. To commit to \(m\in \mathbb {Z}_{N}\), C picks \(r_m\) at random in \(\mathbb {Z}_{N}\) and computes \(\mathtt {Com}\left( m;r_m\right) = g^m\cdot r_m^{N}\). To open, C simply reveals \(r_m\) and m to R.

Hiding/Binding. The scheme is perfectly hiding, as a commitment is simply a random encryption of zero. Further, opening to two different values implies an Nth root of g (which breaks the underlying assumption of Paillier, i.e., DCR).

2.4 \(\Sigma \)-Protocols

Definition 2.6

(\(\Sigma \)-protocol) A protocol \(\pi \) is a \(\Sigma \)-protocol for relation R if it is a three-round public-coin protocol and the following requirements hold:

  • Completeness: If P and V follow the protocol on input x and private input w to P where \((x,w)\in R\), then V always accepts.

  • Special soundness: There exists a polynomial-time algorithm A that given any x and any pair of accepting transcripts \((a,e,z), (a,e',z')\) on input x, where \(e\ne e'\), outputs w such that \((x,w)\in R\).

  • Special honest-verifier zero knowledge: There exists a ppt algorithm M such that

    $$\begin{aligned} \left\{ \phantom {2^{2^2}}\langle P(x,w),V(x,e)\rangle \right\} _{x\in L_R} \equiv \left\{ \phantom {2^{2^2}}M(x,e) \right\} _{x\in L_R} \end{aligned}$$

    where M(xe) denotes the output of M upon input x and e, and \(\langle P(x,w),V(x,e)\rangle \) denotes the output transcript of an execution between P and V, where P has input (xw), V has input x, and V’s random tape (determining its query) equals e.

Any \(\Sigma \) protocol can be easily transferred into a zero-knowledge proof of knowledge using standard techniques; see [43] for more details.

2.5 Security in the Presence of Malicious Adversaries

In this section we briefly present the standard definition for secure two-party computation and refer to [40, Chapter 7] for more details and motivating discussion.

Two-party computation. A two-party protocol problem is cast by specifying a random process that maps pairs of inputs to pairs of outputs (one for each party). We refer to such a process as a functionality and denote it \(f:{\{0,1\}}^*\times {\{0,1\}}^*\rightarrow {\{0,1\}}^*\times {\{0,1\}}^*\), where \(f = (f_1,f_2)\). That is, for every pair of inputs (xy), the output vector is a random variable \((f_1(x,y),f_2(x,y)\) ranging over pairs of strings where \(P_0\) receives \(f_1(x,y)\) and \(P_1\) receives \(f_2(x,y)\). We sometimes denote such a functionality by \(f(x,y) \mapsto (f_1(x,y),f_2(x,y))\).

Adversarial behavior. Loosely speaking, the aim of a secure two-party protocol is to protect honest parties against dishonest behavior by other parties. In this section, we outline the definition for malicious adversaries who control some subset of the parties and may instruct them to arbitrarily deviate from the specified protocol. We also consider static malicious corruptions.

Security of protocols (informal). The security of a protocol is analyzed by comparing what an adversary can do in a real protocol execution to what it can do in an ideal scenario that is secure by definition. This is formalized by considering an ideal computation involving an incorruptible trusted third party to whom the parties send their inputs. The trusted party computes the functionality on the inputs and returns to each party its respective output. Loosely speaking, a protocol is secure if any adversary interacting in the real protocol (where no trusted third party exists) can do no more harm than if it was involved in the above-described ideal computation. One technical detail that arises when considering the setting of no honest majority is that it is impossible to achieve fairness or guaranteed output delivery [15]. That is, it is possible for the adversary to prevent the honest party from receiving outputs. Furthermore, it may even be possible for the adversary to receive output while the honest party does not.

Execution in the ideal model. In an ideal execution, the parties send their inputs to the trusted party who computes the output. An honest party just sends the input that it received, whereas a corrupted party can replace its input with any other value of the same length. Since we do not consider fairness, the trusted party first sends the output of the corrupted parties to the adversary, and the adversary then decides whether the honest parties receive their (correct) outputs or an abort symbol \(\bot \). Let f be a two-party functionality where \(f = (f_1,f_2)\), let \(\mathcal{A}\) be a non-uniform probabilistic polynomial-time machine, and let \(I\subseteq [2]\) be the set of corrupted parties (either \(P_0\) is corrupted or \(P_1\) is corrupted or neither). Then, the ideal execution off on inputs (xy), auxiliary input z to \(\mathcal{A}\) and security parameter n, denoted \({\textsc {ideal}}_{f,\mathcal{A}(z),I}(x,y,n)\), is defined as the output pair of the honest party and the adversary \(\mathcal{A}\) from the above ideal execution.

Execution in the real model. In the real model there is no trusted third party and the parties interact directly. The adversary \(\mathcal{A}\) sends all messages in place of the corrupted party, and may follow an arbitrary polynomial-time strategy. In contrast, the honest parties follow the instructions of the specified protocol \(\pi \).

Let f be as above and let \(\pi \) be a two-party protocol for computing f. Furthermore, let \(\mathcal{A}\) be a non-uniform probabilistic polynomial-time machine and let I be the set of corrupted parties. Then, the real execution of\(\pi \) on inputs (xy), auxiliary input z to \(\mathcal{A}\) and security parameter n, denoted \({\textsc {real}}_{\pi ,\mathcal{A}(z),I}(x,y,n)\), is defined as the output vector of the honest parties and the adversary \(\mathcal{A}\) from the real execution of \(\pi \).

Security as emulation of a real execution in the ideal model. Having defined the ideal and real models, we can now define security of protocols. Loosely speaking, the definition asserts that a secure party protocol (in the real model) emulates the ideal model (in which a trusted party exists). This is formulated by saying that adversaries in the ideal model are able to simulate executions of the real-model protocol.

Definition 2.7

Let f and \(\pi \) be as above. Protocol \(\pi \) is said to securely computefwith abort in the presence of malicious adversaries if for every non-uniform probabilistic polynomial-time adversary \(\mathcal{A}\) for the real model, there exists a non-uniform probabilistic polynomial-time adversary \(\mathcal{S}\) for the ideal model, such that for every \(I\subseteq [2]\),

$$\begin{aligned} \left\{ {\textsc {ideal}}_{f,\mathcal{S}(z),I}(x,y,n)\right\} _{x,y,z\in {\{0,1\}}^*,n\in {\mathbb N}} {\mathop {\equiv }\limits ^\mathrm{c}}\left\{ {\textsc {real}}_{\pi ,\mathcal{A}(z),I}(x,y,n)\right\} _ {x,y,z\in {\{0,1\}}^*,n\in {\mathbb N}} \end{aligned}$$

where \(|x|=|y|\).

The \(\mathcal{F}\)-hybrid model. In order to construct some of our protocols, we will use secure two-party protocols as subprotocols. The standard way of doing this is to work in a “hybrid model” where parties both interact with each other (as in the real model) and use trusted help (as in the ideal model). Specifically, when constructing a protocol \(\pi \) that uses a subprotocol for securely computing some functionality \(\mathcal{F}\), we consider the case that the parties run \(\pi \) and use “ideal calls” to a trusted party for computing \(\mathcal{F}\). Upon receiving the inputs from the parties, the trusted party computes \(\mathcal{F}\) and sends all parties their output. Then, after receiving these outputs back from the trusted party the protocol \(\pi \) continues. Let \(\mathcal{F}\) be a functionality and let \(\pi \) be a two-party protocol that uses ideal calls to a trusted party computing \(\mathcal{F}\). Furthermore, let \(\mathcal{A}\) be a non-uniform probabilistic polynomial-time machine. Then, the \(\mathcal{F}\)-hybrid execution of\(\pi \) on inputs (xy), auxiliary input z to \(\mathcal{A}\) and security parameter n, denoted \({\textsc {hybrid}}_{\pi ^{\mathcal{F}},\mathcal{A}(z),I}(n,x, y)\), is defined as the output vector of the honest parties and the adversary \(\mathcal{A}\) from the hybrid execution of \(\pi \) with a trusted party computing \(\mathcal{F}\). By the composition theorem of [8] any protocol that securely implements \(\mathcal{F}\) can replace the ideal calls to \(\mathcal{F}\).

Reactive functionalities. Until now we have considered the secure computation of simple functionalities that compute a single pair of outputs from a single pair of inputs. However, not all computations are of this type. Rather, many computations have multiple rounds of inputs and outputs. Furthermore, the input of a party in a given round may depend on its output from previous rounds, and the outputs of that round may depend on the inputs provided by the parties in some or all of the previous rounds. In the context of secure computation, multiphase computations are typically called reactive functionalities. Such functionalities can be modeled as a series of functions \((f^1, f^2,\ldots )\) where each function receives some state information and two new inputs. That is, the input to function \(f^j\) consists of the inputs \((x_j , y_j)\) of the parties in this phase, along with a state input \(\sigma _{j-1}\) output by \(f^{j-1}\). Then, the output of \(f^j\) is defined to be a pair of outputs \(f^j_1 (x_j , y_j , \sigma _{j-1})\) for \(P_1\) and \(f^j_2 (x_j , y_j , \sigma _{j-1})\) for \(P_2\), and a state string \(\sigma _j\) to be input into \(f^{j+1}\). We stress that the parties receive only their private outputs and, in particular, do not receive any of the state information; in the ideal model this is stored by the trusted party.

3 Zero-Knowledge Proofs

In order to cope with malicious adversaries, our protocols employ zero-knowledge (ZK) proofs, where some of these proofs are proofs of knowledge. We denote the functionality of a proof of knowledge for a relation \(\mathcal{R}\) by \(\mathcal{F}_{\scriptscriptstyle \mathrm {ZK}}^\mathcal{R}:((x,\omega ),x)\mapsto (-,1)\) only if \(\mathcal{R}(x,\omega )=1\). Below, we provide a description of the proofs we use; while some of these proofs are known, others are new to this work and are interesting by themselves. We note that except from a single proof, all proofs require a strict constant overhead. Fortunately, since our proofs are employed for multiple instances, the analysis of [10] ensures that the average overhead is constant; details follow.

3.1 Discrete Logarithms

  1. 1.

    The following \(\Sigma \)-protocol, denoted by \(\pi _{\scriptscriptstyle \mathrm {DL}}\), demonstrates knowledge of a discrete logarithm. The proof follows due to Schnorr [60].

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {DL}}=\left\{ \left( \left( {\mathbb G},g,h\right) , w\right) \mid h = g^w\right\} . \end{aligned}$$
  2. 2.

    The \(\Sigma \)-protocol \(\pi _{\scriptscriptstyle \mathrm {DH}}\) demonstrates that a quadruple \((g_0,g_1, h_0, h_1)\) is a Diffie–Hellman tuple, i.e., that \(\log _{g_0}(h_0) = \log _{g_1}(h_1)\) for \(g_i, h_i\in {\mathbb G}\). This proof is due to Chaum and Pedersen [18].

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {DH}}=\left\{ \left( \left( {\mathbb G},g_0, g_1,h_0,h_1\right) w\right) \mid h_i = g_i^w~\text{ for }~i\in {\{0,1\}}\right\} . \end{aligned}$$

3.2 Plaintext Relations

  1. 1.

    Protocol \(\pi _{\scriptscriptstyle \mathrm {ENC}}\) demonstrates knowledge of an encrypted plaintext.

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {ENC}}=\left\{ \left( (c,pk), (\alpha ,r)\right) \mid c=\mathsf{Enc}_{pk}(\alpha ;r)\right\} . \end{aligned}$$

    The protocols are due to Schnorr [60] (for ElGamal encryption) and Cramer et al. [11] (for Paillier encryption).

  2. 2.

    Protocol \(\pi _{\scriptscriptstyle \mathrm {ZERO}}\) demonstrates that a ciphertext c is an encryption of zero and is captured by the following language.

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {ZERO}}=\left\{ \left( (c,pk), r\right) \mid c=\mathsf{Enc}_{pk}(0;r)\right\} . \end{aligned}$$

    For ElGamal this is merely \(\pi _{\scriptscriptstyle \mathrm {DH}}\), demonstrating that the key and ciphertext are a Diffie–Hellman tuple. For Paillier encryption this is a proof of Nth power shown by [23] similarly to proving that an element is a quadratic residue.

  3. 3.

    The zero-knowledge proof of knowledge \(\pi _{\scriptscriptstyle \mathrm {MULT}}\) proves that the plaintext of \(c_2\) is the product of the two plaintexts encrypted by \(c_0,c_1\). More formally,

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {MULT}}= & {} \left\{ \left( \left( c_0,c_1,c_2,pk\right) , \left( \alpha ,r_\alpha ,r_0\right) \right) \mid c_1=\mathsf{Enc}_{pk}(\alpha ;r_\alpha )\wedge c_2\right. \\= & {} \left. c_0^\alpha \cdot \mathsf{Enc}_{pk}(0;r_0) \right\} \text {;} \end{aligned}$$

    This proof is due to Damgård and Jurik [23] (for both Paillier and ElGamal). A similar proof of knowledge is possible for commitment schemes, when the contents of all three commitments are known to the prover, [26, 27]; this is required in \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) below.

  4. 4.

    Protocol \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) demonstrates boundedness of an encrypted value, i.e., that the plaintext is smaller than some public threshold B. Formally,

    $$\begin{aligned} \L _{\scriptscriptstyle \mathrm {BOUND}}=\left\{ \left( (c,pk,B),(\alpha ,r)\right) \mid c=\mathsf{Enc}_{pk}(\alpha ;r)\wedge \alpha < B\in {\mathbb N}\right\} . \end{aligned}$$

    The “classic” solution is to provide encryptions to the individual bits and prove in zero knowledge that the plaintexts are bits using the compound proof of Cramer et al. [13], and that the bits admit the required bound. The actual ciphertext is then constructed from these.

    An alternative solution is to take a detour around integer commitments; this allows a solution requiring only O(1) exponentiations [7, 24, 49]. Sketching the solution, the core idea is to commit to \(\alpha \) using a homomorphic integer commitment scheme; the typical suggestion is schemes such as [21, 33]. The prover then demonstrates that \(\alpha \) and \(B-1 - \alpha \) are nonnegative (using the fact that any nonnegative integer can be phrased as the sum of four squares), implying that \(0\le \alpha < B\). Finally, the prover demonstrates that the committed value equals the encrypted value. For simplicity, we use the commitment scheme of Sect. 2.3. Note that for smallB, the classic approach may be preferable in practice.

  5. 5.

    The proof \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) is of correct exponentiation in the group \({\mathbb G}\) with encrypted exponent (where the encryption scheme does not utilize the description of \({\mathbb G}\)). Formally,

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {EQ}}=\left\{ \left( (c,pk,{\mathbb G},h,h'),(\alpha ,r)\right) \mid \alpha \in {\mathbb N}\wedge c=\mathsf{Enc}_{pk}(\alpha ;r)\wedge h, h' \in {\mathbb G}\wedge h' = h^\alpha \right\} . \end{aligned}$$

    The protocol is a simple cut-and-choose approach; its idea is originates from [14]. Namely, the prover selects at random \(s, r_s\) and sends \(c_s = \mathsf{Enc}_{pk}(s,r_s)\) and \(h^s\) to the verifier, who returns a random challenge bit b. The prover then replies with \(\alpha \cdot b + s\) and \(r\cdot b+r_s\), i.e., it sends either s or \(s+\alpha \). Privacy of \(\alpha \) is ensured as long as the bit length of s is longer than the bit length of \(\alpha \) by at least \(\kappa \) bits, where \(\kappa \) is a statistical parameter (fixing \(\kappa =100\) is typically sufficient to mask \(\alpha \)). Note that it is only possible to answer both challenges if the statement is well formed and thus the proof is also a proof of knowledge. Finally, we note that the protocol must be repeated in order to obtain negligible soundness. For a challenge of length 1 inducing soundness 1 / 2, the number of repetitions must be \(\omega (\log n)\) for n the security parameter. Reducing the number of repetitions is possible by increasing the length of the challenge. However, in this case we must ensure that \(\alpha \cdot b + s\) is still private, namely, s is longer than the bit length of \(\alpha \) plus the bit length of b, by at least \(\kappa \). We point out that we can obtain constant amortized cost for multiple instances when the proof is instantiated with the technique of [10]. Indeed, we employ this proof multiple times when checking primality and potentially, for multiple decryptions. In this work, we instantiate \(\mathsf{Enc}\) with the ElGamal PKE.

3.3 Public Key and Ciphertext Relations

  1. 1.

    We sketch the folklore protocol \(\pi _{\scriptscriptstyle \mathrm {RSA}}\) for proving that N and \(\phi (N)\) are co-prime for some integer N, i.e., the protocols demonstrate membership of the language,

    $$\begin{aligned} \L _{\scriptscriptstyle \mathrm {RSA}}=\left\{ \left( N,\phi (N)\right) \mid N\in {\mathbb N}\wedge {{\text {GCD}}}\left( N,\phi (N)\right) = 1 \right\} \text {.} \end{aligned}$$

    The protocol is described as follows.

Protocol 1

Zero-knowledge proof for \(\L _{\scriptscriptstyle \mathrm {RSA}}\):

  • Inputs for the parties: A security parameter \(1^n\) and a composite RSA candidate. The prover also holds \(\phi (N)\).

  • The protocol:

    1. (a)

      The verifier picks \(x = y^{N}\bmod N^2\) and proves the knowledge of an Nth root of x (essentially, the verifier executes the Paillier version of \(\pi _{\scriptscriptstyle \mathrm {ZERO}}\)).

    2. (b)

      The prover returns an Nth root \(y'\) of x.

    3. (c)

      The verifier accepts only if \(y=y'\).

Proposition 3.1

Assuming hardness of the DCR problem, \(\pi _{\scriptscriptstyle \mathrm {RSA}}\) is a zero-knowledge protocol.

Proof sketch

Notably, if \({\text {GCD}}\left( N,\phi (N)\right) = 1\), then y is unique, hence \(y=y'\). Otherwise, there are multiple candidates, and the probability that \(y = y'\) is \(\le 1/2\). This protocol is repeated (in parallel) until a sufficiently low soundness probability is reached. In addition, proving zero knowledge is straightforward by constructing a simulator that simply extracts y first and then sends it to the verifier within the last message. Finally, we note that this protocol is used only once in our construction; therefore, its overhead does not dominate the analysis.\(\square \)

  1. 2.

    We also require a zero-knowledge proof, \(\pi _{\scriptscriptstyle \mathrm {MOD}}\), for proving consistency between two ElGamal ciphertexts in the sense that one plaintext is the other one reduced modulo a fixed public prime. This proof is required for proving correctness within the trial division stage included in the key generation protocol (cf. Sect. 4). Formally,

    $$\begin{aligned} \mathcal{R}_{\scriptscriptstyle \mathrm {MOD}}= & {} \left\{ \left( (c,c',p,pk), (\alpha ,r,r')\right) \mid c\right. \\= & {} \left. \mathsf{Enc}_{pk}(\alpha ;r)\wedge c'=\mathsf{Enc}_{pk}(\alpha \bmod p;r')\right\} . \end{aligned}$$

Protocol 2

Zero-knowledge proof for \(\mathcal{R}_{\scriptscriptstyle \mathrm {MOD}}\):

  • Inputs for the parties: A security parameter \(1^n\) and a composite RSA candidate. The prover also holds \(\phi (N)\).

  • The protocol:

    1. (a)

      The parties compute first \(c'' = \left( c\cdot (c')^{-1}\right) ^{p^{-1}}\), which is an encryption of \(\alpha {\text {div}} p\) (assuming that \(c'\) is correct).

    2. (b)

      The prover then executes \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) twice, on \((c', p)\) and on \((c'',\lceil M/p\rceil )\), where M is an upper bound on the size of \(\alpha \) that is induced by the protocol that employs this proof (in our case it is \(2^{n-2}\)).

    3. (c)

      The verifier accepts if both proofs are accepting.

Proposition 3.2

Assuming hardness of the DDH problem, \(\pi _{\scriptscriptstyle \mathrm {MOD}}\) is a zero-knowledge protocol with constant overhead.

Proof sketch

It is simple to verify that if \(c'\) is computed correctly, then the verifier is convinced since the bounds hold in both cases. On the other hand, if \(c'\) is computed incorrectly, then \(c/c'\) yields an encrypted plaintext of a value that is not divisible by p, which implies that when multiplying this plaintext by \(p^{-1}\) the result is larger than \(\lceil M/p\rceil )\). Finally, a simulator can be constructed by running twice the simulator for \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\).\(\square \)

In order to transform this proof into a proof of knowledge, the prover can prove the knowledge of the plaintexts and randomness within ciphertexts c and \(c'\).

  1. 3.

    For public Paillier key N, we require \(\Sigma \)-protocol \(\pi _{\scriptscriptstyle \mathrm {EXP-RERAND}}\) that allows a prover to demonstrate that ciphertext \(c'\) is in the image of \(\phi : \mathbb {Z}_N\times \mathbb {Z}_{N^2}^*\mapsto \mathbb {Z}_{N^2}^*\), defined by \(\phi (m,r) = c^m\cdot r^N\bmod N^2\) for a fixed ciphertext \(c\in \mathbb {Z}_{N^2}^*\). Namely,

    $$\begin{aligned} \L _{\scriptscriptstyle \mathrm {EXP-RERAND}}=\left\{ \left( \left( N, c, c'\right) , (m, r)\right) \mid c' = c^m\cdot r^N\right\} \end{aligned}$$

    In order to demonstrate this, the prover picks \(v,r_v\) at random, and sends \(A = \phi (v,r_v)\) to the verifier, who responds with a challenge \(e<N\). The prover then replies with \((z_1,z_2) = (me+v,r^e r_v)\), and the verifier checks that \(\phi (z_1,z_2) = (c')^e\cdot A\); see [23] and [41] for the complete details.

Informally, we show that this proof is a \(\Sigma \)-protocol. Note first that it is straightforward to verify completeness. Special soundness follows from the fact that for two accepting conversions \((A,e,(z_1,z_2))\) and \((A,e',(z_1',z_2'))\) with \(e\ne e'\), we may find integers \(\alpha , \beta \) such that \(\alpha (e-e')+\beta N = 1\) using Euclid’s algorithm (unless \((e-e', N)\) are not co-prime, which implies that we have found a factor of N). It is easily verified that \((\alpha (z_1-z_1'); (z_2/z_2')^\alpha \cdot (c')^\beta )\) is a preimage of \(c'\) under \(\phi \). Finally, the simulator for the special honest-verifier zero knowledge is straightforward: given a commitment, pick \((z_1,z_2)\) at random and compute A.

3.3.1 A Zero-Knowledge Proof for \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\)

In this section we give the details of ZK proof \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) used in Step 3a of Protocol 4 and in proving correctness in Protocol 6. Let \(N_P\) be a public Paillier key, with \(g=N_P+1\) generating the plaintext group. \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) is a \(\Sigma \)-protocol allowing a prover P to demonstrate to a verifier V that a Paillier ciphertext \(c_x\) has been computed based on two other ciphertexts c and \(c'\) as well as a known value, i.e., that P knows a preimage of \(c_x\) with respect to

$$\begin{aligned} \phi _{(c,c')}\left( x, x', x'', r_x\right) = c^x\cdot {c'}^{x'}\cdot \mathsf{Enc}_{pk}\left( x'', r_x\right) \text {.} \end{aligned}$$

Protocol 3

\(\Sigma \)-protocol for \(\mathcal{R}_{\scriptscriptstyle \mathrm {VERLIN}}\):

  • Inputs for the parties: A security parameter \(1^n\), public key \(N_p\), and three ciphertexts \(c,c',c_x\). The prover also holds the values \(x,x',x'',r_x\) for which it holds that \(c_x=\phi _{(c,c')}\left( x, x', x'', r_x\right) \).

  • The protocol:

    1. 1.

      The prover picks \(a, a', a''\) uniformly at random from \(\mathbb {Z}_{N_P}\) and \(r_a\) uniformly at random from \(\mathbb {Z}{}_{N_P}^*\) and sends to the verifier

      $$\begin{aligned} c_a = \phi _{(c,c')}\left( a,a',a'',r_a\right) . \end{aligned}$$
    2. 2.

      The verifier then picks a uniformly random t-bit challenge e and sends this to the prover.Footnote 1

    3. 3.

      The prover replies with the tuple

      $$\begin{aligned} \left( z,z',z'',r_z\right) = \left( xe+a, x'e+a',x''e+a'', r_x^er_a\right) \text {.} \end{aligned}$$
    4. 4.

      The verifier accepts if and only if \(\phi _{(c,c')}\left( z,z',z'',r_z\right) = c_x^e\cdot c_a\).

Proposition 3.3

Assuming hardness of the DCR problem, \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) is a \(\Sigma \)-protocol with constant overhead.

Proof

We prove that all three properties required for \(\Sigma \)-protocols (cf. Definition 2.6) are met. Completeness. An honest prover always convinces the verifier, since

$$\begin{aligned} \begin{aligned} \phi _{(c,c')}\left( z,z',z'',r_z\right)&= \phi _{(c,c')}\left( xe+a, x'e+a',x''e+a'', r_x^er_a\right) \\&= c^{xe+a}\cdot {c'}^{x'e+a'}\cdot g^{x''e+a''}\cdot \left( r_x^er_a\right) ^{N_P}\\&= \left( c^x\cdot {c'}^{x'}\cdot g^{x''}\cdot r_x^{N_P}\right) ^e \cdot \left( c^a\cdot {c'}^{a'}\cdot g^{a''}\cdot r_a^{N_P}\right) \\&= c_x^e\cdot c_a. \end{aligned} \end{aligned}$$

Special soundness. A preimage of \(c_x\) may be computed given two accepting conversations with same initial message, \(c_a\), and differing challenges \(e\ne {\bar{e}}\). Denote the final messages of the two executions \(\left( z,z',z'',r_z\right) \) and \(\left( {\bar{z}},{\bar{z}}',{\bar{z}}'',r_{{\bar{z}}}\right) \), and compute integers \(\alpha \) and \(\beta \) such that

$$\begin{aligned} \alpha \left( e-{\bar{e}}\right) + \beta \cdot N_P = 1 \end{aligned}$$

using the extended Euclidian algorithm. This is always possible as \(e-{\bar{e}}\) and \(N_P\) are co-prime. It is straightforward but tedious to verify that

$$\begin{aligned} \left( \alpha \left( z-{\bar{z}}\right) , \alpha \left( z'-{\bar{z}}'\right) , \alpha \left( z''-{\bar{z}}''\right) , \left( r_z\cdot r_{{\bar{z}}}^{-1}\right) ^\alpha \cdot \left( c_x\bmod N_P\right) ^\beta \right) \end{aligned}$$

is a preimage of \(c_x\), briefly

$$\begin{aligned} \begin{aligned} \phi _{(c,c')}&\left( \alpha \left( z-{\bar{z}}\right) , \alpha \left( z'-{\bar{z}}'\right) , \alpha \left( z''-{\bar{z}}''\right) , \left( r_z\cdot r_{{\bar{z}}}^{-1}\right) ^\alpha \cdot \left( c_x\bmod N_P\right) ^\beta \right) \\&= \left( c_x^e\cdot c_a\right) ^\alpha /\left( c_x^{{\bar{e}}}\cdot c_a\right) ^\alpha \cdot \left( \left( c_x\bmod N_P\right) ^\beta \right) ^{N_P}\\&= c_x^{\alpha \left( e-{\bar{e}}\right) }\cdot c_x^{\beta \cdot N_P}\\&= c_x\text {.} \end{aligned} \end{aligned}$$

Special honest-verifier zero-knowledge. Accepting transcripts are easily simulated. Given challenge e, pick \(z,z',z''\) uniformly at random from \(\mathbb {Z}_{N_P}\) and \(r_z\) uniformly at random from \(\mathbb {Z}{}_{N_P}^*\). Then, compute

$$\begin{aligned} c_a = \phi _{(c,c')}\left( z,z',z'', r_z\right) \cdot c_x^{-e}\text {.} \end{aligned}$$

Clearly, this is an accepting conversation. Moreover, for preimage \((x,x',x'',r_x)\) (i.e., the witness),

$$\begin{aligned} \left( z-ex,z'-ex',z''-ex'',r_z\cdot r_x^{-e}\right) \end{aligned}$$

is uniformly random, and a preimage of \(c_a\), i.e., it corresponds to the choice of \((a,a',a'',r_a)\); hence \(c_a\) is distributed as in the real protocol. Finally, given this random choice and a witness, \((z,z',z'',r_z)\) is exactly the final message that an honest prover would send. \(\square \)

4 A Distributed Generation of an RSA Composite

This section presents a protocol, denoted \(\mathsf{DKeyGen}\), for distributively generating an RSA composite without disclosing any information about its factorization and with security against malicious activities. In this protocol the parties generate candidates for the potential composite which they run through a biprimality test for checking its validity. Our protocol is useful for designing distributive variants of the RSA encryption and signature schemes, as well as other schemes that rely on factoring-related hardness assumptions. In this paper we use this protocol for distributively generating the public key for Paillier [55] encryption scheme. The starting point for \(\mathsf{DKeyGen}\) is the protocols of [5, 36]. These protocols are designed to distributively generate an RSA composite \(N=p\cdot q\) with an unknown factorization. Specifically, the protocol by Boneh and Franklin [5] assumes honest majority, whereas the protocol by Gilboa [36] adopts ideas from [5] into the two-party setting; both are secure in the semi-honest setting.

Recall that when coping with malicious adversaries it must be assured that the parties follow the protocol specifications. In our context this means that the parties’ shares must be of the appropriate length and that no party gains any information about the factorization of N, even by deviating.Footnote 2 This challenging task is typically addressed by adding commitments and zero-knowledge proofs to each step of the protocol. Unfortunately, this is usually not very practical since the statements that needed to be proven are complicated, therefore leading to highly inefficient protocols. Instead, we will be exploiting specific protocols for our tasks (some new to this work) that are both efficient and fully secured. By proper analysis of where to use the zero-knowledge proofs, which proofs to use and moreover, by a novel technique of utilizing two different encryption schemes with different homomorphic properties, we achieve a highly efficient key generation protocol. It should be noted that except for the setup step which is only executed once we can avoid expensive zero-knowledge proofs based on the cut-and-choose technique. Additional optimizations can be found in Sect. 6.

For the sake of completeness we include a short description of [5] as adapted by [36] for the two-party setting. These protocols consist of the following three steps: (1) Each party \(P_i\) generates two random numbers \(p_i\) and \(q_i\) representing shares of p and q, such that \(p= \sum _i p_i\), \(q= \sum _i q_i\) and \(p \equiv q \equiv 3 \pmod 4\). We note that [5] includes a distributed trial division of p and q for primes less than a bound B, which greatly improves the efficiency of the protocol. This trial division is not adopted by [36], making our solution the first two-party protocol achieving the significant speedup from this trial division. (2) After having created the two candidates for being primes, the parties execute a secure multiplication protocol to compute \(N=(p_0+p_1)(q_0+q_1)\). In [5] this step is based on standard generic solutions. Here we take a novel approach of utilizing both ElGamal and Paillier encryption schemes, giving us active security at a very low cost. Generating the RSA composite this way does not guarantee that the composite is made of uniformly random primes since the adversary can, in some limited way, influence the distribution of the primes. This issue was observed in [5] and discussed further below. (3) Finally, the candidate N for being an RSA composite is tested by a distributed biprimality test, which requires \(p \equiv q \equiv 3 \pmod 4\). If the biprimality test rejects N as being a proper RSA modulus, the protocol is restarted.

Typically, the definition for the key generation algorithm requires that the RSA composite would be a product of two randomly chosen equal length primes p and q. However, in order to use the distributed biprimality test of Boneh and Franklin N must be a Blum integer (namely, \(N = pq\), where \(p \equiv q \equiv 3 \mod 4\)). Note that this is a common requirement for distributed biprimality tests and it does not decrease the security of the constructions that use these type of keys, since about 1 / 4 of all the RSA modulus are Blum integers. Moreover, as pointed out by [5], the parties can always influence the distribution of the most significant bit of each prime. This is because p and q are generated by adding shares over the integers which implies that they are not uniformly random, so that each party has some (limited) knowledge of the distribution based on its shares.

We will therefore define a new public key generation algorithm, \(\mathsf{Gen}'\), which captures this deviation and generates N by the same distribution as the protocol. This is obtained by \(\mathsf{Gen}'\) receiving additional two inputs \(r_p\) and \(r_q\), representing potential adversary’s input shares. \(\mathsf{Gen}'\) adds this shares to some truly random chosen shares and ensures that the sum is congruent to \(3 \mod 4\). Formally, let \(\mathsf{Gen}'(1^n, r_p, r_q)\) denote a public key generation that takes two additional inputs besides the security parameter \(1^n\) and works as follows:

  1. 1.

    If \(r_p, r_q \ge 2^{n-2}\) output \(\bot \) and halt.

  2. 2.

    Otherwise, choose a uniform random \(s_p \in \{0,1\}^{n-2}\).

  3. 3.

    Calculate \(p = 4(r_p + s_p) + 3\) and examine the outcome:

    • if p is composite, then goto Step 2 and choose a new value for \(s_p\).

    • if p is prime, then repeat the process to generate q.

  4. 4.

    Return \(N = pq\), and generate the private key as in \(\mathsf{Gen}\).

As proven by Boneh and Franklin, using \(\mathsf{Gen}'\) instead of \(\mathsf{Gen}\) does not give the adversary the ability to factor N even if it can slightly influence its distribution. We formally state the security statement proven by [5].

Lemma 4.1

(Revised [5, Lemma 2.1]) Suppose there exists a ppt algorithm \(\mathcal{B}\) that chooses values \((r_p,r_q)\) as above, then given \(N \leftarrow \mathsf{Gen}'(1^n,r_p,r_q)\) and finally, factors N with probability at least \(1/n^d\). Then there exists an expected polynomial-time algorithm \(\mathcal{B}'\) that factors a random RSA modulus with n-bit factors with probability at least \(1/(2^7n^d)\).

This lemma was originally stated for semi-honest adversaries but holds for the malicious case as well. We note that protocols with p and q being chosen as uniform random values do exist; however, they are significantly less efficient. Therefore, we choose to accept this non-uniform distribution induced by protocol \(\mathsf{DKeyGen}\) and let the ideal functionality capture this deviation. Functionality \({\mathcal{F}_{\scriptscriptstyle \mathrm {GEN}}}\) formalizes this discussion in Fig. 1.

Fig. 1
figure 1

The RSA composite generation functionality

We are now ready to describe our protocol which in addition to the above three steps includes a key-setup step used to generate keys for commitments and encryption schemes used in the protocol. Namely, a shared key is generated for the distributed additively homomorphic ElGamal encryption scheme and each party generates a key for standard non-distributive Paillier encryption and integer commitments. We observe that the reason for using both ElGamal and Paillier is due to efficiency considerations. Namely, most zero-knowledge proofs used here can be implemented in an efficient manner when applied on ElGamal (with a known group order), rather than on Paillier. Nevertheless, the plaintext cannot be recovered efficiently and therefore we use Paillier in a non-distributive fashion. We note that consistency between the encryptions using Paillier and ElGamal is only proven implicitly, by repeating the computations and verifying that the two executions give the same result. In addition, the fact that a distributed ElGamal variant can be easily obtained allows us to design trial division test that is run on individual primes and improves the numbers of trials. In order to cope with malicious adversaries, our protocols employ zero-knowledge (ZK) proofs; some are known and others are new to this work and are interesting by themselves. We note that all the proofs that participate in Protocol 4 require a strict constant overhead. In Sect. 3 we specify these proofs in detail.

Protocol 4

\([\mathsf{DKeyGen}]\) A distributed generation of an RSA composite with malicious security:

  • Inputs for parties\({P}_{ 0}, {P}_{1}\): A security parameter \(1^n\) and a threshold B for the trial division.

  1. 1.

    Key-setup.

    1. (a)

      The parties run protocol \(\pi _{\scriptscriptstyle \mathrm {EGGEN}}\) (cf. Sect. 2.2.2) for generating a public key \(pk_{\scriptscriptstyle \mathrm {EG}}=(g,h)\) and secret key shares \(sk^0_{\scriptscriptstyle \mathrm {EG}}\) and \(sk^1_{\scriptscriptstyle \mathrm {EG}}\) for ElGamal.

    2. (b)

      Each party \(P_i\) generates a Paillier key pair \((pk_{\scriptscriptstyle \mathrm {Pa}}^i,sk_{\scriptscriptstyle \mathrm {Pa}}^i)\) with a modulus bit length of \(\lambda > 2n\) and sends \(pk_{\scriptscriptstyle \mathrm {Pa}}^i =N_{\scriptscriptstyle \mathrm {Pa}}^i\) to the other party. Each party proves correctness of \(N_{\scriptscriptstyle \mathrm {Pa}}^i\) by \(\pi _{\scriptscriptstyle \mathrm {RSA}}\) (cf. Sect. 3). The Paillier keys are used for encryptions and commitments (cf. Sects. 2.2.12.3)

  2. 2.

    Generate candidates.

    1. (a)

      Generate shares of candidate. Each party \(P_i\) picks a random \((n-2)\)-bit value \({\bar{p}}_i\), encrypts it, and sends \({\bar{c}}_i = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}({\bar{p}}_i)\) to the other party. The parties prove knowledge of the plaintexts, via \(\pi _{\scriptscriptstyle \mathrm {ENC}}\), and prove that \({{\bar{p}}}_i < 2^{n-2}\) via \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\).

      In order to ensure that \(p_0\equiv 3\bmod 4\), the parties compute \(c_0 \leftarrow \left( {\bar{c}}_0\right) ^4\cdot \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(3)\). Similarly, the parties ensure that \(p_1\equiv 0 \bmod 4\) by \(c_1 \leftarrow \left( {\bar{c}}_1\right) ^4\).

    2. (b)

      Trial division. For all primes \(\alpha \le B\), the parties run a trial division on \(p = p_0+p_1\). Each party \(P_i\) sends an encryption \(c_i^{(\alpha )} = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(p_i\bmod \alpha )\) to the other party, and proves the correctness of the computation using \(\pi _{\scriptscriptstyle \mathrm {MOD}}\).

      The parties compute \(c^{(\alpha )}\leftarrow c_0^{(\alpha )} \cdot c_1^{(\alpha )}\) and \({\tilde{c}}^{(\alpha )}\leftarrow c^{(\alpha )} \cdot \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(-\alpha )\). Clearly, \(\alpha \) divides p if and only if \(p_0^{(\alpha )}+p_1^{(\alpha )} \in \left\{ 0, \alpha \right\} \), i.e., when either \({c}^{(\alpha )}\) or \({\tilde{c}}^{(\alpha )}\) is an encryption of zero. This is checked by raising these to secret, nonzero exponents and decrypting. If no prime \(\alpha < B\) divides the candidate it is accepted by trial division.

    3. (c)

      Repeat. Repeat Steps 2a- 2b until two candidates p and q survive trial division.

  3. 3.

    Compute product (\({\mathbf{N}} = {\mathbf{pq}}\)).

    1. (a)

      Compute the product.\(P_0\) sends \(P_1\) encryptions of \({\tilde{p}}_0 =p_0\) and \({\tilde{q}}_0 = q_0\) under \(pk_{\scriptscriptstyle \mathrm {Pa}}^0\) and proves knowledge of plaintexts using \(\pi _{\scriptscriptstyle \mathrm {ENC}}\). (Note that a malicious \(P_0\) may send encryptions of incorrect values). Next, \(P_1\) computes and sends:

      $$\begin{aligned}&c_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0} \leftarrow \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}(p_0)^{q_1} \cdot \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}(q_0)^{p_1} \cdot \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}(p_1q_1)\\&\quad = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}((p_0+p_1)(q_0+q_1) - p_0q_0) \end{aligned}$$

      Furthermore, \(P_1\) proves that \(c_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0}\) has been computed as a known linear combination based on \(\mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}({\tilde{p}}_0)\) and \(\mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}({\tilde{q}}_0)\) using \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\). \(P_0\) decrypts, thus obtaining the plaintext \(m_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0}\); from this \({\tilde{N}} = m_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0} + {\tilde{p}}_0{\tilde{q}}_0\) is computed and sent to \(P_1\) along with an encryption \(c_\pi = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}({\tilde{p}}_0{\tilde{q}}_0)\). Finally, using \(\pi _{\scriptscriptstyle \mathrm {MULT}}\) and \(\pi _{\scriptscriptstyle \mathrm {ZERO}}\), \(P_0\) proves that \(c_\pi \) contains the product of the two original ciphertexts and that \({\tilde{N}}\) is the plaintext of

      $$\begin{aligned} c_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0}c_\pi = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}(({\tilde{p}}_0+p_1)({\tilde{q}}_0+q_1))\text {.} \end{aligned}$$
    2. (b)

      Verify multiplication. The parties use the homomorphic property of ElGamal encryption to compute an encryption of \(N = (p_0+p_1)(q_0 + q_1)\) from the ciphertexts generated at Step 2a. The computation is analogous to that of Step 3a, again using \(\pi _{{\scriptscriptstyle \mathrm {MULT}}}\) for proving correct multiplication of \((p_i\cdot q_i)\)

      The parties use secure decryption of distributed ElGamal \(\pi _{\scriptscriptstyle \mathrm {DEC}}\) (cf. Sect. 2.2.2) to obtain \(g^N\), where both verify that \(g^{{\tilde{N}}} = g^N\), i.e., that \(N={\tilde{N}}\) and abort if equality does not hold.

  4. 4.

    Biprimality Test. Execute biprimality test (cf. Sect. 4.2) and accept N if the test has accepted; otherwise, the protocol is restarted from Step 2a.

Theorem 4.1

Assuming hardness of the DDH and DCR problems, Protocol 4 realizes \({\mathcal{F}_{\scriptscriptstyle \mathrm {GEN}}}\) in the presence of malicious adversaries.

A proof overview. Note that if both parties follow the protocol then a valid RSA modulus N is generated with high probability. Specifically, in the last iteration of the protocol two elements are chosen randomly and independently of previous generated candidates and are multiplied to produce N. By the correctness of the biprimality test specified below, N is a product of two primes with overwhelming probability.

We assume the simulator has knowledge of the distribution of the loops in the protocol, from the protocol returning to step 2a when candidates are rejected. The simulator can simulate the distribution by running the protocol “in its head,” emulating the role of the honest party. Namely, denoting by \(P_i\) the corrupted party, then upon extracting \(\mathcal{A}\)’s shares \(p_i,q_i\), \(\mathcal{S}\) picks two shares \(p_{1-i},q_{1-i}\) as the honest party would do and checks whether \(N_\mathcal{S}=(p_i+p_{1-i})(q_i+q_{1-i})\) constitutes a valid RSA composite. If this is not the final iteration of the protocol, implied by the fact that \(N_\mathcal{S}\) is not a valid RSA composite, \(\mathcal{S}\) uses \(p_{1-i},q_{1-i}\) to perfectly emulate the role of the honest \(P_{1-i}\). If this is the final iteration, \(\mathcal{S}\) asks the trusted party for \({\mathcal{F}_{\scriptscriptstyle \mathrm {GEN}}}\) to generate an RSA composite with \(p_i,q_i\) being the adversary’s input (as specified in Fig. 1) and completes the execution by emulating the role of the honest party on arbitrary shares. The simulation is different for the two corruption cases as the parties’ roles are not symmetric. For the case that \(P_0\) is corrupted, the simulator sends back in Step 3a the encryption of the composite returned from the trusted party and makes the ElGamal decryption decrypt into this composite as well. For the case that \(P_1\) is corrupted the simulator “decrypts” the Paillier ciphertext result into that composite and then makes the ElGamal decryption return the same outcome.

In Step 3a, where the parties compute the product, we note that it is insufficient to let \(P_1\) complete the computation over the encrypted shares of \(P_0\) without verification of correctness. The problem is that \(P_1\) may attempt to compute N in a different, potentially failing way. Hence if it findsN, this may leak information. Although this issue does not seem critical for practical considerations, we have to deal with it in order to obtain simulation-based security. This makes this corruption case a particular challenge since we had to show that an alternative computation in a successful execution implies determining the factors before the RSA modulus is revealed.

The complete proof follows.

Proof

The proof is shown in a hybrid model, where a trusted party replaces the protocols \(\pi _{\scriptscriptstyle \mathrm {EGGEN}}\), \(\pi _{\scriptscriptstyle \mathrm {ENC}}\), \(\pi _{\scriptscriptstyle \mathrm {MOD}}\), \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\), \(\pi _{\scriptscriptstyle \mathrm {MULT}}\), \(\pi _{\scriptscriptstyle \mathrm {ZERO}}\), \(\pi _{\scriptscriptstyle \mathrm {EGDEC}}\) and \(\mathsf{DPrim}\). We assume the simulator \(\mathcal{S}\) has knowledge of the distribution of the loops in the protocol. The simulator can then simulate the distribution by running the protocol “in its head,” emulating the role of the honest party. Namely, denoting by \(P_i\) the corrupted party, then upon extracting \(\mathcal{A}\)’s shares \(p_i,q_i\), \(\mathcal{S}\) picks two shares \(p_{1-i},q_{1-i}\) as the honest party would do and checks whether \(N_\mathcal{S}=(p_i+p_{1-i})(q_i+q_{1-i})\) constitutes a valid RSA composite. If this is not the final iteration of the protocol, implied by the fact that \(N_\mathcal{S}\) is not a valid RSA composite, \(\mathcal{S}\) uses \(p_{1-i},q_{1-i}\) to perfectly emulate the role of the honest \(P_{1-i}\). If this is the final iteration, \(\mathcal{S}\) asks the trusted party for \({\mathcal{F}_{\scriptscriptstyle \mathrm {GEN}}}\) to generate an RSA composite with \(p_i,q_i\) being the adversary’s input (as specified in Fig. 1) and completes the execution as follows. We distinguish between three different corruption cases.

No party is corrupted. In this case the adversary only sees the communication exchanged between the two parties. Specifically, we claim that such an attacker that only eavesdrops the communication cannot learn meaningful information about the factorization of N. This is because even an adversary that fully corrupts one of the parties cannot obtain such information. Let alone an adversary that does not control the secret shares of one of the parties.

\(P_0\)is corrupted. Let \(\mathcal{A}\) denote an adversary controlling party \(P_0\). Then, construct a simulator \(\mathcal{S}\) simulating the view of the adversary as follows.

  1. 1.

    Key-Setup.

    1. (a)

      \(\mathcal{S}\) emulates the trusted party \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGGEN}}\) by generating an ElGamal key pair \((pk_{\scriptscriptstyle \mathrm {EG}}, sk_{\scriptscriptstyle \mathrm {EG}})\), sharing \(sk_{\scriptscriptstyle \mathrm {EG}}\) to \(sk^\mathcal{S}_{\scriptscriptstyle \mathrm {EG}}\) and \(sk^\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) and handing \(pk_{\scriptscriptstyle \mathrm {EG}}\) and \(sk^\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) to \(\mathcal{A}\).

    2. (b)

      \(\mathcal{S}\) generates a Paillier key pair \((pk_{\scriptscriptstyle \mathrm {Pa}}^\mathcal{S}, sk_{\scriptscriptstyle \mathrm {Pa}}^\mathcal{S})\) as described, sends \(pk_{\scriptscriptstyle \mathrm {Pa}}^S\) to \(\mathcal{A}\), and receives a key \(pk_{\scriptscriptstyle \mathrm {Pa}}^\mathcal{A}\) from \(\mathcal{A}\). \(\pi _{\scriptscriptstyle \mathrm {RSA}}\) is executed to verify that the Paillier keys are well formed.

  2. 2.

    Generate Candidates.

    1. (a)

      Generate Shares of Candidate.\(\mathcal{S}\) uses 0 for \({\tilde{p}}_\mathcal{S}\), encrypts it and sends \({\tilde{c}}_\mathcal{S}= \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(0)\) to \(\mathcal{A}\), and receives \({\tilde{c}}_\mathcal{A}\) from \(\mathcal{A}\). \(\mathcal{S}\) emulates the trusted party for \(\mathcal{F}_{\scriptscriptstyle \mathrm {ENC}}\), receiving \(p_\mathcal{A}\) and the randomness used as witness and verifying \({\tilde{c}}_\mathcal{A}\). If the verification fails \(\mathcal{S}\) halts. \(\mathcal{S}\) stores the share \(p_\mathcal{A}\). \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) is executed where \(\mathcal{S}\) once plays the role of the verifier and once the role of the prover (note that 0 meets the bound requirement made in Step 2a of the protocol).

      In order to ensure that \(p_0\equiv 3\bmod 4\), the parties compute \(c_0 \leftarrow \left( {\tilde{c}}_0\right) ^4\cdot \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(3)\). Similarly, the parties ensure that \(p_1\equiv 0 \bmod 4\) by \(c_1 \leftarrow \left( {\tilde{c}}_1\right) ^4\).

    2. (b)

      Trial division. For primes \(\alpha \le B\), \(\mathcal{S}\) sends an encryption \(c_\mathcal{S}^{(\alpha )} = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(0)\) to \(\mathcal{A}\), and receives \(c_\mathcal{A}^{(\alpha )}\) from \(\mathcal{A}\). \(\mathcal{S}\) emulates the trusted party for \(\mathcal{F}_{\scriptscriptstyle \mathrm {MOD}}\), receiving the randomness used for encrypting \(c_\mathcal{A}^{(\alpha )}\) as witness and verifying its correctness.

      \(\mathcal{S}\) and \(\mathcal{A}\) each compute \(c^{(\alpha )}\leftarrow c_\mathcal{A}^{(\alpha )} \cdot c_\mathcal{S}^{(\alpha )}\) and \({\tilde{c}}^{(\alpha )}\leftarrow c^{(\alpha )} \cdot \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}(-\alpha )\), and raising these to secret, nonzero exponents.

      \(\mathcal{S}\) simulates decrypting, by emulating the output of \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGDEC}}\) to be either zero or a random nonzero element in the plaintext space. A nonzero element is output when trial division by \(\alpha \) should succeed, and zero is the output when trial division should fail. This is simulated according to the distribution of the execution.

    3. (c)

      Repeat. Repeat step 2a and 2b according to the distribution of execution.

  3. 3.

    Compute Product (\(N = pq\)).

    1. (a)

      Compute the product.\(\mathcal{S}\) sends \(p_0\) and \(q_0\) to \({\mathcal{F}_{\scriptscriptstyle \mathrm {THRES}}}\) and receives an RSA composite N from \({\mathcal{F}_{\scriptscriptstyle \mathrm {THRES}}}\). If \(\mathcal{A}\) does not deviate and sends proper encryptions of \(p_0,q_0\), \(\mathcal{S}\) simulates \(c_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0} \leftarrow \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}(N - p_0q_0)\) and emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {VERLIN}}\) as accepting. \(\mathcal{S}\) then receives \({\tilde{N}}\) and \(c_\pi \) from \(\mathcal{A}\) and emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {MULT}}\) and \(\mathcal{F}_{\scriptscriptstyle \mathrm {ZERO}}\) by receiving the witnesses and verifying the statements. If the conditions for accepting are not met, \(\mathcal{S}\) halts, aborting the execution.

      If \(\mathcal{A}\) does not send proper encryptions of \(p_0,q_0\), \(\mathcal{S}\) uses \(p_1,q_1\), picked at the outset of this iteration, for completing the execution. (Note that \(N_\mathcal{S}=(p_0+p_1)(q_0+q_1)\) form a valid RSA composite. Looking a head, this would imply that the decryption of \(c_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0}\) is identically distributed in both the simulated and hybrid executions since in both cases the adversary sees some information of shares picked as the honest \(P_1\) would).

    2. (b)

      Verify multiplication.\(\mathcal{S}\) simulates the computation of the encrypted N by running the protocol as specified and emulating \(\mathcal{F}_{{\scriptscriptstyle \mathrm {MULT}}}\) twice; once by receiving the witness and verifying the statement, and once by emulating an accepting answer for verifying the honest \(P_1\)’s computations.

      If \(\mathcal{A}\) did not deviate in step 3a, then \(\mathcal{S}\) emulates ideal execution for \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGDEC}}\) as outputting \(g^N = g^{{\tilde{N}}}\) where N is the composite returned by \({\mathcal{F}_{\scriptscriptstyle \mathrm {GEN}}}\). If \(\mathcal{A}\) deviated in step 3a, then \(\mathcal{S}\) emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGDEC}}\) as outputting \(g^{N_\mathcal{S}} \ne g^{{\tilde{N}}}\), and aborting the protocol.

  4. 4.

    Biprimality Test. Simulate \(\mathsf{DPrim}\) as either accepting or rejecting according to the distribution of the protocol run, which can be done by Theorem 4.2.

Clearly, \(\mathcal{S}\) runs in expected polynomial time. It is left to prove indistinguishability of the simulation in the ideal world and the hybrid execution of the protocol. This will be done by a series of games.

Game\({\mathrm {H}}_0\). This game corresponds to the original simulation.

Game\({\mathrm {H}}_1\). In this game there is no functionality \({\mathcal{F}_{\scriptscriptstyle \mathrm {THRES}}}\). Instead, simulator \(\mathcal{S}_1\) generates the RSA modulus N by itself the same way \({\mathcal{F}_{\scriptscriptstyle \mathrm {THRES}}}\) does it. This means \(\mathcal{S}_1\) knows the factorization of N. Furthermore, \(\mathcal{S}_1\) plays the exact same role as \(\mathcal{S}\). \({\mathrm {H}}_1\) is clearly perfectly indistinguishable from \({\mathrm {H}}_0\).

Game\({\mathrm {H}}_2\). Simulator \(\mathcal{S}_2\) does not know the secret ElGamal key. That is, instead of emulating \(\mathcal{F}_{\scriptscriptstyle \mathrm {EGGEN}}\) in step 1a, \(\mathcal{S}_2\) receives \(pk_{\scriptscriptstyle \mathrm {EG}}\) from an oracle, generates a random share as \(sk_{\scriptscriptstyle \mathrm {EG}}^\mathcal{A}\), and hands \(pk_{\scriptscriptstyle \mathrm {EG}}\) and \(sk_{\scriptscriptstyle \mathrm {EG}}^\mathcal{A}\) to \(\mathcal{A}\). Since \(\mathcal{S}_1\) does not use its knowledge of \(sk_{\scriptscriptstyle \mathrm {EG}}\), and since \(sk_{\scriptscriptstyle \mathrm {EG}}^\mathcal{A}\) can be simulated statistically close to the real value, \({\mathrm {H}}_2\) is statistically indistinguishable from \({\mathrm {H}}_1\).

Game\({\mathrm {H}}_3\). In this game simulator \(\mathcal{S}_3\) uses N instead of \(N_\mathcal{S}\) in case \(\mathcal{A}\) deviates in Step 3a of the simulation above. Then, the only difference between the views of games \({\mathrm {H}}_2\) and \({\mathrm {H}}_3\) is with respect to this step. However, since the rest of the messages computed by \(\mathcal{S}_2\) and \(\mathcal{S}_3\) are independent of these composites, the adversary’s view is identically distributed in both games.

Game\({\mathrm {H}}_4\). In this game simulator \(\mathcal{S}_4\) does not simulate the ElGamal ciphertexts by sending encryptions of 0, rather it sends encryptions of the real shares that yield the right RSA composite N. More specifically, since \(\mathcal{S}_4\) extracts the shares \(p_0,q_0\) of \(\mathcal{A}\) and since \(\mathcal{S}_4\) generates N by itself it can compute shares \(p_1,q_1\) such that \(N=(p_0+p_1)(q_0+q_1)\), and simulate the execution resulting in an accepted N.

\({\mathrm {H}}_4\) is computationally indistinguishable from \({\mathrm {H}}_3\) which can be proven by a reduction to the sematic security of ElGamal (according to IND-CPA game specified in Definition 2.4). More formally, the reduction goes as follows: We assume the existence of an distinguisher \(D_{3-4}\) capable of distinguishing \({\mathrm {H}}_3\) from \({\mathrm {H}}_4\) with more than negligible probability. We now construct an adversary \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) for breaking the security of the ElGamal encryption scheme. \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) follows \(\mathcal{S}_4\)’s instructions, except instead of encrypting values with the \(pk_{\scriptscriptstyle \mathrm {EG}}\) it asks an oracle to encrypt either \(m_0 = 0\) or \(m_1\) being the real share that yields a proper prime. \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) completes the execution of \(D_{3-4}\) as in game \({\mathrm {H}}_4\). If \(D_{3-4}\) guesses \({\mathrm {H}}_3\) as being executed, then \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) outputs 0, if \(D_{3-4}\) guesses \({\mathrm {H}}_3\) as being executed, then \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) outputs 1.

Game \({\mathrm {H}}_5\). In this game simulator \(\mathcal{S}_5\) does not extract the shares of the candidates for being primes from \(\mathcal{A}\). Instead, \(\mathcal{S}_5\) generates the shares as the honest \(P_1\) does in the hybrid execution. This implies that the only difference in \(\mathcal{A}\)’s view within executions \({\mathrm {H}}_4\) and \({\mathrm {H}}_5\) is with respect to step 3b of the simulation above, where \(\mathcal{S}_4\) makes the protocol abort if \(\mathcal{A}\) deviates in step 3a by not sending proper encryptions of \(p_0,q_0\). Note that there are two cases here: (1) \(\mathcal{A}\) deviates by sending encryptions of values different than \(p_0\) and \(q_0\), which leads to a different composite than the one computed using the ElGamal encryptions in Step 2a of the simulation. (2) \(\mathcal{A}\) deviates by sending encryptions of values different than \(p_0\) and \(q_0\), which leads to the same composite as the one computed using the ElGamal encryptions in Step 2a.

Focusing on (1), we note that the adversary always sees the same view in both games, since in both cases it sees some information of the real shares picked by \(P_1\) that correspond to N, and gets caught. Since there is no match between the two composites. As for (2), we note that as proven in Sect. 4.1, honest \(P_1\) always detects such a cheating, implying that \({\mathrm {H}}_4\) is statistically close to \({\mathrm {H}}_5\).

Finally, since \({\mathrm {H}}_5\) corresponds to executing the real protocol in the hybrid model, we conclude that if \(P_0\) is corrupted then the real and the ideal executions are computationally indistinguishable.

\(P_1\)is corrupted. Let \(\mathcal{A}\) denote an adversary controlling party \(P_1\). Then, construct a simulator \(\mathcal{S}\) as follows. All steps except step 3a are analog to the previous simulation.

  1. 3.

    Compute Product. (\({\textsc { N}} = {\textsc { pq}}\))

    1. (a)

      Compute the product.\(\mathcal{S}\) simulates the encryptions of \({\tilde{p}}_0\) and \({\tilde{q}}_0\) as encryptions of 0 under \(pk_{\scriptscriptstyle \mathrm {Pa}}^\mathcal{S}\) and emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {ENC}}\), as accepting.

      \(\mathcal{S}\) receives \(c_{{\tilde{N}}-{\tilde{p}}_0{\tilde{q}}_0}\) from \(\mathcal{A}\) and during emulation of \(\mathcal{F}_{\scriptscriptstyle \mathrm {VERLIN}}\), \(\mathcal{S}\) extracts the values \(p_1\), \(q_1\) and \(p_1q_1\), and if these values are not consistent with the values extracted in step 2a, then \(\mathcal{S}\) continues simulating the protocol using \(N_\mathcal{S}\) and \(p_0,q_0\).

      If \(\mathcal{A}\) does not deviate, \(\mathcal{S}\) sends encryption of \({\tilde{N}} = N\) to \(\mathcal{A}\) along with an encryption \(c_\pi = \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {Pa}}^0}(0)\) and emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {MULT}}\) and \(\mathcal{F}_{\scriptscriptstyle \mathrm {ZERO}}\) as accepting.

Clearly, \(\mathcal{S}\) runs in expected polynomial time, it is left to prove indistinguishability of the simulation in the ideal world and the real execution of the protocol. This will be done by a series of games.

Game \({\mathrm {H}}_0\)\({\mathrm {H}}_4\). These games are identical to games \({\mathrm {H}}_0\) - \({\mathrm {H}}_4\) in the case of the corruption of \(P_0\).

Game \({\mathrm {H}}_5\). In this game simulator \(\mathcal{S}_5\) does not simulate the Paillier encryptions by encryptions of 0. Instead, it sends the encryption of \(p_0 q_0\). We claim that \({\mathrm {H}}_4\) and \({\mathrm {H}}_5\) are computationally indistinguishable. The proof is completely analog to the indistinguishability of \({\mathrm {H}}_3\) and \({\mathrm {H}}_4\).

Game \({\mathrm {H}}_6\). In this game simulator \(\mathcal{S}_6\) does not extract the shares of the prime candidates from \(\mathcal{A}\) in steps 2a and 3a. Instead, \(\mathcal{S}_6\) generates the shares as the honest \(P_0\) does in the hybrid execution. Recall that in the previous game \(\mathcal{S}_5\) makes the protocol abort in step 3b if \(\mathcal{A}\) deviates in step 3a; however, as described in “Appendix 4.1” this will also be the case in this game. Therefore, \({\mathrm {H}}_5\) and \({\mathrm {H}}_6\) are statistically close.

Since \({\mathrm {H}}_6\) corresponds to executing the real protocol in the hybrid model, we conclude that if \(P_0\) is corrupted then the real and the ideal executions are computationally indistinguishable. \(\square \)

4.1 Deviation while Computing \({\tilde{N}}\) is Always Detected

The ZK proofs used in the calculation of \({\tilde{N}}\) in Step 3a in Protocol 4 ensure that the parties compute \({\tilde{N}}\) based on values they know, but not that the correct \(p_i\) and \(q_i\) are used for this computation. More specifically, this step ensures that \({\tilde{N}} \equiv N\bmod N_0\), where \(N_0\) is the Paillier key picked by \(P_0\). However, this does not rule out from a malicious party, \(\mathcal{A}\), supplying wrong values but still getting the right result. For instance, \(\mathcal{A}\) can guess the difference \(\delta \) between p and q and switch the factors around by using \(p_i+\delta \) and \(q_i-\delta \) instead of \(p_i\) and \(q_i\), respectively. Now, since we have that

$$\begin{aligned} p_0 + p_1 + \delta = q,~~~ q_0+q_1 - \delta = p \end{aligned}$$

the product of \(p_i+\delta \) and \(q_i-\delta \) still equals N. Intuitively, this specific attack is infeasible; however, we must rule out all such attacks. A much worse attack would be one where the attacker could induce failure, say depending on some specific bit of N (which is of course unknown to \(\mathcal{A}\) at the time). In a real execution of the protocol, since N is the output, \(\mathcal{A}\) simply learns the bit ahead of time, which may not be critical in practice. However, in the simulated execution, \(\mathcal{A}\) learns a bit of the simulated modulus, N, which may differ from the analogous bit of the modulus supplied by the ideal functionality, \({\mathcal{F}_{\scriptscriptstyle \mathrm {GEN}}}\). Hence \(\mathcal{A}\) may be able to distinguish between the executions.

In this section we show that no such behavior is possible. Specifically, we show that if an execution with a malicious \(\mathcal{A}\) results in \({\tilde{N}} =N\), then this must have been computed using the correct shares of p and q. We do this by using \(\mathcal{A}\) to break the IND-CPA security of either ElGamal or Paillier encryption (cf. Definition 2.4). We distinct the cases of corrupted \(P_0\) and \(P_1\).

\(P_0\)is corrupted. Let \(\mathcal{A}\) denote an adversary controlling party \(P_0\) and denote by bad the event in which a malicious \(P_0\) sends in Step 3a of Protocol 4 encryptions of \({\tilde{p}}\) and \({\tilde{q}}\) with \({\tilde{p}}_0\ne p_0 \vee {\tilde{q}}_0\ne q_0\) and an honest \(P_1\) does not abort the execution (where \(p_0,q_0\) are the decryptions of ciphertexts sent in Step 2a using the ElGamal scheme). Then, conditioned on bad, we have that

$$\begin{aligned} \begin{aligned} {\tilde{q}}_0p_1 + {\tilde{p}}_0q_1 + q_1p_1 + {\tilde{q}}_0{\tilde{p}}_0&\equiv {\tilde{N}}\bmod N_{0}\\&\equiv N \bmod N_{0}\\&\equiv {q}_0p_1 + {p}_0q_1 + q_1p_1 + {q}_0{p}_0\bmod N_{0}, \end{aligned} \end{aligned}$$

since the execution of \(\pi _{\scriptscriptstyle \mathrm {MULT}}\) ensures that \(P_0\) correctly adds the product of the two initial values in the final step, and \({\tilde{N}} \ne N\) would be caught in the following step, causing \(P_1\) to abort. This implies that we know \(\alpha = {\tilde{q}}_0-q_0,~~\beta ={\tilde{p}}_0-p_0,~~\gamma = {\tilde{q}}_0{\tilde{p}}_0 - {q}_0{p}_0 \in \mathbb {Z}_{N_{0}}\) such that

$$\begin{aligned} \alpha \cdot p_1 + \beta \cdot q_1 + \gamma \equiv 0\bmod N_{0}\end{aligned}$$

and either \(\alpha \ne 0\) or \(\beta \ne 0\). These values will be used to determine information about \(p_1\) and \(q_1\) which may, in turn, be used to break the IND-CPA security of ElGamal.

More formally, assume bad occurs with probability \(\epsilon \). Then, construct an adversary \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) that breaks the IND-CPA security of ElGamal with probability \(1/2+\epsilon /2\) as follows. Given an ElGamal public key \(pk_{\scriptscriptstyle \mathrm {EG}}'=(g,h')\), and a ciphertext \(c_b\) which is an encryption of \(b\in \{0,1\}\), \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) simulates the initial key generation by replacing \(pk_{\scriptscriptstyle \mathrm {EG}}\) with \(pk_{\scriptscriptstyle \mathrm {EG}}'\) (faking the proof that knows part of the decryption key). \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) then extracts \(p_0\) and \(q_0\) from \(\mathcal{A}\)’s ElGamal encryptions and generates two independent sets of candidates, \(p_1^{(0)},p_1^{(1)},q_1^{(0)},q_1^{(1)}\) which will pass trial division. \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) then computes encryptions of one of the pairs:

$$\begin{aligned} c_{p_1}^{(b)} = {\left( c_b\right) }^{p_1^{(1)} - p_1^{(0)}}\mathsf{Enc}\left( {p_1^{(0)}}\right) \qquad c_{q_1}^{(b)} = {\left( c_b\right) }^{q_1^{(1)} - q_1^{(0)}}\mathsf{Enc}\left( {q_1^{(0)}}\right) \text {.} \end{aligned}$$

Note that in case \(b=0\), then \(c_{p_1}^{(b)}\) and \(c_{q_1}^{(b)}\) correspond to encryptions of \(p_1^{(0)}\) and \(q_1^{(0)}\), respectively. Otherwise, we get encryptions of \(p_1^{(1)}\) and \(q_1^{(1)}\). \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) then simulates the trial division (which is passed), and finally reach the step, where it computes \({\tilde{N}}\), and extracts \({\tilde{p}}_0\) and \({\tilde{q}}_0\) from \(\mathcal{A}\). Note that this allows \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) to compute \(\alpha \), \(\beta \), and \(\gamma \) without even completing this step. \(\mathcal{A}\) outputs 0 if and only if

$$\begin{aligned} \alpha \cdot p_1^{(0)} + \beta \cdot q_1^{(0)} + \gamma \equiv 0\bmod N_{0}. \end{aligned}$$

Due to \(\pi _{\scriptscriptstyle \mathrm {RSA}}\), it holds that \(N_0\) is the product of two large primes with overwhelming probability. Neglecting the event where \(N_0\) is a product of more than two primes, it holds that \(p_1\) and \(q_1\) are co-primes to \(N_0\). In addition, if either \({\text {GCD}}(\alpha , N_0)\ne 1\) or \({\text {GCD}}(\beta , N_0)\ne 1\), we may compute a factor f of \(N_0\), such that

$$\begin{aligned} \alpha \not \equiv 0\bmod f \vee \beta \not \equiv 0 \bmod f \end{aligned}$$

and both \(\alpha \) and \(\beta \) co-prime with f unless congruent to 0. Otherwise, let f equal the trivial factor, \(N_0\). As the execution would pass if it continued, it must hold that

$$\begin{aligned} \alpha \cdot p_1 + \beta \cdot q_1 + \gamma \equiv 0\bmod f\text {,} \end{aligned}$$

i.e., we find a linear equation in \(p_1\) and \(q_1\). However, these will be either \(p_1^{(0)},q_1^{(0)}\) or \(p_1^{(1)},q_1^{(1)}\) depending on the unknown bit chosen by the ElGamal oracle. Hence, if \(\mathcal{A}\) can cheat with probability \(\epsilon \), then \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) breaks the IND-CPA security of ElGamal encryption with probability \(1/2+\epsilon /2\) by checking which pair of candidates gives a linear equation of the form specified above. Formally,

$$\begin{aligned}&{\mathsf{Adv}_{\Pi _{\scriptscriptstyle \mathrm {EG}},\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}}(n)}\\&\quad = \frac{1}{2}\left( \Pr [\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}(c_{p_1}^{(b)},c_{q_1}^{(b)})=0|b=0] + \Pr [\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}(c_{p_1}^{(b)},c_{q_1}^{(b)})=1|b=1]\right) \\&\quad = \frac{1}{2}\left| \Pr [\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}(c_{p_1}^{(b)},c_{q_1}^{(b)})=0|b=0] - \Pr [\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}(c_{p_1}^{(b)},c_{q_1}^{(b)})=0|b=1]\right| + \frac{1}{2}\\&\quad = \Pr [\mathsf{bad}|b=0] - \mathsf{negl}\ge \frac{\epsilon }{2}+ \frac{1}{2} \end{aligned}$$

where \(\mathsf{negl}\) is a negligible function in the security parameter. The reason \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) outputs 0 with negligible probability in the case where \(b=1\) is due to the fact that \(p_1^{(0)},q_1^{(0)}\) are independent of \(p_1^{(1)},q_1^{(1)}\) and information theoretic hidden from \(\mathcal{A}\) (as \(\mathcal{A}_{\scriptscriptstyle \mathrm {EG}}\) either uses \(p_1^{(0)},q_1^{(0)}\) or \(p_1^{(1)},q_1^{(1)}\)). Therefore, the probability that the outcome forms a linear equation for \(p_1^{(0)},q_1^{(0)}\) is negligible.

\(P_1\)is corrupted. Let \(\mathcal{A}\) denote an adversary controlling party \(P_1\) and consider the event bad in which the honest \(P_0\) does not abort even though the malicious \(P_1\) computes \(c_{{\tilde{N}}-p_0q_0}\) differently than specified. Note that even if \(\mathcal{A}\) returns a ciphertext \(c_{{\tilde{N}}-p_0q_0}\), encrypting \(N-p_0q_0\) and computed differently than specified in the protocol, the ZK proof \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) enables to extract values \(x,x',x''\in \mathbb {Z}_{N_0}\) and \(r_x\in \mathbb {Z}{}_{N_0}^*\) such that

$$\begin{aligned} c_{{\tilde{N}}-p_0q_0} = c^x\cdot \left( c'\right) ^{x'}\cdot \mathsf{Enc}(x'',r_x)\text {,} \end{aligned}$$

where c is an encryption of \(p_0\) and \(c'\) is an encryption of \(q_0\). These values will be used to break the IND-CPA security of either ElGamal or Paillier encryptions.

First, construct a distinguisher \(\mathcal{A}_{\scriptscriptstyle \mathrm {Pa}}\) based on \(\mathcal{A}\) which breaks the semantic security of Paillier encryption. Specifically, simulate steps 1 and 2 as above but also extract \(p_1\) and \(q_1\) during the simulation. In step 3, \(\mathcal{A}_{\scriptscriptstyle \mathrm {Pa}}\) is given a Paillier key to be used as \(N_0\) and an encryption \(c_b\) of a bit b. Similarly to above, we generate two sets of candidates, \(p_0^{(0)},p_0^{(1)},q_0^{(0)},q_0^{(1)}\) which will pass trial division, and compute encryptions of one of the pairs:

$$\begin{aligned}c_{p_0^{(b)}} = {\left( c_b\right) }^{p_0^{(1)} - p_0^{(0)}}\mathsf{Enc}\left( {p_0^{(0)}}\right) \qquad c_{q_0^{(b)}} = {\left( c_b\right) }^{q_0^{(1)} - q_0^{(0)}}\mathsf{Enc}\left( {q_0^{(0)}}\right) \text {.}\end{aligned}$$

We send \(c_{p_0^{(b)}}\) and \(c_{q_0^{(b)}}\) as the initial messages in the \({\tilde{N}}\)-computation and fake the proofs of known plaintext. Once \(\mathcal{A}\) has returned \(c_{{\tilde{N}}-p_0q_0}\) (which is an encryption of \(N-p^{(b)}_0q^{(b)}_0\) by assumption), we extract x, \(x'\), \(x''\), and \(r_x\). Again, we do not need to finish this step of the protocol, but may directly use these values to break the IND-CPA security.

As \({\tilde{N}} = N\), we have the following equation in the two unknowns \(p_0^{(b)}\) and \(q_0^{(b)}\)

$$\begin{aligned} \begin{aligned}&xp_0^{(b)} + x'q_0^{(b)} + x'' \equiv q_1p_0^{(b)} + p_1q_0^{(b)} + p_1q_1 \bmod N_0\\ \Updownarrow&\\&\left( q_1 - x\right) p_0^{(b)} + \left( p_1 -x'\right) q_0^{(b)} + \left( p_1q_1-x''\right) \equiv 0 \bmod N_0\\ \end{aligned} \end{aligned}$$

There are two cases:

Case 1:\(q_1 - x = 0 \vee p_1-x' = 0\). In this case, we can compute either \(p_0^{(b)}\) or \(q_0^{(b)}\) by:

$$\begin{aligned} p_0^{(b)} = \left( x''-p_1q_1\right) \left( q_1-x\right) ^{-1}\qquad q_0^{(b)} = \left( x''-p_1q_1\right) \left( p_1-x\right) ^{-1}\text {.} \end{aligned}$$

This calculation requires that the nonzero value is invertible. However, if it is not, then we may compute a factor of \(N_0\) using \({\text {GCD}}\). This allows us to compute the decryption key ourselves, which trivially breaks the security of Paillier.

Case 2: \(q_1 - x \ne 0 \wedge p_1-x' \ne 0\). Again, we may assume that both \(q_1 - x\) and \(p_1-x'\) are invertible. Similarly to the case of a corrupt \(P_0\), we now have a linear equation in \(p_0^{(b)}\) and \(q_0^{(b)}\), and we can easily check which pair, \(\left( p_0^{(0)},q_0^{(0)}\right) \) or \(\left( p_0^{(1)},q_0^{(1)}\right) \), fits the equation; this breaks the security of Paillier encryption as demonstrated above for ElGamal.

Similarly to the above, we can design a reduction to the security of ElGamal by computing encryptions of \(p_0^{(b)}\) and \(q_0^{(b)}\). Then in the computation of \({\tilde{N}}\), we obtain x, \(x'\), \(x''\), and \(r_x\), which again splits into two cases and used to break IND-CPA security.

4.2 The Biprimality Test

The distributed biprimality test for checking the validity of a candidate for being an RSA composite is based on a test by Boneh-Franklin [5] where the parties first agree on a random element \(\gamma \in {\mathbb Z}_N^*\) with Jacobi symbol 1, and then raise \(\gamma \) to a power calculated from their shares. The test accepts a number with more than two prime factors with probability at most 1 / 2. Therefore, the parties must repeat this test sufficiently many times in order to decrease the error. We adopt this test for the malicious setting. As a side remark, we note that although the biprimality test by Damgård and Mikkelsen [25] has a better error estimate, it cannot be used efficiently in the two-party setting with malicious adversaries. In “Appendix B” we show how to adapt their test into the two-party setting when the parties are semi-honest.

Protocol 5

\([\mathsf{DPrim}]\) A distributed biprimality test:

  • Inputs: A security parameter \(1^n\), a statistical parameter \(1^\ell \) and a public key candidate N.

  • The protocol:

    1. 1.

      The parties jointly generate a random element \(\gamma \in {\mathbb Z}_N^*\) with Jacobi symbol \(\mathcal{J}(\gamma )=1\). By standard techniques this is made secure against active deviation.

    2. 2.

      The parties compute the encryption \(e_0=\mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}\left( \frac{N-(p_0+q_0)+1}{4}\right) \) using the homomorphic property of ElGamal (\(P_1\) knows the encryptions of \(p_0\) and \(q_0\) from the earlier protocol). Furthermore, \(P_0\) sends \(\gamma _0=\gamma ^{\left( \frac{N+1-(p_0+q_0)}{4}\right) }\bmod N\) and proves consistency between \(e_0\) and \(\gamma _0\) using \(\pi _{\scriptscriptstyle \mathrm {EQ}}\).

    3. 3.

      \(P_1\) sends \(\gamma _1=\gamma ^{\left( \frac{-(p_1+q_1)}{4}\right) }\bmod N\) to \(P_0\) and proves consistency using \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) to an encryption \(e_1\) of \(\frac{-(p_1+q_1)}{4}\), computed as above.

    4. 4.

      Finally, the parties reject N if and only if \(\gamma _0\cdot \gamma _1\bmod N \ne \pm 1\). We further note that the test by [5] includes an additional step were instead of using \(\gamma \), the parties randomly pick an element from the group \(({\mathbb Z}_N[x]/(x^2+1))^*/{\mathbb Z}_N^*\); we omit the details due to the similarity of the above test.

    5. 5.

      This test is repeated \(\ell \) times to achieve sufficiently small error.

Theorem 4.2

Assuming hardness of the DDH problem, Protocol 5 is a distributed Monte Carlo algorithm such that on a statistical parameter \(1^\ell \) and a random \(\gamma \), it holds that

  • A correctly formed RSA modulus \(N = pq\), where \(p \equiv q \equiv 3 \pmod 4\) is always accepted.

  • The average case probability of accept if either p or q is a composite, is at most \(2^{-\ell }\).

  • The protocol is secure (simulatable with abort without knowledge of the factorization of N) in the presence of malicious adversaries.

Informally, correctness follows from [5] and security is proven by simulation where the simulator is able to simulate the corrupted party’s view by having knowledge of the adversaries shares of p and q, and thereby being able to calculate \(\gamma _0\) or \(\gamma _1\), respectively. With this knowledge the simulator can simulate acceptance of a modulus without knowledge of the factorization. A complete proof follows.

Proof

The theorem states both correctness and security. By correctness we mean: If the parties do not deviate, then Blum integers are never rejected, whereas numbers with more than two prime factors are rejected with probability at least \(2^{-\ell }\). Since the biprimality test is identical to the one of Boneh and Franklin [5], we refer the reader to [5] for a proof of correctness.

Security is proven in the \(\mathcal{F}_{\scriptscriptstyle \mathrm {EQ}}\)-hybrid model. We assume that simulator \(\mathcal{S}\) has knowledge of the shares of adversary \(\mathcal{A}\) from protocol \(\mathsf{DKeyGen}\) for distributively generating an RSA composite. Observe that there are two possible outcomes of \(\mathsf{DPrim}\), either N is rejected, in which case N is not a Blum integer in the real protocol. This can easily be simulated by \(\mathcal{S}\) choosing shares on behalf of the honest player such that N is not a Blum integer and executing the real protocol as the honest party would. It is easy to verify that if \(\mathcal{A}\) deviates then it cannot make \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) accept. In the other case, N is a Blum integer and should be accepted. Therefore, \(\mathcal{S}\) has to be able to simulate \(\mathcal{A}\)’s view without knowing the factorization of N, which is possible in the following way. Assume that \(P_0\) is corrupted by \(\mathcal{A}\); the simulation is analog to the other corruption case.

  1. 1.

    \(\mathcal{S}\) emulates the choice of \(\gamma \) by choosing a uniform random value \(a \in \mathbb {Z}_N^*\) with Jacobi symbol \(\mathcal{J}(a)=1\) and a uniform random bit \(b \in \{0,1\}\) and fixing \(\gamma = a^2(-1)^b \bmod N\).

  2. 2.

    Each player is supposed to calculate \(e_0=\mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}\left( \frac{N-(p_0+q_0)+1}{4}\right) \).

    \(\mathcal{S}\) receives \(\gamma _\mathcal{A}\) from \(\mathcal{A}\), and since \(\mathcal{S}\) has knowledge of the shares \(p_0\) and \(q_0\) of \(\mathcal{A}\), \(\mathcal{S}\) knows a priori the expected value of \(\gamma _\mathcal{A}\). \(\mathcal{S}\) emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {EQ}}\), by receiving \(\left( \frac{N-(p_0+q_0)+1}{4}\right) \) as withness, and verifying whether \(\gamma _\mathcal{A}\) is calculated correct. (Abort if \(\gamma _\mathcal{A}\) is not the expected value)

  3. 3.

    Each player is supposed to calculate \(e_1=\mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}\left( \frac{-(p_1+q_1)}{4}\right) \), we note that this is done with the simulated values for \(p_1\) and \(q_1\).

    \(\mathcal{S}\) sends \(\gamma _\mathcal{S}= (\gamma _\mathcal{A})^{-1}(-1)^b \bmod N\) to \(\mathcal{A}\) and emulates \(\mathcal{F}_{\scriptscriptstyle \mathrm {EQ}}\) accepting.

  4. 4.

    Finally, the parties rejects N if and only if \(\gamma _\mathcal{A}\cdot \gamma _\mathcal{S}\bmod N \ne \pm 1\) (in this iteration they always accept).

    The simulation of the additional test in the group \(({\mathbb Z}_N[x]/(x^2+1))^*/{\mathbb Z}_N^*\) is analog to the simulation described above.

Note the following:

  1. I.

    Because N is a Blum integer, the size of the subgroup of quadratic residues \({\mathrm {QR}}\) in \({\mathbb Z}_N^*\) is half the size of the subgroup of elements with Jacobi symbol 1 in \(\mathbb {Z}_N^*\). Furthermore, \(-1\) is a quadratic non-residue modulo N with Jacobi symbol \(\mathcal{J}(-1) = 1\). This means that \(\gamma \) is a uniform random element of \(\mathbb {Z}_N^*\) with Jacobi symbol \(\mathcal{J}(\gamma ) = 1\). This is the exact distribution in the real execution, since we assume \(\mathcal{A}\) cannot influence the distribution of \(\gamma \) in \(\mathsf{DPrim}\).

  2. II.

    In the real-world execution of \(\mathsf{DPrim}\) the following holds:

    $$\begin{aligned} \gamma _0 \cdot \gamma _1\equiv & {} 1 \mod N \text { if } \gamma \in {\mathrm {QR}}. \\ \gamma _0 \cdot \gamma _1\equiv & {} -1 \mod N \text { if } \gamma \not \in {\mathrm {QR}}. \end{aligned}$$

    From b, \(\mathcal{S}\) knows whether \(\gamma \) is in \({\mathrm {QR}}\) or not, and therefore, \(\gamma _\mathcal{S}\) is simulated perfectly by \(\gamma _\mathcal{S}= (\gamma _\mathcal{A})^{-1}(-1)^b \bmod N\).

Finally, since all values except the encryptions \(e_0\) and \(e_1\) are simulated perfectly, \(\mathcal{A}\) can only distinguish the real and hybrid executions if it can break the sematic security of ElGamal and therefore break the DDH assumption. \(\square \)

5 A Complete Threshold Paillier Cryptosystem

In the following section, we describe our threshold construction in the two-party setting for the Paillier encryption scheme [55]. Our Threshold Paillier Scheme, \(\mathbf{TPS}\), is comprised of the following subprotocols: (i) The protocol \(\mathsf{DKeyGen}\) (cf. Sect. 4) for distributed generation of an RSA composite. (ii) A protocol for distributed generation of the corresponding secret key shares, denoted by \(\mathsf{Dsk}\) (cf. Sect. 5.1.1). (iii) A protocol for distributed decryption, denoted by \(\mathsf{DDec}\), for decrypting according to Paillier’s specifications while maintaining the randomness of the ciphertext a secret (cf. Sect. 5.1.2). These protocols rely on the following standard hardness assumptions: (1) DDH (cf. Definition 2.1), due to employing the ElGamal scheme [30] and (2) DCR (cf. Definition 2.2), due to employing the Paillier scheme [55] and integer commitments [26, 27].

Our protocols form the first complete threshold scheme for Paillier in the two-party setting with security in the presence of malicious adversaries under full simulation-based definitions, following the ideal/real-model paradigm. We denote by \(\Pi =(\mathsf{Gen}',\mathsf{Enc},\mathsf{Dec})\) the Paillier encryption scheme that is depicted in Sect. 2.2.1, with the modified key generation algorithm \(\mathsf{Gen}'\) specified in Sect. 4, encryption algorithm \(\mathsf{Enc}\) and decryption algorithm \(\mathsf{Dec}\). The formal description of the threshold functionality, \({\mathcal{F}_{\scriptscriptstyle \mathrm {THRES}}}\), is found in Fig. 2.

Theorem 5.1

Assuming hardness of the DDH and DCR problems, scheme \(\mathbf{TPS}=(\mathsf{DKeyGen},\mathsf{Dsk},\mathsf{DDec})\) computes functionality \({\mathcal{F}_{\scriptscriptstyle \mathrm {THRES}}}\) in the presence of malicious adversaries.

Proof

The proof for this theorem follows from the proofs for Theorems 4.14.25.2 and 5.3. That is, Theorems 4.1 and 4.2 form a complete key generation protocol, where the parties compute an RSA composite without leaking its factorization. Moreover, Theorems 5.2 and 5.3 guarantee that the parties decrypt according to Paillier in a secure manner. \(\square \)

Fig. 2
figure 2

The (Paillier) threshold functionality

5.1 A Distributed Decryption for Paillier

In this section we present a secure decryption protocol in the distributed setting. We first note that a typical way to decrypt is to use the algorithm of the RSA scheme, where the decrypter raises the ciphertext to the power of the inverse of N modulo \(\phi (N)\), as shown in [12]. This similarity follows because both schemes have the same public key of an RSA composite N and a secret key that is the factorization of N. Furthermore, the ciphertexts in both schemes have similar algebraic structure.

However, in some scenarios this type of algorithm may be problematic, since the decrypter must extract first the randomness used for computing the ciphertext in order to complete the decryption. As desirable as this property may be, it is problematic in the context of simulation-based secure computation because the parties have to present the randomness of the ciphertext instead of proving correctness using ZK proofs. This means that a potential simulator cannot cheat in the decryption by encrypting arbitrary values and then fake their decryption. We further note that Paillier’s scheme requires extra computation in order to complete the decryption. This means that on top of raising the ciphertext to the power of the secret value, the outcome must be multiplied with the inverse of the secret key in order to extract the plaintext. In the distributive setting this implies that the parties must keep two types of shares. When coping with malicious behavior, it is not immediately clear how to efficiently verify the parties’ computations. Notably, the protocol of Damgård and Jurik [23] circumvents this technicality by having a trusted party picking a secret \(d\equiv 1\bmod N\equiv 0\bmod \phi (N)\).

Our protocol offers a distributive decryption for Paillier with simulation-based security against malicious adversaries without randomness extraction. It is comprised of the following two subprotocols: First, the parties produce shares of a value d similarly to the Damgård–Jurik scheme [23]. This protocol is executed only once. Next, the parties run the distributed decryption algorithm using their shares. As mentioned earlier we use the simplified encryption function of Damgård and Jurik, i.e., use \(g=1+N\) as a generator of the subgroup of \(\mathbb {Z}_{N^2}^*\) of order N. Encryption of a plaintext m with randomness r is then,

$$\begin{aligned} \mathsf{Enc}_N(m, r) = (1+N)^m\cdot r^N\bmod N^2\text {.} \end{aligned}$$

5.1.1 Generating a Shared Paillier Decryption Key

We now present our protocol for generating a shared Paillier decryption key. As stated, similarly to Damgård and Jurik [23], we share a decryption exponent as follows

$$\begin{aligned} d \equiv \left\{ \begin{array}{l} 0\bmod \phi (N)\\ 1\bmod N \end{array}\right. \end{aligned}$$

However, since there are only two parties, a full threshold sharing is not necessary and we therefore use an additive sharing. Initially, we focus on the task at hand and present a protocol with semi-honest security (where the parties are assumed to follow the protocol’s description). This is then compiled into a protocol with full active security toward both parties by adding zero-knowledge proofs, ensuring that the parties cannot deviate.

Protocol 6

\([\mathsf{Dsk}]\) A distributed generation of a shared Paillier decryption key with passive security:

  • Inputs: A public RSA modulus \(N=pq\) with unknown factorization, additive shares of \(\phi (N)\): \(sk_0 = N-p_0 - q_0 +1\) and \(sk_1 = -p_1-q_1\) held by \(P_0\) and \(P_1\), respectively. A public ElGamal key (gh) with the secret key shared between the parties. A public Paillier key \(N_0\gg N^3\) with the secret key held by \(P_0\).

  • The protocol:

    1. 1.

      \(P_0\) encrypts \(sk_0\) using \(N_0\) and sends this to \(P_1\).

    2. 2.

      \(P_1\) picks \(r_1\in \mathbb {Z}{}_{N}^\star \) and \(r_\sigma \in \mathbb {Z}_{2^{\log {N}+\kappa }}\) uniformly at random (for a statistical parameter \(\kappa \) that enables to mask the secret key). \(P_1\) computes an encryption of

      $$\begin{aligned} (sk_0+sk_1)\cdot r_1+N\cdot r_\sigma \end{aligned}$$

      using the homomorphic property of Paillier encryption. This is rerandomized and sent to \(P_0\).

    3. 3.

      \(P_0\) decrypts, thus obtaining plaintext \({r}_0\); \(P_0\) computes \({r_0}^{-1} \bmod N\) and encrypts this as well as plaintext \(sk_0({r_0}^{-1} \bmod N)\) under public key \(N_0\). Both ciphertexts are sent to \(P_1\).

    4. 4.

      Based on the encryptions of \({r_0}^{-1} \bmod N\) and \(sk_0({r_0}^{-1} \bmod N)\), \(P_1\) computes an encryption of

      $$\begin{aligned} \begin{aligned} d&= \left( sk_0({r_0}^{-1} \bmod N)\cdot r_1 + ({r_0}^{-1} \bmod N)(sk_1\cdot r_1)\right) \\&= r_1(sk_0+sk_1)({r_0}^{-1} \bmod N)\\&= r_1\cdot \phi (N)\cdot ({r_0}^{-1} \bmod N). \end{aligned} \end{aligned}$$
      (1)

      \(P_1\) then picks \({\tilde{d}}_1\) uniformly at random in \(\mathbb {Z}_{2^{3\log N + \kappa }}\), and computes and rerandomizes an encryption of \(d+{\tilde{d}}_1\). This is sent to \(P_0\) and finally, \(P_1\) sets its share of d to the integer \(-{\tilde{d}}_1\).

    5. 5.

      \(P_0\) decrypts and obtains \(d_0\): its share of d.

Correctness.

Since no overflow modulo \(N_0\) occurs in Eq. (1), all calculations can be viewed to occur over the integers. Thus, since \(\phi (N)\) is a factor of d, clearly \(d\equiv 0\bmod \phi (N)\). Moreover, as \(r_0\equiv \phi (N)\cdot r_1\bmod N\) we also have \(d\equiv 1\bmod N\). Finally, as \(d = d_0+d_1\) over the integers, clearly we have an additive sharing of a value with the desired property.

Theorem 5.2

Assuming hardness of the DDH and DCR problems, Protocol 6 computes additive shares of a value d specified above in the presence of semi-honest adversaries.

Proof

The case follows by two corruption cases.

\(P_0\)is corrupted. We demonstrate how to generate a view statistically close to that of \(P_0\). During the protocol, \(P_0\) receives two messages: the encryptions of \(r_0\) and \(d_0\). As the encryptions have been rerandomized, they are indistinguishable from fresh encryptions of the plaintext values. Moreover, both of these are statistically close to uniformly random:

  • \(r_0\bmod N\) is uniformly random in \(\mathbb {Z}{}_{N}^*\) due to the multiplication by \(r_1\).

  • \(\lfloor r_0/N\rfloor \) is statistically close to a uniformly random \(\log N +\kappa \) bit integer.

  • \(d_0\) is statistically close to a uniformly random \(3\log N +\kappa \) bit integer.

Hence, to simulate, it suffices to pick and encrypt values distributed as the masks generated by \(P_1\).

\(P_1\)is corrupted. We cannot achieve unconditional security toward \(P_1\); however, a computationally indistinguishable view may be generated. During the protocol, the messages received by \(P_1\) consist of three Paillier encryptions under the key \(N_0\). Assuming that Paillier encryption is semantically secure, this is indistinguishable from three encryptions of 0. \(\square \)

We now demonstrate how to achieve security against malicious adversaries by adding zero-knowledge proofs to support correct behavior of each party.

Ensuring correctness of\({\textsc { P}}_0\). First, \(P_0\) must show that the plaintexts of the three encryptions sent in Steps 1 and 3 are as specified by the protocol. Demonstrating that the former encryption contains \(sk_0\) is equivalent to the same task as in the calculation of N (see Protocol 4). Indeed, \(P_0\) could simply reuse the encryption from that protocol. Similarly, demonstrating that the later encryption contains the product of the two first ones is simply obtained by an invocation of \(\pi _{\scriptscriptstyle \mathrm {MULT}}\).

The more challenging part is to have \(P_0\) demonstrate that the second plaintext is the modulo N inverse of the encrypted value received in Step 3. This requires \(P_0\) to send additional encryptions and execute zero-knowledge proofs based on the following:

  1. 1.

    \(P_0\) executes \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) on the encryption of \(r_0^{-1}\bmod N\), demonstrating that it is less than N.

  2. 2.

    \(P_0\) sends an encryption of \(r_0^\bot = r_0\bmod N\) under \(N_0\) and uses \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) to demonstrate that it is less than N.

  3. 3.

    \(P_0\) sends an encryption of \(r_0^\top = \lfloor r_0/N\rfloor \) under \(N_0\) and demonstrates that \(r_0^\bot +N\cdot r_0^\top \) equals \(r_0\), i.e., equals the plaintext of the encryption received from \(P_1\), using the zero-knowledge proof \(\pi _{\scriptscriptstyle \mathrm {ZERO}}\). (That is, the above boils down to proving that the division of two ciphertexts in an \(N_0\)th root.)

  4. 4.

    \(P_0\) sends an encryption of \(r_0^\bot \cdot (r_0^{-1}\bmod N)\) and demonstrates correct multiplication using \(\pi _{\scriptscriptstyle \mathrm {MULT}}\).

  5. 5.

    Both parties compute an encryption of \((r_0^\bot \cdot (r_0^{-1}\bmod N) -1)\cdot N^{-1}\); \(P_0\) executes \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) to show that the value is less than N.

Note that Steps 1, 2, and 3 demonstrate that \(r_0^\bot = r_0\bmod N\). Thus, it remains to demonstrate that the inversion modulo N has been performed properly. This must be the case, as the execution of \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) in Step 5 only succeeds if N divides \((r_0^\bot \cdot (r_0^{-1}\bmod N)-1)\). Namely, if the product is congruent to \(1\bmod N\). This completes the description of the modified role of \(P_0\).

Ensuring correctness of\({\textsc { P}}_1\). We continue with the description of \(P_1\). Security against malicious \(P_1\) follows similarly to the security against a malicious \(P_1\) during the computation of N. More specifically, \(P_1\) is required to prove the correctness of computation specified by the following linear equations \((sk_0+sk_1)\cdot r_1+N\cdot r_\sigma \) in step 2 and \(\left( sk_0({r_0}^{-1} \bmod N)\cdot r_1 + ({r_0}^{-1} \bmod N)(sk_1\cdot r_1)\right) \) in step 4, where the variables introduced by \(P_1\) are \(r_1\), \(r_\sigma \) and \(sk_1\). This is done as follows:

  • Proving honest behavior in step 2:

    1. 1.

      \(P_1\) encrypts \(r_1\) and \(r_\sigma \) using the distributed homomorphic ElGamal scheme and sends the ciphertexts to \(P_0\).

    2. 2.

      \(P_1\) is using \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) to prove knowledge of the values \((sk_1 \cdot r_1)\), \(r_1\) and \((N \cdot r_\sigma )\) and correct computation of the encryption of \((sk_0+sk_1)\cdot r_1+N\cdot r_\sigma = sk_0 \cdot r_1 + sk_1 \cdot r_1 + N\cdot r_\sigma \).

    3. 3.

      After \(P_0\) has decrypted \(r_0\), \(P_0\) and \(P_1\) re-execute the computation using the homomorphic ElGamal scheme, and using \(\pi _{\scriptscriptstyle \mathrm {MULT}}\) to prove correct multiplication. The result is decrypted to \(P_0\), which verifies whether the decryption of both schemes results in the same value \(r_0\). If this is the case \(P_1\) has been following the protocol honestly.

  • Proving honest behavior in step 4:

    1. 1.

      \(P_1\) starts by picking \({\tilde{d}}_1\) and encrypting it using the distributed homomorphic ElGamal scheme and sends the ciphertexts to \(P_0\) along with a proof of knowledge using \(\pi _{\scriptscriptstyle \mathrm {ENC}}\).

    2. 2.

      \(P_1\) is using \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) to prove knowledge of the values \((sk_1 \cdot r_1)\), \(r_1\) and \({\tilde{d}}_1\) and correct computation of the encryption of \(\left( sk_0({r_0}^{-1} \bmod N)\cdot r_1 + ({r_0}^{-1} \bmod N)\right. \left. (sk_1\cdot r_1)\right) + {\tilde{d}}_1\).

    3. 3.

      Again \(P_0\) and \(P_1\) re-execute the computation using the homomorphic ElGamal scheme, and using \(\pi _{\scriptscriptstyle \mathrm {MULT}}\) to prove correct multiplication. The result is decrypted to \(P_0\), which verifies whether the decryption of both schemes results in the same value \(d_0\). If this is the case \(P_1\) has been following the protocol honestly.

Since \(P_1\) does not explicitly prove consistency between the encryptions using the Paillier scheme and the ElGamal scheme we need to verify that a corrupted \(P_1\) cannot return encryptions giving the same result which are computed using different values. If that was possible, it would make simulating the security impossible. In step 2, it follows easily that if \(P_1\) is capable of returning a Paillier Encryption where different values of \((sk_1 \cdot r_1)\), \(r_1\) and \((N \cdot r_\alpha )\) are used compared to the ElGamal encryption and that the two computations give the same result, then \(P_1\) is able to compute \(sk_0\) from either the Paillier encryption or the ElGamal encryption, which is a contradiction. In step 4, if \(P_1\) is capable of returning a Paillier encryption and an ElGamal encryptions giving the same result, but using different values for \((sk_1 \cdot r_1)\), \(r_1\) and \({\tilde{d}}_1\), there are two cases, each described below. In the following we label the values used in the Paillier encryption as \((sk_1 \cdot r_1)'\), \(r_1'\) and \({\tilde{d}}_1'\):

  1. 1.

    \({\tilde{d}}_1 = {\tilde{d}}_1'\): In this case the corrupt \(P_1\) is capable of computing \(sk_0\) since: \(sk_0 = \frac{(sk_1 \cdot r_1) - (sk_1 \cdot r_1)'}{ (r_1' - r_1)}\). This is a contradiction since \(P_1\) has only seen encryptions of \(sk_0\). (Note, since \({\tilde{d}}_1 = {\tilde{d}}_1'\) then \(r_1' \ne r_1\)).

  2. 2.

    \({\tilde{d}}_1 \ne {\tilde{d}}_1'\): In this case \(P_1\) is able to compute a value \(\delta \) which is divisible by \(({r_0}^{-1} \bmod N)\). This is a contradiction since \(P_1\) has only seen semantically secure encryption (Paillier and ElGamal) of \(({r_0}^{-1} \bmod N)\). The value \(\delta \) is computed as:

    $$\begin{aligned} \delta = {\tilde{d}}_1 - {\tilde{d}}_1' = \left( sk_0 \cdot (r_1' - r_1) + (sk_1 \cdot r_1)'-(sk_1 \cdot r_1)\right) \cdot ({r_0}^{-1} \bmod N). \end{aligned}$$

5.1.2 Performing a Joint Paillier Decryption

To perform a joint decryption of some ciphertext c, both parties need to raise c to their share of the key, \(d_0\) or \(d_1\). They then demonstrate that this has been computed correctly using the commitments of the shares. The plaintext is immediately computable from \(c^{d_0}\) and \(c^{d_1}\).

Protocol 7

\([\mathsf{DDec}]\) A distributed Paillier decryption with a shared key:

  • Inputs: A public Paillier key \(N=pq\) with unknown factorization and a ciphertext \(c = E_N(m,r)\). Party \(P_i\) holds its share \(d_i\) of the secret decryption exponent, \(d = d_0 + d_1\) where \(d \equiv 1 \bmod N \wedge d\equiv 0\bmod \phi (N)\). Finally, the parties hold commitments to (or rather: ElGamal encryptions of) their key shares.

  • The protocol:

    1. 1.

      \(P_0\) sends \(c_0 = c^{sk_0}\bmod N^2\) to \(P_1\). Moreover, \(P_0\) demonstrates that this has been done correctly by executing \(\pi _{{\scriptscriptstyle \mathrm {EQ}}}\), i.e., that the committed number equals the discrete log of \(c_0\) with base c and the plaintext encrypted with ElGamal.

    2. 2.

      \(P_1\) sends \(c_1 = c^{sk_1}\bmod N^2\) to \(P_0\). Moreover, \(P_1\) demonstrates that this has been done correctly by executing \(\pi _{{\scriptscriptstyle \mathrm {EQ}}}\), i.e., that the committed number equals the discrete log of \(c_1\) with base c and the plaintext encrypted with ElGamal.

    3. 3.

      Finally, both parties compute the plaintext, \(m = ((c_0\cdot c_1)\bmod N^2 -1) / N\).

Theorem 5.3

Assuming that \(\pi _{{\scriptscriptstyle \mathrm {EQ}}}\) is a zero-knowledge proof of knowledge that correctly demonstrates equality of discrete logarithms, Protocol 7 determines the plaintext, m, of ciphertext c in the presence of malicious adversaries.

Proof

Simulation in a hybrid model with access to \(\mathcal{F}_{{\scriptscriptstyle \mathrm {EQ}}}\) is straightforward. Namely, from \(P_0\) viewpoint the only message received is \(c_1\), since the message of \(\pi {{\scriptscriptstyle \mathrm {DH}}}\) are handled by \(\mathcal{F}_{{\scriptscriptstyle \mathrm {EQ}}}\). This value may be computed deterministically given the plaintext by:

$$\begin{aligned} c_1\leftarrow (1+N)^m\bmod N^2 \cdot c^{-d_0}\bmod N^2. \end{aligned}$$

Clearly, this is the value sent by \(P_1\) during the protocol execution, as

$$\begin{aligned} c^{d_1} = c^{d-d_0} = c^d \cdot c^{-d_0} \equiv (1+N)^m \cdot c^{-d_0}\bmod N^2\text {.} \end{aligned}$$

That is, \(c_1\) can be computed using values known to the simulator. The case of corrupt \(P_1\) is equivalent. \(\square \)

6 The Efficiency of Our Protocols

In this section we discuss the efficiency of our protocols. We split our discussion into two parts: a theoretical analysis with a focus on the asymptotic complexity and optimizations that yield a more practical analysis.

6.1 The Number of Failed Attempts

First, the complexity of our protocol depends heavily on the number of failed attempts when generating the modulus. Recall that without running a trial division the protocol has to restart with two freshly generated prime candidates after every rejected composite, or otherwise the leaked information would make factoring an accepted composite easy. Specifically, without the trial division the expected number of tests is given by the probability of choosing two random primes simultaneously. This can be calculated by the prime number theorem, making the expected number of executions: \(\text {512 bit primes: }\left( {\ln (2^{512})}/{2}\right) ^2 \approx 31000, \text { 1024 bit primes: }\left( {\ln (2^{1024})}/{2}\right) ^2\approx 126000. \)

Nevertheless, this can be dramatically improved when employing the trial division test. Following the analysis of [5] it can be shown that the probability a generated candidate is a prime, given that it passes the trial division, is computed due to [19] and is as follows,

$$\begin{aligned} \Pr [p~\mathrm{is~prime}~|~p~\mathrm {passes~trial~division~with~threshold}~B]=2.57\cdot \frac{\ln B}{n}\left( 1+o\left( \frac{1}{n}\right) \right) \end{aligned}$$

which for \(\ln B = 9\) (i.e., \( B = 8103\)) and \(n = 1024\) is 1 / 44. This means that our protocol needs to test an expected number of 1936 candidates if \(n = 1024\). This shows how important the trial division is for the efficiency of our protocol, which is the first to incorporate this test securely in the two-party setting. Note that this analysis is independent of the construction used for generating the composite and strictly relies on the primes density in a given interval.

6.2 Theoretical Efficiency

We remark that all of our zero-knowledge proofs run in constant round and require constant number of exponentiations; the only exception is \(\pi _{\scriptscriptstyle \mathrm {EQ}}\), employed in our threshold decryption protocol, for which there is an amortized constant analysis due to Cramer and Damgård [10].

Key generation. Ignoring the initial key-setup, the complexity of a single RSA composite generation attempt (except for the biprimality test that is separately analyzed below), is dominated by the number of trial divisions; the rest of the secure computation requires only constant work and communication. Each of the trial divisions require only constantly many invocations of subprotocols, including \(\pi _{\scriptscriptstyle \mathrm {MOD}}\) (and hence of \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\)) and all these subprotocols require only a constant number of exponentiations. Thus, we conclude that the total costs that are incurred by the entire protocol are linear in the number of trial divisions. Further, all subprotocols at every step of the full protocol may be run in parallel; hence, round complexity is constant.

Biprimality test. The main part of the biprimality test consists of the verification of the secure exponentiation of the random \(\gamma \). Further, in the test of [5], the parties reach a negligible error probability by repeating the test \(\ell \) times—as the test has one-sided error with probability at most 1 / 2, it must be run, e.g., 40 times in order to achieve an error of \(2^{-40}\). The most expensive part of the test is the execution of \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) as it is a cut-and-choose protocol, i.e., we need \(O(\ell )\) exponentiations overall for each run, where \(\ell \) is some statistical security parameter. However, as noted above this may be brought down to amortized constant overhead using the techniques of Cramer and Damgård [10]. Further, as the all \(\ell \) tests may be run in parallel, round complexity is constant as well.

Secret key shares. The generation of the decryption key shares requires constant overhead and constant round complexity. The communication/computation complexity is dominated by the multiple invocations of \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) and \(\pi _{\scriptscriptstyle \mathrm {VERLIN}}\) which obtain negligible soundness with constant overhead. We note that this protocol is executed only once.

Threshold decryption. This protocol is dominated by the invocation of \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) which requires constant number of exponentiations for long enough challenge (see more discussion about this proof in Sect. 3.2, Item 5). For batch decryption the technique of Cramer and Damgård [10] can be used here as well.

6.3 Practical Considerations

To ease the security proof, we have taken a pessimistic approach above. Namely, zero-knowledge proofs have been applied at all stages in order to catch cheating players at once. However, a more optimistic approach allows for a more efficient protocol: All but one of our RSA composite generation attempts fail, and most of the zero-knowledge proofs are only needed for the successful modulus generation—hence they may be postponed. In addition to this, further optimizations for distributed RSA key generation are possible. We refer to Boneh and Franklin [5] for a list of general optimizations some of which are also applicable in our setting.

For the failing RSA composite generation attempts, we utilize the fact that the encryptions provided can be viewed as binding commitments. On failure, the parties reveal all random choices, thereby allowing the other party to verify their correct behavior by “executing” the protocol “in their head” and checking the correctness of the other party’s messages, e.g., that plaintexts are appropriately bounded. Thus, overall efficiency of the many failing attempts will not be much more costly than twice that of failing attempts for the passively secure protocol. Once an attempt succeeds, ZK proofs are used to ensure that this was correct. Slightly more formally, the key idea is that the simulator must know that the adversary is cheating (and that an honest party would detect this later, i.e., that the invocation should fail). We cannot simply postpone all proofs; care must be taken to allow simulation and to not reveal information that would allow a malicious party to, e.g., fake some zero-knowledge proof at a later point.

Generating the prime candidate. We may omit the invocations of \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) on \(p_i\) and \(q_i\), as this statement is implicitly shown by the invocations of \(\pi _{\scriptscriptstyle \mathrm {MOD}}\) in the trial divisions. Further, verification may be postponed until we believe we have successfully generated an RSA modulus; we cannot ensure correctness underway, but the encryption will be the same; thus, we still accept or reject as if we had run \(\pi _{\scriptscriptstyle \mathrm {BOUND}}\) immediately.

Trial division. We may postpone the invocations of \(\pi _{\scriptscriptstyle \mathrm {MOD}}\) at the cost of a few extra executions of simple proofs of knowledge, such as \(\pi _{\scriptscriptstyle \mathrm {ENC}}\). This ensures that the party knows its input, and that the simulator knows whether a later invocation of \(\pi _{\scriptscriptstyle \mathrm {MOD}}\) may be successful (as it knows both what the input should be and what it actually is). If a trial division fails incorrectly, the honest party learns this when the corrupt party reveals its random choice, including its share of the random prime and the reduction modulo the trial division prime. If a trial division succeeds incorrectly, this can be discovered easily by performing the same trial division on N—indeed at this point we may use a larger bound for the trial division as this can be performed very efficiently on the public N. The only remaining possibility is the case where the test should succeed, and did so despite one party providing an incorrect input. This case is handled by executing \(\pi _{\scriptscriptstyle \mathrm {MOD}}\) for each trial division once the biprimality test succeeds, at which point the honest party will detect the incorrect behavior.

Computing and verifying the product. For the Paillier computation, we may postpone all checks except the proof that \({\tilde{N}}\) was the plaintext of the encryption supplied by \(P_1\). Privacy of \(P_0\) follows from the security of Paillier encryption, while privacy for \(P_1\) follows from the fact the encryption sent back by \(P_1\) only contains the desired result. Leakage from constructing a potentially incorrect value is eliminated by the eventual execution of the full zero-knowledge proofs. Alternatively, we may avoid verifying the product altogether. This may leak a single bit of information, namely whether some function on the shares of the honest party equals the still hidden modulus, N. Depending on the setting, this leakage may or may not be acceptable.

Biprimality test. The invocation of \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) can be postponed. If the test fails, the parties simply reveal their shares of the candidates; both parties may then verify that the other performed the exponentiations correctly. On the other hand, if the test succeeds, the parties have either determined an RSA composite or one of them has cheated. They now execute \(\pi _{\scriptscriptstyle \mathrm {EQ}}\) to determine which of the two is the case. Since the simulator knows the shares of the corrupt party, it is straightforward for it to check if the value supplied is the correct one.

7 Experimental Results

In this section we present an implementation of Protocol 4 with security against semi-honest adversaries. Our primary goal is to examine the overall time it takes to generate an RSA composite of length 2048 bits in case the parties do not deviate, and identify bottlenecks. The bulk of our implementation work is related to reducing the computational overhead of the trial division which is the most costly phase. To improve the overhead relative to the ElGamal PKE, we implement this scheme on elliptic curves using the MIRACL library [51] and use the elliptic curve P-192 [52] based on Ecrypt II yearly report [29]; see [53, 61] for more practical information. The modulus p and the order n of this curve are given in the decimal form where \(p = 6277101735386680763835789423207666416083908700390324961279\) and \(n = 6277101735386680763835789423176059013767194773182842284081\). A brief background on elliptic curves in found in Sect. 7.1.1. We further consider two optimizations detailed below.

Fig. 3
figure 3

Probability plot with \(n = 2048\)

7.1 Trial Division Implementation

As pointed out in Sect. 6.1, the trial division approach dramatically improves the complexity of the overall key generation process. Viewing the plot from Fig. 3 (that expresses the classic result of DeBruijn [19], analyzing the probability that a candidate integer is a prime given that it passes the trial division), one can easily observe the probability growth rate for finding a prime p while using larger thresholds. Specifically, for larger thresholds the number of comparisons increases, as the interval now covers more primes. Thus, the overall protocol is slowed down. In Sect. 7.2 we study some candidates for this threshold.

We further note that while implementing our protocols we noticed that more than 80% of the computational time is spent on the decryption process. This operation is required in Step 2b of Protocol 4 to test whether either \(c^{(\alpha )}\) or \({\tilde{c}}^{(\alpha )}\) encrypt zero, for \(\alpha \) a prime smaller than the trial division threshold B (namely, decryption is required at the end of each internal trial division check). Our implementations show that running the trial division in its naive form takes several hours. We therefore design two optimizations that reduce the running time of our protocol. It is straightforward to verify that the security of our protocol is not harmed by these modifications and we thus omit the security proofs. We begin with a short introduction on elliptic curve cryptography.

7.1.1 Background on Elliptic Curve Cryptography

In order to improve our performance, we implement the ElGamal PKE over the group of points on an elliptic curve defined over a finite field. For an elementary introduction the reader is referred to [46, 47] and for [63, 64] for additional treatment. In the following we introduce some basics notations regarding elliptic curves; for simplicity we only introduce the case where the elliptic curve is defined over the real numbers \({\mathbb {R}}\).

Definition 7.1

An elliptic curve over \({\mathbb {R}}\) is the set of points \(x, y \in {\mathbb {R}}\) which satisfy the equation

$$\begin{aligned} y^2 = x^3 + ax + b . \end{aligned}$$

The set of points on an elliptic curve form an Abelian group. Moreover, the elliptic curve analogy of multiplying two elements in \({\mathbb G}\) is adding two points on \({\mathbb {E}}\), where \({\mathbb {E}}\) is an elliptic curve defined over \({\mathbb G}\). Thus, the analog of raising an element in \({\mathbb G}\) to the kth power is a multiplication of a point \(P \in {\mathbb {E}}\) by an integer k. We now recall the ElGamal PKE over elliptic curves.

Distributed key generation protocol:

  1. 1.

    The parties agree on an elliptic curve E and a generator G.

  2. 2.

    Party \(P_0\) chooses a random secret key \(x_{P_0}\) and sends \(P_1\) the value \(Q_{P_0} = {x_{P_0}}G\).

  3. 3.

    Party \(P_1\) chooses a random secret key \(x_{P_1}\) and sends \(P_0\) the value \(Q_{P_1} = {x_{P_1}}G\).

  4. 4.

    The parties compute the shared key \(Q = Q_{P_0} + Q_{P_1}\).

Encryption: Let \(m \in \mathbb {G}\) be a message and let \({\mathbb {E}}\) be the set of points over the curve E. Then m must be mapped to a point in \({\mathbb {E}}\) before encrypted because addition over an elliptic curve is only possible with points on that curve. Thus, integers have to be mapped to corresponding points through a mapping function \(h : {\mathbb G}\rightarrow {\mathbb {E}}\). Moreover, this mapping should be homomorphic in the sense,

$$\begin{aligned} \displaystyle h(m_1 + m_2 + \cdots + m_n) = h(m_1) + h(m_2) + \cdots + h(m_n). \end{aligned}$$

Thus, each integer \(m \in {\mathbb G}\) is mapped to a curve point \(M \in {\mathbb {E}}\) by computing \(M = h(m) = mG\). This mapping function meets the required homomorphic property as,

$$\begin{aligned} \displaystyle M_1 + M_2 + \cdots + M_n= & {} h(m_1 + m_2 + \cdots + m_n) = (m_1 + m_2 + \cdots + m_n)G\\= & {} m_1G + m_2G + \cdots + m_nG. \end{aligned}$$

Let q be the order of the group of points on the curve E, and let r be picked uniformly at random in \(\mathbb {Z}_q\), then encrypting the point M is computed as follows:

$$\begin{aligned} \displaystyle (C_1, C_2) = (rG, M + rQ) \end{aligned}$$

Distributed decryption protocol:

  1. 1.

    The parties wish to decrypt ciphertext \(C = (C_1, C_2)\).

  2. 2.

    Party \(P_0\) computes the secret share \(D_0 = x_{P_0}C_1\) and sends it to party \(P_1\).

  3. 3.

    Party \(P_1\) computes the secret share \(D_1 = x_{P_1}C_1\) and sends it to party \(P_0\).

  4. 4.

    The parties compute the plaintext point \(M = C_2 - D_1 - D_2\).

7.1.2 Optimization I: The BatchedDec Protocol

One way to improve the trial division performance is by reducing the number of decryption operations. The idea is quite simple, the parties do not decrypt \(c^{(\alpha )}\) and \({\tilde{c}}^{(\alpha )}\) after each trial division iteration, but instead they maintain a state S for each T iterations specified by a pair of ciphertexts \((C_f, \tilde{C_f})\). These ciphertexts encrypt the multiplication of the respective T values encrypted within \(c^{(\alpha )}\)’s and \({\tilde{c}}^{(\alpha )}\)’s throughout the T iterations. More specifically, at the beginning of the first iteration the parties set \(C_f = c^{(\alpha )}\) and \(\tilde{C_f} = {\tilde{c}}^{(\alpha )}\). Recalling that \(p_0\) and \(p_1\) are the respective shares of a prime p, picked by \(P_0\) and \(P_1\), then for each iteration i the parties update \(C_f\) as follows (the update of \({{\tilde{C}}}_f\) is computed similarly):

  1. 1.

    Party \(P_0\) selects a random value \(r'_i\) and computes \(R'_i = r'_iG\) and \(K'_i = r'_iQ\), where Q is the public key.

  2. 2.

    \(P_0\) computes \({V_{P_0}}_i = (p_0\bmod \alpha _i){C_f}_{i-1}\). Let \({V_{P_0}}_i = (C_1, C_2)\), then \(P_0\) computes \({H_{P_0}}_i = (C_1 + R'_i, C_2 + K'_i)\) and sends \({H_{P_0}}_i\) to \(P_1\).

  3. 3.

    \(P_1\) computes \({H_{P_1}}_i\) similarly, selecting a random value \(r''\) and using \(p_1\bmod \alpha _i\). \(P_1\) sends \({H_{P_1}}_i\) to \(P_0\).

  4. 4.

    The parties compute \(H = H_{P_0} + H_{P_1}\) and set \(C_f = H\).

Finally, at the Tth iteration the parties decrypt and check whether one of the two ciphertexts is an encryption of zero. Based on the homomorphic properties of our PKE, it holds that either \({C_f}\) or \({\tilde{C}}_f\) are the encryption of 0 if at least one of the \(\alpha \)’s tested during one of the T iterations divided the parties’ candidate. This approach enables to perform the decryption operation only once every T iterations. Clearly, if T is too small the software does not get a big performance improvement. On the other hand, when T is too big the software will have to perform too many rounds before discovering that much of the work is useless. After some empirical studies we observed that \(T = 100\) is a good threshold candidate.

Correctness (informally). We begin from the first iteration of the new trial division protocol. For simplicity, we only address the second iteration. The general case easily generalizes.

  • First iteration: Let \(\alpha _1\) be the prime checked during the first iteration, then the parties initialize the status \(S = ({C_f}_1, {\tilde{C}}_{f_1})\) as follows: \(S = ({C_f}_1, {\tilde{C}}_{f_1}) = (c^{(\alpha _1)}, {\tilde{c}}^{(\alpha _1)})\) Where:

    $$\begin{aligned} c^{(\alpha _1)}= & {} \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}\left( p_0\bmod \alpha _1 + p_1\bmod \alpha _1\right) \\= & {} \left( r_1G, r_1Q + (p_0\bmod \alpha _1 + p_1\bmod \alpha _1)G\right) . \end{aligned}$$

    and

    $$\begin{aligned} {\tilde{c}}^{(\alpha _1)}= & {} \mathsf{Enc}_{pk_{\scriptscriptstyle \mathrm {EG}}}\left( p_0\bmod \alpha _1 + p_1\bmod \alpha _1 - \alpha _1\right) \\= & {} \left( r_{{\tilde{c}}}G, r_{{\tilde{c}}}Q + (p_0\bmod \alpha _1 + p_1\bmod \alpha _1 - \alpha _1)G\right) . \end{aligned}$$
  • Second iteration: Using the above notations, and keeping in mind that \({V_{P_0}}_2 = (v_1,v_2)\), \(P_0\) computes

    $$\begin{aligned} {H_{P_0}}_2 = (v_1 + R'_2, v_2 + K'_2)\end{aligned}$$

    and sends it to \(P_1\). Thus, remembering that \({C_f}_1 = (c_1, c_2)\) we have:

    $$\begin{aligned} {H_{P_0}}_2= & {} \left( (p_0\bmod \alpha _2)c_1 + R'_2, (p_0\bmod \alpha _2)c_2 + K'_2\right) \\= & {} \left( (p_0\bmod \alpha _2)r_1G \right. \\&\left. +\, r'_2G, (p_0\bmod \alpha _2)(r_1Q + (p_0\bmod \alpha _1 + p_1\bmod \alpha _1)G + r'_2Q)\right) \\= & {} \left( ((p_0\bmod \alpha _2)r_1 \right. \\&\left. +\, r'_2)G, ((p_0\bmod \alpha _2)r_1 + r'_2)Q + \right. \\&\left. (p_0\bmod \alpha _2)(p_0\bmod \alpha _1 + p_1\bmod \alpha _1)G\right) . \end{aligned}$$

    In addition, party \(P_1\) computes,

    $$\begin{aligned} {{H_{P_1}}_2}= & {} \left( ((p_1\bmod \alpha _2)r_1 + r''_2)G, ((p_1\bmod \alpha _2)r_1 \right. \\&\left. +\, r''_2)Q + (p_1\bmod \alpha _2)(p_0\bmod \alpha _1 + p_1\bmod \alpha _1)G\right) . \end{aligned}$$

    The parties then exchange \({H_{P_0}}_2\) and \({H_{P_1}}_2\) and compute \({C_f}_2 = {H_{P_0}}_2 + {H_{P_1}}_2\). It is now trivial to see that if \({C_f}_2\) is an encryption of 0 then \(\alpha _1\), \(\alpha _2\) or both divide the candidate. The demonstration is analogous for \({{\tilde{C}}}_{f_2}\). This optimization enables to maintain the same level of security while improving performance. Indeed, looking at Table 2 the expected running time of the parties drops into 47 min.

7.1.3 Optimization II: The LocalTrialDiv Protocol

In this section we take a different approach and instruct the parties to “abort” the distributed trial division after a number of checks, continue with the computation of the composite candidate, and only then complete the trial division test on their own (i.e., without communication). More specifically,

  1. 1.

    For the first X rounds the parties run the trial division as explained in the previous section.

  2. 2.

    The parties then quit the trial division loop and compute Step 3a of Protocol 4, computing \({\tilde{N}}\).

  3. 3.

    The parties then locally complete the trial division for \({\tilde{N}}\) until the threshold B is reached. Namely, by checking whether \(\alpha | {\tilde{N}}\) or not.

Notably, it has been observed that most of the candidates are rejected at very early stages of the trial division, namely before \(\alpha \) turns to be higher than 31. The main advantage of this solution is that it enables to avoid the usage of cryptographic routines for \(\alpha \)’s greater than X. This optimization, denoted by LocalTrialDiv, improves the trial division performance even further; our experimental results are depicted in Table 3. In our experiments we fix X to be 11.

7.2 Performance Results

In order to illustrate the efficiency of our protocols, we created a benchmark program that simulates the behavior of the parties in three different cases: (1) the original protocol, (2) the LocalTrialDiv protocol, and (3) the BatchedDec protocol. In this section we present the performance measures we have observed during our experiments. These measurements have been computed by running the programs over an Intel Core i5 dual core 2.3 GHz, with 256 KB for L2 cache per core, 3 MB for L3 cache, and 8 GB of Ram.

7.2.1 Performance Analysis of the Original Protocol

In order to estimate the resources needed to output a legal RSA composite following the original protocol, we let the parties run 10 trial division tests and calculate the average time the parties spent on a single test. This value is then multiplied by the overall expected number of iterations of the trial division (specified by the DeBruijn formula; see Fig. 3). Observing the results presented in Table 1, one can see that the expected running time is about 3 h already for a relatively small threshold value. In the following sections we present the performance measurements of our two optimized protocols.

Table 1 Experimental results for the original protocol

7.2.2 Performance Analysis of the BatchedDec Protocol

In Table 2 we present our performance analysis of protocol BatchedDec. Each row reports the duration (in minutes) of a complete execution for different selected values of B. We take into account the set of all operations performed by the parties during BatchedDec protocol, i.e., from the initialization phase of the libraries and the key generation steps, to the actual output of the RSA composite. We report the average time it takes to generate a valid composite, as well as the average number of iterations required throughout the entire computation, until a valid RSA composite is output.

Observing this data, the reader can see that the theoretical results reported in the previous sections are partly confirmed. Indeed, the cost of the trial division decreases along with the threshold values for B, yet the number of rounds increases. Using \(B = 1129\) the parties need more CPU time on the average than for threshold \(B = 3181\). This is because the improvement due to using a decreased value of B cannot “compete” with the resources needed to perform the increased number of rounds. Indeed, the former threshold doubles the expected number of rounds. Moreover, increasing the threshold value even further does not improve the performance.

Table 2 Experimental results for the BatchedDec protocol

7.2.3 Performance Analysis of the LocalTrialDiv Protocol

Finally, given the results from Table 3, one can observe that a similar scenario described with respect to Protocol LocalTrialDiv as well. Indeed, setting \(B = 8117\), the average CPU time required in order to compute an RSA composite is 37 min. Increasing the value of B into 15973 makes the CPU time drop into 15 min on the average, yet increasing B even more increases the CPU time beyond that. It can be seen that the values chosen for B are a bit higher than the values chosen for the previous approach; this is because this method is much faster. Thus, the parties are able to handle more trial divisions per round before executing a biprimality test.

Table 3 Experimental results for the LocalTrialDiv protocol