Keywords

1 Introduction

1.1 Background

In the setting of secure multiparty computation, a set of mutually distrusting parties wish to jointly and securely compute a function of their inputs. This computation should be such that each party receives its correct output, and none of the parties learn anything beyond their prescribed output. The standard definition today [14, 26] formalizes the above requirements (and others) in the following general way. Consider an ideal world in which an external trusted party is willing to help the parties carry out their computation. An ideal computation takes place in this ideal world by having the parties simply send their inputs to the trusted party, who then computes the desired function and passes each party its prescribed output. The security of a real protocol is established by comparing the outcome of the protocol to the outcome of an ideal computation. Specifically, a real protocol that is run by the parties is secure, if an adversary controlling a coalition of corrupted parties can do no more harm in a real execution than in the ideal execution.

One of the most important parameters for designing a protocol is the communication model. In the synchronous communication model, messages that are sent are guaranteed to be delivered within a known and finite time frame. As a result, the computation can proceed in rounds, such that if a party failed to receive a particular message in some round, within the expected time frame, the receiver knows that the sender did not transmit the message. Impressive feasibility results are known in this model [8, 17, 27, 38], stating that every functionality can be securely computed, assuming that a majority of the parties are honest. Furthermore, under suitable cryptographic assumptions, the computation can be done using constant-round protocols [2, 4, 24, 28, 31, 33].

The asynchronous model of communication is arguably more appropriate for modeling the real world. In this model the adversary has a stronger control over the communication channels and can impose an arbitrary unbounded (yet finite) delay on the arrival of each message. In particular, an honest party cannot distinguish between a corrupted party that refuses to send messages and an honest party whose messages are delayed.

This inherent limitation was taken into account by Ben-Or et al. [9] by adjusting the ideal-world computation. Since messages from t parties might never be delivered during the execution of the protocol, the trusted party cannot compute the function on all inputs. Therefore, the ideal-world adversary gets to decide on a core set of \(n-t\) input providers (t of which might be corrupted) and the trusted party computes the function on their inputs (and default values for the rest). Next, the trusted party sends to each party the output of the computation along with the identities of the parties in the core set. It immediately follows that a secure protocol implies agreement in the asynchronous setting, since the core set must be agreed upon as part of the protocol, and therefore is feasible in the standard model if and only if \(t<n/ 3\) [9, 10]. Asynchronous protocols that are secure assuming \(t<n/ 2\) are only known in weaker models that assume either a synchronous broadcast round [6] or some form of non-equivocation [3]. Moreover, the running-timeFootnote 1 of all currently known asynchronous protocols depends on the function to be computed and no constant-time protocols were known.

In this work we study the following question.

Do there exist asynchronous secure multiparty protocols which run in constant time?

1.2 Our Result

Our main result is a feasibility result of an asynchronous secure multiparty protocol that runs in constant time in a hybrid model where the parties have access to an ideal asynchronous Byzantine agreement (ABA) functionality.

The main tools that we use are threshold fully homomorphic encryption (TFHE) and threshold signatures (TSIG). A fully homomorphic encryption scheme (FHE) is an encryption scheme that enables an evaluation of a function over a tuple of ciphertexts to obtain an encrypted result. TFHE is essentially a distributed version of FHE, where the decryption key is secret shared amongst the parties. In order to decrypt a ciphertext, each party locally uses its share of the decryption key and computes a share of the plaintext. The plaintext can then be reconstructed given \(t+1\) decryption shares. Similarly, in a threshold signature scheme, the signing key is secret shared and \(t+1\) shares are required in order to sign a message. We note that both of these computational assumption can be based on the standard learning with errors (LWE) problem, see Asharov et al. [2], Bendlin and Damgård [11] and Bendlin et al. [12].

Theorem 1

(informal). Assume that TFHE and TSIG schemes exist, and that the cryptographic keys have been pre-distributed. Then any efficiently computable function f can be securely computed in the asynchronous setting facing static malicious adversaries, assuming an honest majority and given access to an ABA ideal functionality. The time complexity of the protocol is O(1), the communication complexity is independent of the multiplication-depth of the circuit representing f and the number of (concurrent) invocations of the ABA ideal functionality is \(n\).

Using the concurrent ABA protocol of Ben-Or and El-Yaniv [7], which runs in constant expected timeFootnote 2 and is resilient for \(t<n/ 3\), we obtain the following corollary.

Corollary 1

(informal). Assume that TFHE and TSIG schemes exist, then any function can be securely computed in the asynchronous setting using a constant expected time protocol, in the presence of static malicious adversaries, for \(t<n/ 3\).

1.3 Overview of the Protocol

The basis of our technique is the protocol of Cramer et al. [20] (designed for the synchronous setting), which is based on threshold additively homomorphic encryption (TAHE)Footnote 3 and is designed in a hybrid model where the encryption keys are pre-distributed before the protocol begins. Initially, each party encrypts its input and broadcasts the ciphertext. Next, the circuit is homomorphically evaluated, where addition gates are computed locally and multiplication gates are computed interactively. Finally, a threshold decryption protocol is executed, and the parties learn the output.

Hirt et al. [29, 30] adopted the protocol of [20] into the asynchronous setting by introducing the king-slaves paradigm. Initially, each party sends its encrypted input to all the parties, and the core set is decided upon using an agreement on a common subset (ACS) protocol, which incorporates \(n\) instances of ABA. Next, \(n\) copies of the circuit are interactively evaluated. In each evaluation one of the parties acts as king while all other parties act as slaves. The role of the slaves is to help the king with the computation of multiplication gates. At the end of each such evaluation, the slaves send their decryption shares to the king which recovers the output. The evaluations of the circuit are executed asynchronously, i.e., one king may finish its computation while another king hasn’t started yet, therefore each party must hold a state for each evaluation of the circuit.

The time complexity of the protocols of Hirt et al. [29, 30] depends on the depth of the circuit to compute. In this work, we use a TFHE instead of TAHE in order to reduce the running time. This adjustment not only yields better time complexity and better communication complexity, but also enables a design without the expensive king-slave paradigm, since each party can locally and non-interactively evaluate the entire circuit. As a consequence, the description of the new protocol is greatly simplified, and also results with a better memory complexity compared to [29, 30], since the parties do not need to store a local state for each of the \(n\) evaluations of the circuit.

Our protocol consists of three stages. The input stage, in which the core set of input providers is determined, follows in the lines of Hirt et al. [29, 30]. In the computation and threshold decryption stage, each party homomorphically evaluates the circuit non-interactively and obtains an encrypted output \(\tilde{c}\). Next, the party uses its share of the decryption key to compute a decryption share and send it to all other parties. Once a party receives \(t+1\) valid decryption shares it can recover the output. During these stages, the validity of each message sent by some party must be proven. This is done by running a sub-protocol which produces a certificate for the message (which is essentially a signature produced by \(n-t\) parties). Therefore, a party must remain active and assist in constructions of certificates even after it obtained its output. The termination stage ensures a safe termination of all the parties and follows Bracha [13]. Once a party obtained its output it sends it to all other parties. When a party receives \(t+1\) consisting values it can safely set its output to this value (even if it did not complete the computation and threshold decryption stage) and once receiving outputs from \(n-t\) parties, terminate.

1.4 Additional Related Work

Ben-Or et al. [9] were the first to define asynchronous secure multiparty computation. They constructed a BGW-alike [8] asynchronous protocol that is secure in the presence of malicious adversaries when \(t<n/ 4\); the authors showed that this threshold is tight when considering perfect correctness. Ben-Or et al. [10] constructed a protocol with statistical correctness that is secure in the presence of malicious adversaries, for \(t<n/ 3\). This threshold is also tight following the lower bound of Toueg [41], stating that asynchronous Byzantine agreement is impossible if \(t\ge n/ 3\), even in the PKI model.

Following the feasibility results of [9, 10] great improvements have been made regarding the communication complexity. Two main approaches have been used, the first is in the information-theoretic model and does not rely on cryptographic assumptions [5, 19, 35–37, 40] while the second is in the computational model and is based on threshold additively homomorphic encryption, these protocols appear in [18, 29, 30] and rely on a preprocessing phase for key distribution.

In order to achieve security for an honest majority, the model must be weakened in some sense. Beerliová-Trubíniová et al. [6] allowed a limited usage of synchronous Byzantine agreement and adjusted the protocol from [30] to the case where \(t < n/ 2\). Backes et al. [3] augmented the model with a non-equivocation oracle, and constructed a protocol that is secure assuming an honest majority.

In an independent work, Choudhury and Patra [18] suggested using TFHE in order to reduce the time complexity, but did not proceed in this route since they considered concrete efficiency. We note that in this work we focus on feasibility results rather than concrete efficiency of the protocols.

A comparison of the asynchronous MPC protocols appears in Table 1.

Table 1. Comparison of asynchronous MPC protocols.
Full size table

Paper Organization

The cryptographic primitives are defined in Sect. 2 and followed by the description of the UC security model in Sect. 3. Certificates are defined in Sect. 4 and then in Sect. 5 we present our asynchronous MPC protocol. The security proof is given in Sect. 6.

2 Preliminaries

In this section we present the definitions of the cryptographic schemes that are used in our protocol.

2.1 Threshold Fully Homomorphic Encryption

Definition 1

A homomorphic encryption (HE) scheme consists of 4 PPT algorithms:

  • Key generation: \((dk,ek) \leftarrow {\text {Gen}}(1^\kappa )\); outputs a pair of keys: the secret decryption key dk and the public encryption (and evaluation) key ek.

  • Encryption: \(c \leftarrow {\text {Enc}}_{ek}(m)\); using ek, encrypt a plaintext m into a ciphertext c.

  • Decryption: \(m = {\text {Dec}}_{dk}(c)\); using dk, decrypt the ciphertext c to into a plaintext m.

  • Homomorphic evaluation: \(c ={\text {Eval}}_{ek}(C, c_1, \ldots , c_\ell )\); using ek, evaluate a circuit C over a tuple of ciphertexts \((c_1, \ldots , c_\ell )\) to produce a ciphertext c.

We say that a HE scheme is correct for circuits in a circuit class \(\mathcal{C}\) if for every \(C\in \mathcal{C}\) and every series of inputs \(m_1, \ldots , m_\ell \in \{0,1\}^*\) it holds that

$$ {\mathrm {Pr}}\left[ {\text {Dec}}_{dk}\left( {\text {Eval}}_{ek}\left( C, {\text {Enc}}_{ek}(m_1), \ldots , {\text {Enc}}_{ek}(m_\ell )\right) \right) \ne C\left( m_1, \ldots , m_\ell \right) \right] \le {\text {negl}}(\kappa ). $$

Semantic security of HE schemes is defined in the standard way, see [25].

Definition 2

A family of HE schemes \(\{\varPi ^{(d)} = ({\text {Gen}}^{(d)}, {\text {Enc}}^{(d)}, {\text {Dec}}, {\text {Eval}}^{(d)}) \mid d\in {\mathbb {N}}^+\}\) is leveled fully homomorphic if for every \(d\in {\mathbb {N}}^+\), the following holds:

  • Correctness: \(\varPi ^{(d)}\) correctly evaluates the set of all boolean circuits of depth at most d.

  • Compactness: There exists a polynomial s such that the common decryption algorithm can be expressed as a circuit of size at most \(s(\kappa )\) and is independent of d.

In our protocol for computing a function f, the depth d of the circuit C representing f is known in advance. We remove the notation (d) from the schemes throughout the paper for clarity. We also require the FHE scheme to have a threshold decryption, informally this means that \({\text {Gen}}\) generates the public key ek as well as a \(t_e\)-secret sharing of the secret key \((dk_1, \ldots , dk_n)\), such that decrypting c using \(dk_i\) produces a share \(m_i\) of the plaintext m. We will use \(t_e=t+1\).

Definition 3

A threshold homomorphic encryption scheme is a homomorphic encryption scheme augmented with the following properties:

  • The key generation algorithm is parameterized by \((t_e,n)\) and outputs \((dk,ek) \leftarrow {\text {Gen}}_{(t_e,n)}(1^\kappa )\), where dk is represented using a \((t_e,n)\)-threshold secret sharing of the secret key \((dk_1, \ldots , dk_n)\).

  • Given a ciphertext c and a share of the secret key \(dk_i\), the share-decryption algorithm outputs \(d_i={\text {DecShare}}_{dk_i}(c)\) such that \((d_1, \ldots , d_n)\) forms a \((t_e,n)\)-threshold secret sharing of the plaintext \(m={\text {Dec}}_{dk}(c)\). We denote the reconstruction algorithm that receives \(t_e\) decryption shares \(\{d_i\}\) by \(m={\text {DecRecon}}(\{d_i\})\).

2.2 Threshold Signatures

A threshold signature scheme is a signature scheme in which the signing key is shared amongst \(n\) parties using a \(t_s\)-threshold secret-sharing scheme. Using \(t_s\) shares of the signing key it is possible to sign on any message, however using less than \(t_s\) shares it is infeasible to forge a signature. We will use \(t_s=n-t\).

Definition 4

(Threshold Signature Scheme). A threshold signature scheme is a signature scheme \(({\text {SigGen}}, {\text {Sign}}, {\text {Vrfy}})\) augmented with the following properties

  • The signature key generation algorithm is parameterized by \((t_s,n)\) and outputs \((sk,vk) \leftarrow {\text {SigGen}}_{(t_s,n)}(1^\kappa )\), where sk is represented using a \((t_s,n)\)-threshold secret sharing of the secret signing key \((sk_1, \ldots , sk_n)\).

  • Given a plaintext m and a share of the secret key \(sk_i\), the share-signing algorithm outputs \(\sigma _i\leftarrow {\text {SignShare}}_{sk_i}(m)\) such that \((\sigma _1, \ldots , \sigma _n)\) forms a \((t_s,n)\)-threshold secret sharing of the signature \(\sigma \leftarrow {\text {Sign}}_{sk}(m)\).

For a security definition of threshold signatures see, for example, [1].

3 The Security Model

3.1 The UC Framework

In this section we present a high-level description of the security model. We follow the UC framework of Canetti [14], which is based on the real/ideal paradigm, i.e., comparing what an adversary can do in the real execution of the protocol to what it can do in an ideal model where an uncorrupted trusted party (an ideal functionality) assists the parties. Informally, a protocol is secure if whatever an adversary can do in the real protocol (where no trusted party exists) can be done in the ideal computation.

The Real World. An execution of a protocol \(\pi \) in the real model consists of n interactive Turing machines (ITMs) \(P_1,\ldots ,P_n\) representing the parties, along with two additional ITMs, an adversary \(\mathcal A\), describing the behavior of the corrupted parties and an environment \(\mathcal Z\), representing the external environment in which the protocol operates. The environment gives inputs to the honest parties, receives their outputs, and can communicate with the adversary at any point during the execution. The adversary controls the operations of the corrupted parties and the delivery of messages between the parties.

In more details, each ITM is initialized with the security parameter \(\kappa \) and random coins, where the environment may receive an additional auxiliary input. We consider static corruptions, meaning that the set of corrupted parties is fixed before the protocol begins and is known to \(\mathcal A\) and \(\mathcal Z\). The protocol proceeds by a sequence of activations, where the environment is activated first and at each point a single ITM is active. The environment can either activate one of the parties with input or activate the adversary by sending it a message. Once a party is activated it can perform a local computation, write on its output tape or send messages to other parties. After the party completes its operations the control is returned to the environment. Once the adversary is activated it can send messages on behalf of the corrupted parties or send a message to the environment. In addition, \(\mathcal A\) controls the communication between the parties, and so it can read the content of the messages sent between the parties and is responsible for delivering each message to its recipient. Once \(\mathcal A\) delivers a message to some party, this party is activated. We assume that the adversary cannot omit, change or inject messages, however it can decide which message will be delivered and when.Footnote 4 The protocol completes once \(\mathcal Z\) stops activating other parties and outputs a single bit.

If the adversary is fail-stop, it always instructs the corrupted parties to follow the protocol, with the exception that they can halt prematurely and stop sending messages. If the adversary is malicious, it may instruct the corrupted parties to deviate from the protocol arbitrarily.

Let \(\textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}}(\kappa , z, {\varvec{r}})\) denote \(\mathcal Z\) ’s output on input \(z\) and security parameter \(\kappa \), after interacting with adversary \(\mathcal A\) and parties \(P_1, \ldots , P_n\) running protocol \(\pi \) with random tapes \({\varvec{r}}=(r_1, \ldots , r_n, r_\mathcal{A}, r_\mathcal{Z})\) as described above. Let \(\textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}}(\kappa , z)\) denote the random variable \(\textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}}(\kappa , z, {\varvec{r}})\), when the vector \({\varvec{r}}\) is uniformly chosen.

The Ideal Model. A computation in the ideal model consists of n dummy parties \(P_1,\ldots ,P_n\), an ideal adversary (simulator) \(\mathcal S\), an environment \(\mathcal Z\), and an ideal functionality \(\mathcal{F}\). The environment gives inputs to the honest (dummy) parties, receives their outputs, and can communicate with the ideal adversary at any point during the execution. The dummy parties act as channels between the environment and the ideal functionality, meaning that they send the inputs received from \(\mathcal Z\) to \(\mathcal{F}\), and transfer the output they receive from \(\mathcal{F}\) to \(\mathcal Z\). We consider static corruptions, and so the set of corrupted parties is fixed before the computations, and is known to \(\mathcal Z\), \(\mathcal S\) and \(\mathcal{F}\). As before, the computation completes once \(\mathcal Z\) stops activating other parties and outputs a single bit.

The ideal functionality defines the desired behaviour of the computation. \(\mathcal{F}\) receives the inputs from the dummy parties, executes the desired computation and sends the output to the parties. The ideal adversary does not see and cannot delay the communication between the parties and the ideal functionality, however, \(\mathcal S\) can communicate with \(\mathcal{F}\). As we consider asynchronous protocols in the real model, ideal functionalities must consider some inherent limitations, for instance, the ability of the adversary to decide when each honest party learns the output. Since the UC framework has no notion of time, we follow [32, 34] and model time by number of activations. Once \(\mathcal{F}\) prepares an output for some party it does not ask permission from the adversary to deliver it to the party, instead the party must request the functionality for the output, and this can only be done when the party is active. Furthermore, the adversary can instruct \(\mathcal{F}\) to delay the output for each party by ignoring the requests for a polynomial number of activations. If the environment activates the party sufficiently many times, the party will eventually receive the output from the ideal functionality. It follows that the ideal computation will terminate, i.e., all honest parties will obtain their output, in case the environment will allocate enough resources to the parties. We use the term \(\mathcal{F}\) sends a request-based delayed output to \(P_i\) to describe the above interaction between the \(\mathcal{F}\), \(\mathcal S\) and \(P_i\).

Let \(\textsc {ideal}_{\mathcal{F}, \mathcal{S}, \mathcal{Z}}(\kappa , z, {\varvec{r}})\) denote \(\mathcal Z\) ’s output on input \(z\) and security parameter \(\kappa \), after interacting with ideal adversary \(\mathcal S\) and dummy parties \(P_1, \ldots , P_n\) which interact with ideal functionality \(\mathcal{F}\) with random tapes \({\varvec{r}}=(r_\mathcal{S}, r_\mathcal{Z})\) as described above. Let \(\textsc {ideal}_{\mathcal{F}, \mathcal{S}, \mathcal{Z}}(\kappa , z)\) denote the random variable \(\textsc {ideal}_{\mathcal{F}, \mathcal{S}, \mathcal{Z}}(\kappa , z, {\varvec{r}})\), when the vector \({\varvec{r}}\) is uniformly chosen.

Definition 5

We say that a protocol \(\pi \) t-securely UC realizes an ideal functionality \(\mathcal{F}\) in the presence of static malicious (resp., fail-stop) adversaries, if for any PPT malicious (resp., fail-stop) real model adversary \(\mathcal A\), controlling a subset of up to t parties, and any PPT environment \(\mathcal Z\), there exists a PPT ideal model adversary \(\mathcal S\) such that following two distribution ensembles are computationally indistinguishable

$$ \left\{ \textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}}\left( \kappa , z\right) \right\} _{\kappa \in {\mathbb {N}}, z\in \{0,1\}^*} \mathop {\equiv }\limits ^\mathrm{c}\left\{ \textsc {ideal}_{\mathcal{F}, \mathcal{S}, \mathcal{Z}}\left( \kappa , z\right) \right\} _{\kappa \in {\mathbb {N}}, z\in \{0,1\}^*}. $$

The Hybrid Model. In a \(\mathcal{G}\)-hybrid model, the execution of the protocol proceeds as in the real model, however, the parties have access to an ideal functionality \(\mathcal{G}\) for some specific operations. The communication of the parties with the ideal functionality \(\mathcal{G}\) is performed as in the ideal model. An important property of the UC framework is that an ideal functionality in a hybrid model can be replaced with a protocol that securely UC realizes \(\mathcal{G}\). We informally state the composition theorem from Canetti [14].

Theorem 2

[14]. Let \(\pi \) be a protocol that t-securely UC realizes \(\mathcal{F}\) in the \(\mathcal{G}\)-hybrid model and let \(\rho \) be a protocol that t-securely UC realizes \(\mathcal{G}\). Then the protocol \(\pi ^\rho \) that is obtained from \(\pi \) by replacing every ideal call to \(\mathcal{G}\) with the protocol \(\rho \), t-securely UC realizes \(\mathcal{F}\) in the model without ideal functionality \(\mathcal{G}\).

3.2 Some Ideal Functionalities

We now present the asynchronous SFE and asynchronous BA functionalities.

Asynchronous Secure Function Evaluation. Secure function evaluation (SFE) is a multiparty primitive where a set of \(n\) parties wish to compute a (possibly randomized) function \(f :({\{0,1\}^*})^n\times {\{0,1\}^*}\rightarrow ({\{0,1\}^*})^n\), where \(f = (f_1, \ldots , f_n)\). That is, for a vector of inputs \({ \varvec{x}}= (x_1, \ldots , x_n)\in ({\{0,1\}^*})^n\) and random coins \(r\in _R{\{0,1\}^*}\), the output vector is \((f_1({ \varvec{x}};r), \ldots , f_n({ \varvec{x}};r))\). The output for the i’th party (with input \(x_i\)) is defined to be \(f_i({ \varvec{x}};r)\). The function f has public output, if all parties output the same value, i.e., \(f_1=\ldots =f_n\), otherwise f has private output.

In an asynchronous protocol for computing secure function evaluation, the adversary can always delay messages from t parties, and so t input values might not take part in the computation. Therefore, in the definition of the ideal functionality for asynchronous SFE, the ideal-model adversary is given the power to determine a core set of \(n-t\) input providers (t of which might be corrupted) that will contribute input values for the computation. The asynchronous secure function evaluation functionality, \({\mathcal{F}^f_\mathsf{ASFE}}\), is presented in Fig. 1.

Fig. 1.
figure 1

The asynchronous secure function evaluation functionality

Full size image

Asynchronous Byzantine Agreement. In a synchronous Byzantine agreement, each party has an input bit and outputs a bit. Three properties are required: agreement, meaning that all honest parties agree on the same bit, validity, meaning that if all honest parties have the same input bit then this will be the common output and termination, meaning that the protocol eventually terminates. When considering asynchronous Byzantine agreement (ABA), the definition must be weakened, since t input values may be delayed and not effect the result. We adopt the ABA functionality as defined in [34]. The asynchronous Byzantine agreement functionality, \({\mathcal{F}_\mathsf{ABA}}\), is presented in Fig. 2.

Fig. 2.
figure 2

The asynchronous Byzantine agreement functionality

Full size image

4 Zero-Knowledge Proofs and Certificates

In order to ensure security against malicious behaviour, the parties must prove their actions using zero-knowledge proofs during the protocol. The zero-knowledge functionality \({\mathcal{F}_\mathsf{ZK}}\) and its one-to-many extension \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) are defined in Sect. 4.1 and the notion of certificates in Sect. 4.2.

4.1 Zero-Knowledge Proofs

In the zero-knowledge functionality, parameterized by a relation R, the prover sends the functionality a statement x to be proven along with a witness w. In response, the functionality forwards the statement x to the verifier if and only if \(R(x,w) = 1\) (i.e., if and only if x a correct statement and w is a witness for x). Thus, in actuality, this is a proof of knowledge in that the verifier is assured that the prover actually knows w (and has explicitly sent w to the functionality), rather than just being assured that such a w exists. The zero-knowledge functionality, \({\mathcal{F}_\mathsf{ZK}}\), is presented in Fig. 3.Footnote 5

Fig. 3.
figure 3

The zero-knowledge functionality

Full size image

The zero-knowledge functionality, as defined in Fig. 3, is parameterized by a single relation R (and thus a different copy of \({\mathcal{F}_\mathsf{ZK}}\) is needed for every different relation required). In this work we require zero-knowledge proofs for several relations, therefore, we use standard techniques by considering the relation R index several predetermined relations. This can be implemented by separating the statement x into two parts: \(x_1\) that indexes the relation to be used and \(x_2\) that is the actual statement. Then, define \(R((x_1, x_2),w)\) as \(R_{x_1}(x_2,w)\).

We now define the one-to-many extension of the zero-knowledge functionality, where one party proves a statement to some subset of parties. The definition of the one-to-many zero-knowledge functionality, denoted \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\), is presented in Fig. 4.

Fig. 4.
figure 4

The one-to-many zero-knowledge functionality

Full size image

4.2 Certificates

As we consider static corruptions, there exists efficient constant-round zero-knowledge protocols in the \({\mathcal{F}_\mathsf{CRS}}\)-hybrid model, e.g., omega protocols [23], and even non-interactive zero-knowledge proofs [21]. These protocols would suffice for realizing \({\mathcal{F}_\mathsf{ZK}}\) as it is a two-party functionality. However, when considering the multiparty functionality \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\), some problems may arise. The reason is that the statement that needs to be proven is not public, and a malicious prover may prove different statements to different parties.

This problem is resolved using certificates, introduced by Hirt et al. [30]. Certificates are generated by an interactive protocols among the parties such that at the end of the execution, one party can non-interactively prove correctness of some statement to each other party, without revealing additional information. The protocol for issuing a certificate is based on threshold signatures and involves two stages. First, a signature proving the statement is computed interactively with all the parties – it is essential that all the parties are active during this stage, otherwise the prover might not receive enough shares to reconstruct the signature. Next, the prover can send the signature as a non-interactive proof of the statement and every other party can validate it.

During out main protocol, in Sect. 5, we consider three relations:

  • Proof of Plaintext Knowledge. The relations is parameterized by a TFHE scheme. The statement consists of a public encryption key ek and a ciphertext c and the witness consists of the plaintext x and random coins r, explaining c as an encryption of x under ek. That is

    $$ R_\mathsf{PoPK}=\left\{ ((ek,c),(x,r))\mid c={\text {Enc}}_{ek}(x;r)\right\} . $$

  • Proof of Correct Decryption. The relations is parameterized by a TFHE scheme. The statement consists of a public encryption key ek, a ciphertext c and a decryption share d and the witness consists of the decryption key dk. That is

    $$ R_\mathsf{PoCD}=\left\{ ((ek,c,d),dk)\mid d={\text {DecShare}}_{dk}(c)\right\} . $$

  • Proof of Correct Signature. The relations is parameterized by a TSIG scheme. The statement consists of a public verification key vk, a message \(\mathsf{msg}\) and a signature share \(\sigma \) and the witness consists of the signing key sk. That is

    $$ R_\mathsf{PoCS}=\left\{ ((vk,\mathsf{msg},\sigma ),sk)\mid \sigma ={\text {SignShare}}_{sk}(\mathsf{msg})\right\} $$

Lemma 1

Let \(n>2t+1\) and let \(R_{x_1}\) be a binary relation. Assuming the existence of threshold signature schemes, \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) can be UC realized in the \({\mathcal{F}_\mathsf{ZK}}\)-hybrid model in the presence of static malicious adversaries.

Proof

Consider a party \(P_i\), holding a witness w, that wishes to prove a statement x to all other parties. The high-level idea is for \(P_i\) to prove x to each other \(P_j\) using a two-party zero-knowledge proof. If all parties are active and \(P_i\) is honest, it is guaranteed that eventually at least \(n-t\) proofs will successfully terminate. Once a verifier \(P_j\) accepts the proof, it produces a share \(\sigma _j\) of a signature approving x, sends the share back to \(P_i\) and proves the validity of \(\sigma _j\) to \(P_i\) using another two-party zero-knowledge proof. After \(P_i\) obtains \(n-t\) valid signature shares, it can reconstruct the signature \(\sigma \) which serves as its certificate.

Assuming that \(n>2t+1\), it holds that \((n-t)-t\ge 1\), and so it is guaranteed that at least one honest party accepted the proof of the statement x; it follows that the corrupted parties cannot falsely certify invalid statements. Furthermore, assuming the two-parties zero-knowledge proofs are constant round, certifying a statement takes constant time.

Protocol 3 shows how to compute \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) in the \({\mathcal{F}_\mathsf{ZK}}\)-hybrid model. During the protocol, two instances of \({\mathcal{F}_\mathsf{ZK}}\) are used; the first is for proving statements for the relation \(R_{x_1}\) and the second for the relation \(R_\mathsf{PoCS}\). We use the notation \(\textsf {sid}^k_j\) for the string \(\textsf {sid}\circ k \circ j\).

figure a

Let \(\mathcal A\) be an adversary attacking Protocol 3 and let \(\mathcal Z\) be an environment. We construct a simulator \(\mathcal S\) as follows. \(\mathcal S\) runs the adversary \(\mathcal A\) and simulates the environment, the honest parties and the ideal functionality \({\mathcal{F}_\mathsf{ZK}}\) towards \(\mathcal A\). In order to simulate \(\mathcal Z\), \(\mathcal S\) forwards every message it receives from \(\mathcal Z\) to \(\mathcal A\) and vice-versa. \(\mathcal S\) simulates the honest parties towards \(\mathcal A\). In case \(P_i\) is corrupted, \(\mathcal S\) receives \(((x_1,x_2),w)\) by simulating \({\mathcal{F}_\mathsf{ZK}}\) and in addition receives \(\mathcal{P}\) from \(\mathcal A\). Next, \(\mathcal S\) sends \((\mathsf{ZK \hbox {-}prover},\textsf {sid},\mathcal{P},(x_1,x_2),w)\) to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) and continues simulating the honest parties and \({\mathcal{F}_\mathsf{ZK}}\) to \(\mathcal A\). In case \(P_i\) is not corrupted, it first receives \((\mathsf{ZK \hbox {-}proof}, \textsf {sid}, P_i, \mathcal{P}, (x_1,x_2))\) from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\). Next, whenever \(\mathcal A\) requests output from \({\mathcal{F}_\mathsf{ZK}}\) with \(\textsf {sid}^1_j\) for \(j\in {\mathcal {I}}\), \(\mathcal S\) replies with \((\mathsf{ZK \hbox {-}proof}, \textsf {sid}, (x_1,x_2))\). The rest of the simulation follows the protocol. It is straight-forward to see that the view of \(\mathcal A\) is indistinguishable when interacting with \(\mathcal S\) and when attacking the execution of Protocol 3, and the proof follows.

5 Asynchronous MPC Protocol

Following the spirit of [29, 30], the protocol consists of an offline key-distribution stage (preprocessing) followed three online stages: the input stage, the computation and threshold-decryption stage and the termination stage. We present the protocol for public-output functionalities, and a variant for private-output functionalities can be obtained using the technique of [29].

5.1 Key-Distribution Stage

The key-distribution stage can be computed once for multiple instances of the protocol and essentially distributes the keys for threshold schemes amongst the parties. We will describe the protocol in a hybrid model where the key-distribution is done by an ideal functionality \({\mathcal{F}_\mathsf{KeyDist}}\). This ideal functionality can be realized using any asynchronous MPC protocol that does not require preprocessing, e.g., [35]. We emphasize that the time complexity of the protocol realizing the key-distribution stage is independent of the function to compute.

\({\mathcal{F}_\mathsf{KeyDist}}\) generates the public and secret keys for the TFHE and the TSIG schemes and sends to each party its corresponding keys. The key-distribution functionality is described in Fig. 5.

Fig. 5.
figure 6

The key-distribution functionality

Full size image

5.2 Input Stage

In the input stage, as described in Protocol 4, each party encrypts its input and sends it to all the other parties along with certificates proving that the party knows the plaintext (and so independence of inputs is retained) and that \(n-t\) parties have obtained it. Next, the parties jointly agree on a common subset of input providers, \(\mathsf{CoreSet}\), which consists of \(n-t\) parties whose encrypted input has been obtained by all the parties. This stage proceeds in a similar manner to [29] with the difference that the plaintexts are encrypted using TFHE rather than TAHE.

In more details, each party \(P_i\) starts by encrypting its input \(c_i \leftarrow {\text {Enc}}_{ek}(x_i)\), and proving to each other party knowledge of the plaintext. Once a party \(P_j\) accepts the proof, it sends \(P_i\) a signature share for the statement \(\mathsf{msg}=\langle n-t \text{ parties } \text{ hold } \text{ the } \text{ input } c_i \text{ of } P_i \rangle \). After \(P_i\) obtains \(n-t\) signature shares, it can reconstruct and distribute the certificate \(\mathsf{cert}^\mathsf{input}_i\), which is essentially a signature on \(\mathsf{msg}\).

When a party collects \(n-t\) certificates it knows that at least \(n-t\) parties have their certified inputs distributed to at least \(n-t\) parties. Since \(n\ge 2t+1\), by assumption, this means that at least \((n-t)-t \ge 1\) honest parties obtained certified inputs from at least \(n-t\) parties. Hence, if the honest parties echo the certified inputs they receive and collect \(n-t\) echoes, then all honest parties will end up holding the certified inputs of the \(n-t\) parties which had their certified inputs distributed to at least one honest party. These \(n-t\) parties will eventually be the input providers. To determine who they are, the asynchronous Byzantine agreements functionality \({\mathcal{F}_\mathsf{ABA}}\) is invoked (concurrently) \(n\) times. During the protocol description we use the notation \(\textsf {sid}^k_j\) for the string \(\textsf {sid}\circ k \circ j\).

figure b

5.3 Computation and Threshold Decryption Stage

In the computation and threshold-decryption stage, as described in Protocol 5, each party locally prepares the circuit \(\mathsf{Circ}(\mathsf{CoreSet})\) (with hard-wired default input values for parties outside \(\mathsf{CoreSet}\)) and evaluates it over the encrypted input ciphertexts that were agreed upon in the input stage. Since the encryption scheme is fully homomorphic, this part is done without interaction between the parties. Once the encrypted output \(\tilde{c}_i\) is obtained, \(P_i\) computes a decryption share \(d_i\) and interactively certifies it. Next, \(P_i\) sends the certified decryption share to all other parties and waits until it receives \(t+1\) certified decryption shares, from which it can reconstruct the output \(y_i\).

Once \(P_i\) obtains the output, it should send it to all other parties in order to trigger the termination stage. This is done by first computing a signature share \(\sigma ^\mathsf{output}_i\) for the statement that \(y_i\) is the output value, interactively certify \(\sigma ^\mathsf{output}_i\) and send it to all parties. Once \(P_i\) receives \(n-t\) signature shares it can reconstruct a certificate proving that \(y_i\) is indeed the output value. Finally \(P_i\) sends \(y_i\) along with the certificate to all the parties.

figure c

5.4 Termination Stage

The termination stage, as described in Protocol 6, ensures that all honest parties will eventually terminate the protocol, and will do so with the same output. Recall that the computation and threshold-decryption stage is concluded when a party sends a certified output value to all the parties. The party cannot terminate at this point since it might be required to assist in certifying statements for other parties. Therefore, during the entire course of the protocol the termination code is run concurrently. The termination stage follows the technique of Bracha [13]. In this stage, each party continuously collects certified outputs sent by other parties. Once it receives \(t+1\) certified outputs of the same value it knows that this is the correct output value for the computation (since at least one honest party sent it). The party then adopts this certified output as its own output (in case it did not obtain the output value earlier) and echoes it to all other parties. Once the party receives \(n-t\) certified outputs of the same value, it can terminate.

figure d

6 Proof of Security

Lemma 2

Let f be an \(n\)-party functionality and assume the existence of TFHE and TSIG schemes. Then the protocol \(\pi \) described in Protocols 4, 5 and 6 UC realizes \({\mathcal{F}^f_\mathsf{ASFE}}\) in the \(({\mathcal{F}_\mathsf{KeyDist}},{\mathcal{F}_\mathsf{ZK}},{\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}},{\mathcal{F}_\mathsf{ABA}})\)-hybrid model, in constant time, in the presence of static malicious adversaries corrupting at most t parties, for \(t<n/ 2\).

Proof

Let \(\mathcal A\) be a static malicious adversary against the execution of \(\pi \) and let \(\mathcal Z\) be an environment. Denote by \({\mathcal {I}}\) the set of indices of the corrupted parties. We construct an ideal-process adversary \(\mathcal S\), interacting with the environment \(\mathcal Z\) and with the ideal functionality \({\mathcal{F}^f_\mathsf{ASFE}}\). \(\mathcal S\) constructs virtual real-model honest parties and runs the real-model adversary \(\mathcal A\). \(\mathcal S\) must simulate the view of \(\mathcal A\), i.e., its communication with \(\mathcal Z\), the messages sent by the uncorrupted parties, and the interactions with the functionalities \(({\mathcal{F}_\mathsf{KeyDist}},{\mathcal{F}_\mathsf{ZK}},{\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}},{\mathcal{F}_\mathsf{ABA}})\).

In order to simulate the communication with \(\mathcal Z\), every message that \(\mathcal S\) receives from \(\mathcal Z\) is sent to \(\mathcal A\), and likewise, every message sent from \(\mathcal A\) sends to \(\mathcal Z\) is forwarded by \(\mathcal S\).

Simulating the Input Stage. \(\mathcal S\) starts by simulating \({\mathcal{F}_\mathsf{KeyDist}}\) and generates the cryptographic keys by computing \((dk, ek)\leftarrow {\text {Gen}}_{(t,n)}(1^\kappa )\), where \(dk=(dk_1, \ldots , dk_n)\), and \((sk, vk)\leftarrow {\text {SigGen}}_{(n-t,n)}(1^\kappa )\), where \(sk=(sk_1, \ldots , sk_n)\), and recording (dk, ek, sk, vk). Upon request from \(\mathcal A\), \(\mathcal S\) sends the corresponding keys \((dk_i, ek, sk_i, vk)\) for each corrupted party \(P_i\) (\(i\in {\mathcal {I}}\)).

Next, \(\mathcal S\) simulates the operations of all honest parties in the input stage (Protocol 4). During the Distribution of Encrypted Input phase, \(\mathcal S\) sets every ciphertext of an honest party to be an encryption of zero, that is for every \(j\notin {\mathcal {I}}\), compute \(c_j\leftarrow {\text {Enc}}_{ek}(0)\). When the adversary send a request to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) with \(\textsf {sid}^1_j\) (for \(j\notin {\mathcal {I}}\)) on behalf of a corrupted party, \(\mathcal S\) responds with a confirmation of the validity of the ciphertext \(c_j\), i.e., with \((\mathsf{ZK \hbox {-}proof}, \textsf {sid}^1_j, P_j, \{P_1, \ldots , P_n\}\setminus \{P_j\}, (\mathsf{PoPK},ek,c_j))\). When a corrupted party \(P_i\) (\(i\in {\mathcal {I}}\)) sends \((\mathsf{ZK \hbox {-}prover}, \textsf {sid}^1_i, \{P_1, \ldots , P_n\}\setminus \{P_i\}, (\mathsf{PoPK}, ek,c_i), (x_i,r_i))\) to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\), \(\mathcal S\) confirms that indeed \(c_i={\text {Enc}}_{ek}(x_i;r_i)\) and if so records the input \(x_i\). \(\mathcal S\) continues to simulate the honest parties by following the protocol; in all other calls to \({\mathcal{F}_\mathsf{ZK}}\), \(\mathcal S\) responds according to the ideal functionality. When the simulation reaches the Select Input Providers phase, \(\mathcal S\) simulates the interface to \({\mathcal{F}_\mathsf{ABA}}\) to \(\mathcal A\). When the first honest party completes the simulated input stage, \(\mathcal S\) learns the set \(\mathsf{CoreSet}\).

Note that \(\mathcal S\) learned the input values that were used by the adversary \(\mathcal A\) on behalf of the corrupted parties that were selected to be input providers. This follows since for every \(i\in {\mathcal {I}}\cap \mathsf{CoreSet}\), there exists an honest party that confirmed the ciphertext \(c_i\) and sent a signature share to \(P_i\) (except for the negligible probability that \(\mathcal A\) managed to forge a signature). It follows that the corrupted party must have sent its input to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) during the Distribution of Encrypted Input phase, and so its input value \(x_i\) was recorded by \(\mathcal S\).

Interacting with \({\mathcal{F}^f_\mathsf{ASFE}}\). Once \(\mathcal S\) learns \(\mathsf{CoreSet}\), it sends to \({\mathcal{F}^f_\mathsf{ASFE}}\) the input value \(x_i\) that was recorded for each \(i\in {\mathcal {I}}\cap \mathsf{CoreSet}\), the input value \(x_i=0\) for each \(i\in {\mathcal {I}}\setminus \mathsf{CoreSet}\) and the set \(\mathsf{CoreSet}\) as the set of input providers. Once \(\mathcal S\) receives back the output value y, it starts the simulation of the computation and threshold-decryption stage.

Simulating the Computation and Threshold-Decryption Stage. In order to simulate the honest parties in this stage (Protocol 5), \(\mathcal S\) proceeds as follows. Initially, \(\mathcal S\) computes the evaluated ciphertext \(\tilde{c}\) based on the input ciphertexts of the input providers, i.e., \(\tilde{c} = {\text {Eval}}_{ek}(\mathsf{Circ}(\mathsf{CoreSet}), c_{j_1}, \ldots , c_{j_{\left| \mathsf{CoreSet}\right| }})\). Next, for every \(i\in {\mathcal {I}}\), use the share of the decryption key \(dk_i\) to compute the decryption share \(d_i={\text {DecShare}}_{dk_i}(\tilde{c})\). \(\mathcal S\) then sets the decryption share \(d_j\), for every \(j\notin {\mathcal {I}}\), such that \((d_1,\ldots ,d_n)\) form a secret sharing of the output value y. When the adversary sends a request to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) with \(\textsf {sid}^4_j\) (for \(j\notin {\mathcal {I}}\)) on behalf of a corrupted party, \(\mathcal S\) responds with a confirmation of the validity of the decryption share \(d_j\), i.e., with \((\mathsf{ZK \hbox {-}proof}, \textsf {sid}^4_j, P_j, \{P_1, \ldots , P_n\}\setminus \{P_j\}, (\mathsf{PoCD},ek,\tilde{c}, d_j))\). \(\mathcal S\) continues to simulate the honest parties by following the protocol; in all other calls to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\), \(\mathcal S\) responds according to the ideal functionality.

Simulating the Termination Stage. \(\mathcal S\) simulates the honest parties in the termination stage (Protocol 6) by following the protocol;

We now define a series of hybrid games that will be used to prove the indistinguishability of the real and ideal worlds. The output of each game is the output of the environment.

The Game \(\textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}}.\) This is exactly the execution of the protocol \(\pi \) in the real-model with environment \(\mathcal Z\) and adversary \(\mathcal A\) (and ideal functionalities \(({\mathcal{F}_\mathsf{KeyDist}},{\mathcal{F}_\mathsf{ZK}},{\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}},{\mathcal{F}_\mathsf{ABA}})\)).

The Game \(\textsc {hyb}^1_{\pi , \mathcal{A}, \mathcal{Z}}.\) In this game, we modify the real-model experiment in the computation stage as follows. Whenever a corrupted party requests output from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) with \(\textsf {sid}^4_j\) (for \(j\notin {\mathcal {I}}\)), the response from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) is \((\mathsf{ZK \hbox {-}proof}, \textsf {sid}^4_j, P_j, \{P_1, \ldots , P_n\}\setminus \{P_j\}, (\mathsf{PoCD},ek,\tilde{c}, d_j))\), without checking if \(P_j\) sent a valid witness.

Claim 7. \(\textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}} \equiv \textsc {hyb}^1_{\pi , \mathcal{A}, \mathcal{Z}}\).

Proof. This follows since in the execution of \(\pi \), honest parties always send a valid witness to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\), and so the response from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) is the same in both games.

The Game \(\textsc {hyb}^2_{\pi , \mathcal{A}, \mathcal{Z}}.\) This game is just like an execution of \(\textsc {hyb}^1\) except for the computation of the decryption shares of honest parties during the computation stage. Let y be the output of f, let \(\tilde{c}\) be the evaluated ciphertext, let \(dk_i\) (for \(i\in {\mathcal {I}}\)) be the shares of the decryption key held by the corrupted parties, and let \(d_i={\text {DecShare}}_{dk_i}(\tilde{c})\) be the corresponding decryption shares. Then, instead of computing the decryption share of the honest parties as \(d_j={\text {DecShare}}_{dk_j}(\tilde{c})\) (for \(j\notin {\mathcal {I}}\)), the decryption shares are computed such that \((d_1,\ldots ,d_n)\) form a secret sharing of the output value y.

Claim 8. \(\textsc {hyb}^1_{\pi , \mathcal{A}, \mathcal{Z}} \mathop {\equiv }\limits ^\mathrm{c}\textsc {hyb}^2_{\pi , \mathcal{A}, \mathcal{Z}}\).

Proof. The ability to compute the decryption shares of the honest parties follows from the properties of the secret sharing scheme.Footnote 6 Computational indistinguishability follows from the semantic security of the TFHE scheme.

The Game \(\textsc {hyb}^3_{\pi , \mathcal{A}, \mathcal{Z}}.\) This game is just like an execution of \(\textsc {hyb}^2\) except for the following difference. Whenever a corrupted party requests output from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) with \(\textsf {sid}^1_j\) (for \(j\notin {\mathcal {I}}\)), the response from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) is \((\mathsf{ZK \hbox {-}proof}, \textsf {sid}^1_j, P_j, \{P_1, \ldots , P_n\}\setminus \{P_j\}, (\mathsf{PoPK},ek,c_j))\), without checking if \(P_j\) sent a valid witness.

Claim 9. \(\textsc {hyb}^2_{\pi , \mathcal{A}, \mathcal{Z}} \equiv \textsc {hyb}^3_{\pi , \mathcal{A}, \mathcal{Z}}\).

Proof. This follows since in the execution of \(\pi \), honest parties always send a valid witness to \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\), and so the response from \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) is the same in both games.

The Game \(\textsc {hyb}^{4,\ell }_{\pi , \mathcal{A}, \mathcal{Z}}.\). This game is just like an execution of \(\textsc {hyb}^3\) with the following difference. In the input stage, in case \(i\le \ell \) honest party \(P_i\) encrypts its actual input \(c_i\leftarrow {\text {Enc}}_{ek}(x_i)\), whereas in case \(i> \ell \) \(P_i\) encrypts zeros \(c_i\leftarrow {\text {Enc}}_{ek}(0)\). (Note that \(\textsc {hyb}^{4,n}\) is exactly \(\textsc {hyb}^3\).)

Claim 10. For every \(\ell \in \left\{ 0,\ldots , n-1\right\} \), \(\textsc {hyb}^{4,\ell }_{\pi , \mathcal{A}, \mathcal{Z}} \mathop {\equiv }\limits ^\mathrm{c}\textsc {hyb}^{4,\ell +1}_{\pi , \mathcal{A}, \mathcal{Z}}\).

Proof. This follows from the semantic security of the encryption scheme.

Claim 11. \(\textsc {hyb}^{4,0}_{\pi , \mathcal{A}, \mathcal{Z}} \equiv \textsc {ideal}_{f,\mathcal{S},\mathcal{Z}}\).

Proof. This follows since the joint behaviour of ideal functionalities \(({\mathcal{F}_\mathsf{KeyDist}},{\mathcal{F}_\mathsf{ZK}},{\mathcal{F}_\mathsf{ABA}})\), the modified behaviour of the ideal functionality \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) and the behaviour of the honest parties in \(\textsc {hyb}^{4,0}\) is identical to the simulation done by \(\mathcal S\).

Combining Claims 7–11, we conclude that \(\textsc {real}_{\pi , \mathcal{A}, \mathcal{Z}} \mathop {\equiv }\limits ^\mathrm{c}\textsc {ideal}_{f,\mathcal{S},\mathcal{Z}}\).

7 Conclusions

By Lemma 1, \({\mathcal{F}^{1:{{\tiny \mathrm{M}}}}_{\mathsf{ZK}}}\) can be realized in the \({\mathcal{F}_\mathsf{ZK}}\)-hybrid model (assuming the existence of TSIG and an honest majority). Assuming the existence of enhanced trapdoor permutations, \({\mathcal{F}_\mathsf{ZK}}\) can be UC realized in the \({\mathcal{F}_\mathsf{CRS}}\)-hybrid model non-interactively (meaning that the prover sends a single message to the verifier) [21]. Using universal composition with joint state [16], a multi-session version of \({\mathcal{F}_\mathsf{ZK}}\) that requires a single copy of the CRS can be used. We thus obtain the following theorem from Lemma 2:

Theorem 12

(formal statement of Theorem 1 ). Let f be an \(n\)-party function and assume that enhanced trapdoor permutations, TFHE schemes and TSIG schemes exist. Then \({\mathcal{F}^f_\mathsf{ASFE}}\) can be UC realized in the \(({\mathcal{F}_\mathsf{CRS}},{\mathcal{F}_\mathsf{KeyDist}},{\mathcal{F}_\mathsf{ABA}})\)-hybrid model, in constant time, in the presence of static malicious adversaries corrupting at most t parties, for \(t<n/ 2\).

During the input stage (Protocol 4) the functionality \({\mathcal{F}_\mathsf{ABA}}\) is concurrently invoked n times. If \({\mathcal{F}_\mathsf{ABA}}\) is instantiated using a constant expected round protocol, e.g., the protocol of Canetti and Rabin [15], the time complexity of the concurrent composition will result with expectancy of \(\log (n)\). Ben-Or and El-Yaniv [7] constructed a concurrent ABA protocol that runs in constant expected time, assuming that \(t<n/ 3\).Footnote 7 We therefore conclude with the following corollary.

Corollary 2

(formal statement of Corollary 1 ). Let f be an \(n\)-party function and assume that enhanced trapdoor permutations, TFHE schemes and TSIG schemes exist. Then \({\mathcal{F}^f_\mathsf{ASFE}}\) can be UC realized in the \(({\mathcal{F}_\mathsf{CRS}},{\mathcal{F}_\mathsf{KeyDist}})\)-hybrid model, in constant expected time, in the presence of static malicious adversaries corrupting at most t parties, for \(t<n/ 3\).