Mixed-Technique Multi-Party Computations Composed of Two-Party Computations

Abstract

Protocols for secure multi-party computation are commonly composed of different sub-protocols, combining techniques such as homomorphic encryption, secret or Boolean sharing, and garbled circuits. In this paper, we design a new class of multi-party computation protocols which themselves are composed out of two-party protocols. We integrate both types of compositions, compositions of fully homomorphic encryption and garbled circuits with compositions of multi-party protocols from two-party protocols. As a result, we can construct communication-efficient protocols for special problems. Furthermore, we show how to efficiently ensure the security of composed protocols against malicious adversaries by proving in zero-knowledge that conversions between individual techniques are correct. To demonstrate the usefulness of this approach, we give an example scheme for private set analytics, i.e., private set disjointness. This scheme enjoys lower communication complexity than a solution based on generic multi-party computation and lower computation cost than fully homomorphic encryption. So, our design is more suitable for deployments in wide-area networks, such as the Internet, with many participants or problems with circuits of moderate or high multiplicative depth.

1 Introduction

Whereas secure two-party computations are deployed in practice [68], designing and deploying practical secure multi-party computation is still an open challenge. Communication latency is a typical bottleneck for many multi-round protocols, and in response constant-round multi-party computations [34, 45, 46] based on Beaver et al.’s [5]’s technique [5] have been designed. Their deployment is lacking due to challenges from implementation complexity, communication bandwidth, and memory requirements. To address these challenges, protocols using fully-homomorphic encryption (FHE) [12, 26] and dual execution can be used. Yet, designing efficient homomorphic encryption schemes (for arithmetic circuits) is also an open challenge. Circuits with high multiplicative depth, the reason for a high number of rounds in many multi-party computation protocols, imply high computation costs.

In this paper, we present a design alternative. We specifically consider multi-party computations that can at least partially be decomposed into a sequence of two-party computations (2PCs). We first evaluate 2PCs using garbled circuits and then combine the output and continue computation using FHE evaluation. The idea of our mixed-technique protocols is to exploit advantages of each technique, for example, binary vs. arithmetic circuits, typical in application domains such as machine learning [14, 22, 31, 50]. For fully malicious security, we show how to convert between outputs of garbled circuits and FHE ciphertexts using efficient zero-knowledge proofs. Compared to conversions in the semi-honest model [41], this requires a different construction, which has, however, little additional overhead. Other related work [40] sketches malicious conversions, but only for two parties, whereas we consider the multi-party setting. The first phase of 2PC reduces multiplicative depth for the following FHE evaluation phase, but remains small enough to have low communication complexity. As we show by construction, such a combined protocol can keep a constant number of rounds and can still be secure in the malicious model. Due to their lower communication requirements, combined protocols have the potential for deployment in wide area networks.

The composition of 2PC protocols into a multi-party protocol can take many forms. In order to demonstrate the advantages of our constructions, we design and investigate a combined protocol for private set disjointness, i.e., a protocol that computes whether the intersection of sets is empty, but does not reveal anything else, including the intersection itself. This protocol follows a star topology of communication where each party $P_i$ engages in 2PC with a central party $P_1$. Our composition of 2PC protocols into a multi-party protocol is particularly efficient if it follows a star topology. We stress that even in the star topology, we provide malicious security against an adversary controlling the central node (among others) which is the challenge of any such composition. Furthermore, besides the set disjointness protocol there are (infinitely) many other protocols that can be implemented in a star topology. The entire class of multi-party private set analytics protocols [4, 13, 21, 47, 52] is an example. However, our protocols are also not limited to a star topology, and we also mention other use cases, such as auctions [9], that do not follow a star topology.

Our example use case is driven by the use case of sharing Indicators of Compromise (IoCs), where multiple parties try to determine whether they have been subject to a common attack. We design a maliciously-secure protocol which determines whether the multi-party set intersection is empty. A non-empty intersection would be grounds for further investigation. With each party’s set holding n elements, our set disjointness protocol runs in 9 rounds, needs O(n) broadcasts, and has a message complexity linear in the number of comparisons required to compare all parties’ inputs. We have implemented a semi-honest version of this protocol to show that our design offers performance improvements over other multi-party computation protocols in the semi-honest model. Using our zero-knowledge proofs, our protocol can also be made secure in the malicious model.

In summary, the main contributions of this paper are:

• 1. A construction for mixed-technique MPC composed from 2PC which features a constant number of rounds, low communication complexity, and malicious security.

• 2. Efficient zero-knowledge proofs, included in this construction, converting between garbled circuit outputs and homomorphic encryption with malicious security.

• 3. A demonstration of our construction’s usefulness by realizing a multi-party protocol for set disjointness.

In the full version of this paper [10], we also present a technique replacing standard verification of hash-based commitments during 2PC by a white-box use of garbled circuits. We use this technique to reduce communication overhead in our conversion, but the idea is general, applicable to other scenarios, and of independent interest.

2 Conversion Between 2PC and Homomorphic Encryption

To simplify exposition, we start with a motivation and an overview of our conversion for the special case of $d=2$ parties. For space reasons, we defer the extension to any $d\ge {}2$ parties to Appendix B. Our goal is malicious security of the conversions which we describe in Sect. 2.1.

Parties $P_1$ and $P_2$ want to jointly compute function $F(I_1,I_2)=O$ on their respective input bit strings $I_1$ and $I_2$ to receive output string $O=(o_1,\ldots ,o_{N})$. For security reasons, $P_1$ should only learn some subset of bit string O, but nothing else (for example not $P_2$’s input). Similarly, $P_2$ should only learn the other bits of O, but nothing else. To enable secure computation of F, parties can revert to two standard approaches. Parties could express F as a Boolean circuit and evaluate this circuit using maliciously-secure two-party garbled circuit computation (2PC). Alternatively, parties express F as an arithmetic circuit, compute a shared private key of a fully homomorphic encryption (FHE), and encrypt their inputs with the corresponding public-key. Parties then evaluate the circuit homomorphically and jointly decrypt the final result such that each party only learns their output bits.

Yet, each of the two approaches comes with performance issues. On the one hand, FHE evaluation of arithmetic circuits with large multiplicative depth is computationally expensive. On the other hand, evaluating Boolean circuits with 2PC for large circuits is expensive regarding the amount of communication.

So, a third alternative and the focus of this paper is for parties to evaluate F using a mix of both techniques. Parties evaluate F as a circuit decomposed into a sequence of sub-circuits $F(I_1,I_2)=(C_1\circ \cdots \circ {}C_{m})(I_1,I_2)$. Some sub-circuits $C_i$ are Boolean, while others are arithmetic. Parties agree that Boolean sub-circuits of function F will be evaluated using garbled circuit 2PC, and arithmetic sub-circuits of F will be evaluated using FHE. Output of 2PC will serve as input to FHE and vice versa. The goal of such a mixed-techniques approach is to optimize overall performance by reducing multiplicative depth of FHE circuits and communication complexity of 2PC circuits. For clarity, we now denote Boolean (sub-)circuits $C_i$ by $C^{\textsf{Bool}}_i$ and arithmetic (sub-)circuits $C_i$ by $C^{\textsf{Arith}}_i$. Assume that $P_1$ and $P_2$ have initially computed a public and private key pair for a homomorphic encryption $\textsf{Enc}$, where the private key is shared among both parties.

2.1 Malicious Security

Achieving malicious security for conversion turns out to be a challenge. For example, let $P_1$ be the garbler and $P_2$ the evaluator during 2PC evaluation of a simple sub-circuit $C^{\textsf{Bool}}_i$ with two input and two output bits $(x,y)=C^{\textsf{Bool}}_i(a,b)$. Evaluator $P_2$ receives both output bits x, y and must convert them into correct homomorphic encryptions $\textsf{Enc}(x)$ and $\textsf{Enc}(y)$. This is hard to achieve against malicious adversaries: as $P_2$ could be malicious, $P_2$ must prove to $P_1$ that ciphertexts $\textsf{Enc}(x)$ and $\textsf{Enc}(y)$ are correctly encrypting outputs x and y received during 2PC. Worse, $P_2$ should not even learn x and y, as they are an intermediate result of C’s evaluation or maybe output bits for $P_1$. Party $P_2$ should instead receive related information during 2PC which then allows $P_2$ to indirectly generate homomorphic encryptions $\textsf{Enc}(x)$ and $\textsf{Enc}(y)$. Alternatively, one might suggest implementing homomorphic encryption $\textsf{Enc}$ inside a 2PC circuit, but this is too costly.

Similarly, we need to convert FHE ciphertexts output by circuits $C^{\textsf{Arith}}_i$ into input for 2PC garbled circuits with malicious security. Moreover, if $P_1$ and $P_2$’s 2PC computation was part of a larger MPC computation involving $d\ge {}2$ parties, we also need to consider the case where both are malicious, so they must prove to all parties that their encryptions are correct. Finally, the private key is shared among all d parties which impedes easy zero-knowledge (ZK) proofs.

Important Remarks. This paper targets secure output conversion between 2PC and FHE. To actually evaluate Boolean sub-circuit $C^{\textsf{Bool}}_i$, we assume existence of any maliciously secure 2PC scheme as a building block. Several different approaches exist which achieve maliciously secure 2PC in practice, see [43, 44, 54, 65] for an overview.

For secure evaluation of arithmetic sub-circuits $C^{\textsf{Arith}}_i$, any FHE scheme could serve as building block. FHE is maliciously secure by default, as long as parties evaluate the same circuit on the same ciphertexts. To enforce this, our conversion requires the FHE scheme to also support distributed key generation and certain ZK proofs detailed below. There exist several efficient lattice-based FHE schemes with support for both [7, 8, 11, 18, 19, 51, 63], and there are even efficient schemes which allow proving general, arbitrary ZK statements in addition to distributed key generation [2]. While describing details of our techniques, we use any of these as an underlying building block, e.g., the one by Asharov et al. [2].

2.2 Solution Overview

Roadmap. There are two different cases for conversion we will have to consider in a mixed-technique setting. First, parties convert output bits $(o_{i,1},\ldots ,o_{i,n})=C^{\textsf{Bool}}_i(I_{i,1},$ $I_{i,2})$ from 2PC evaluation of circuit $C^{\textsf{Bool}}_i$ on input strings $I_{i,1}$ and $I_{i,2}$ into n homomorphic encryptions $\textsf{Enc}(o_{i,j})$. Knowing encryptions $\textsf{Enc}(o_{i,j})$, each party then evaluates the subsequent arithmetic circuit $C^{\textsf{Arith}}_{i+1}$.

Second, parties convert a sequence of ciphertexts $\textsf{Enc}(b_i)$, homomorphic encryptions of bits $b_i$ (or integers, see Appendix A) into input for a 2PC Boolean circuit evaluation. That is, both parties have evaluated arithmetic sub-circuit $C^{\textsf{Arith}}_{i}$ and computed ciphertexts $\textsf{Enc}(b_i)$, respectively. These ciphertexts will now be converted into input for 2PC evaluation of sub-circuit $C^{\textsf{Bool}}_{i+1}$.

Actual evaluation of circuits is then secure by definition, as we rely on standard maliciously-secure 2PC. For arithmetic sub-circuits, both parties evaluate FHE ciphertexts on their own. An honest party will automatically compute correct output ciphertexts as long as input ciphertexts are correct.

Parties will also need to securely convert both parties’ plain input into either FHE encryptions or 2PC inputs. Yet, that part is trivial: if the first sub-circuit is an arithmetic circuit, a party sends homomorphic encryptions of each input bit. If the first circuit is Boolean, we rely on whatever technique the underlying maliciously secure 2PC offers. Finally, at the end of the last circuit evaluation, FHE ciphertexts or 2PC output has to be decrypted. Again, this is fairly simple, and we skip details for now. We only consider the first two cases of converting 2PC output to FHE input and FHE output to 2PC input.

Intuition. Our conversions focus on Boolean sub-circuits $C^{\textsf{Bool}}_i$. We design mechanisms which either convert 2PC output of $C^{\textsf{Bool}}_i$ to FHE ciphertexts serving as input to $C^{\textsf{Arith}}_{i+1}$ or convert FHE ciphertexts coming from $C^{\textsf{Arith}}_{i-1}$ into input to $C^{\textsf{Bool}}_i$. Each of our two conversions first modifies $C^{\textsf{Bool}}_i$ and evaluates the modified circuit using three new cryptographic building blocks which we call ZK Protocol (1), ZK Protocol (2), and ZK Protocol (3). Each ZK Protocol takes as input a Boolean circuit and $P_1$’s and $P_2$’s input bits. ZK Protocol (1) and ZK Protocol (2) also take FHE ciphertexts as inputs. Each ZK Protocol again modifies the input circuit internally, 2PC-evaluates the modified version, and outputs 2PC output together with a ZK proof which proves certain relations between input and output in zero-knowledge for malicious security. As ZK Protocols are general, their interesting property is to be stackable, i.e., they can be combined with each other. Their internal circuit modification schemes will be merged, and only ZK proofs enclosing circuit modification have to be adapted, which is rather mechanical.

ZK Protocols. Let $\gamma$ be any Boolean circuit defined by its input and output bits as $(\omega _{1},\ldots ,\omega _{n})=\gamma ((\iota _{1,1},\ldots ,\iota _{1,\ell _1}),(\iota _{2,1},\ldots ,\iota _{2,\ell _2}))$. Parties $P_1$ and $P_2$ want to evaluate this circuit with 2PC. Bits $\iota _{1,i}$ are inputs of $P_1$. Bits $\iota _{2,i}$ are inputs of $P_2$, and $\omega _i$ will be output bits known to $P_2$. From a high level, our three ZK Protocols implement:

• ZK Protocol (1). $P_1$ sends homomorphic ciphertexts $c_{1,i}\leftarrow \textsf{Enc}(\iota _{1,i})$, encrypting their input bits $\iota _{1,i}$ to $P_2$. Circuit $\gamma$ is evaluated, and $P_2$ receives output. $P_1$ proves in ZK to $P_2$ that $c_{1,i}$ encrypts $\iota _{1,i}$, used during 2PC evaluation of $\gamma$.

• ZK Protocol (2): $P_2$ sends homomorphic ciphertexts $c_{2,i}\leftarrow \textsf{Enc}(\iota _{2,i})$, encrypting their input bits $\iota _{2,i}$ to $P_1$. Circuit $\gamma$ is evaluated, and $P_1$ receives output. $P_2$ proves in ZK to $P_1$ that $c_{2,i}$ encrypts $\iota _{2,i}$, used during 2PC evaluation of $\gamma$. This is ZK Protocol (1) with roles of $P_1$ and $P_2$ reversed.

• ZK Protocol (3): Circuit $\gamma$ is evaluated, and $P_2$ receives output $\omega _i$. Party $P_2$ sends homomorphic ciphertext $c_{\omega ,i}\leftarrow \textsf{Enc}(\omega _i)$ and proves in ZK to $P_1$ that $c_{\omega ,i}$ really encrypts $\omega _i$ received during 2PC evaluation to $P_1$.

Observe the different notation used in this paper for describing circuits. Boolean sub-circuits of function F are written as $C^{\textsf{Bool}}_i$, while Boolean circuits we use inside our ZK Protocol building blocks are written with the Greek letter $\gamma$.

Conversion. The main idea behind the actual conversion is to modify a circuit $C^{\textsf{Bool}}_i$ into $\gamma$ which takes shares of $C^{\textsf{Bool}}_i$’s original input as its input and outputs shares of $C^{\textsf{Bool}}_i$’s original output. For example, to convert a 2PC output bit $\omega _1$ of $C^{\textsf{Bool}}_i$ to an FHE ciphertext $\textsf{Enc}(\omega _1)$, we do not evaluate $C^{\textsf{Bool}}_i$, but $\gamma$ which outputs share $\omega _1\oplus {}s$ to $P_2$, and s to $P_1$. Both parties encrypt their shares, exchange resulting ciphertexts, and homomorphically compute an XOR to get $\textsf{Enc}(\omega _1)$. During this conversion, ZK Protocols prove the correctness of operations.

So, we design conversion schemes combining multiple 2PC circuit modification techniques with efficient ZK proofs. Together, modifications and proofs prove correctness of output conversion between outputs of 2PC and FHE circuit evaluation.

Semi-honest Security. Our presentation concentrates on the case of fully malicious security. Nevertheless, even the semi-honest version of our conversion is of interest, as it enjoys the same properties as the fully-malicious version, e.g., O(1) rounds, support for $d\ge {}2$ parties, and moreover its performance is competitive when compared to related work, see Sect. 4.4. Essentially, the semi-honest version is just the fully-malicious one as described in the next section, but does not include the actual FHE ZK proofs inside ZK Protocols.

3 Technical Details

For simplicity, we describe details for $d=2$ parties and extend to $d\ge {}2$ in Appendix B.

For their input bit strings $I_1,I_2\in \{0,1\}^{*}$ and function F, parties $P_1$ and $P_2$ want to compute $O=F(I_1,I_2),O\in \{0,1\}^{*}$. Function F is represented as a circuit composition of Boolean and arithmetic sub-circuits $F=(C_m\circ \cdots \circ {}C_1)$. Observe that if the ${i}^{\text {th}}$ sub-circuit is Boolean, then the ${i+1}^{\text {th}}$ is arithmetic and the other way around. We now turn toward technical details on how we enable maliciously-secure mixed-technique evaluation of sub-circuits. We show how to convert 2PC evaluation output of a Boolean sub-circuit $C^{\textsf{Bool}}_i$ into input for a following arithmetic sub-circuit $C^{\textsf{Arith}}_{i+1}$ for FHE evaluation and the other way around.

2PC Output Bits for $P_1$ In a typical garbled circuit evaluation of $C_i$, only $P_2$ receives output, i.e., bits $o_j$. If a specific bit $o_j$ is a secret output bit for $P_1$, then a standard trick is denying $P_2$ to open the last wire label for $o_j$ and forwarding the label to $P_1$. As $P_1$ knows both possible labels for $o_j$, they can recover bit $o_j$. Also, this ensures that $P_1$ receives the correct output bit $o'_j$ from $P_2$, i.e., authenticity [6]. We silently rely on this trick for secure computation of all of $P_1$’s plain output bits for the rest of the paper.

Notation. Let $\textsf{Commit}$ denote a computationally hiding and binding commitment scheme. For some bit string $B\in \{0,1\}^*$, computational security parameter $\lambda '$, and randomness $R\in \{0,1\}^{\lambda '}$, $\textsf{Commit}(B,R)$ outputs a commitment $\textsf{Com}$. In the full version of this paper [10], we show how to efficiently realize commitments with a white-box use of wire labels in garbled circuits. Encryption $\textsf{Enc}$ over plaintext space M is fully (or somewhat) homomorphic. Both parties have already set up a key pair, where the public key is known to both parties, but the private key is shared. For homomorphic operations on ciphertexts, we use the intuitive notation of “$+$” for homomorphic addition, “$\cdot$” for scalar multiplication, and $\oplus$ for homomorphic XOR. So for example, if x and y are from M, then $\textsf{Dec}(\textsf{Enc}(x)+\textsf{Enc}(y))=x+y$. During conversion, we will randomly select scalars from $\mathbb {Z}_p$, where p is a prime of $\lambda$ bits.

Let $\varPi$ be the set of two single bit permutations $\pi :\{0,1\}\rightarrow \{0,1\}$. That is, $\varPi =\{\pi _0,\pi _1\}$ with $\pi _0(x)=x$ and $\pi _1(x)=1-x$.

3.1 ZK Protocols

Let $(\omega _{1},\ldots ,\omega _{n})=\gamma ((\iota _{1,1},\ldots ,\iota _{1,\ell _1}),(\iota _{2,1},\ldots ,\iota _{2,\ell _2}))$ be any Boolean circuit which parties $P_1$ and $P_2$ want to evaluate using maliciously secure 2PC. Bits $\iota _{1,i}$ are $P_1$’s input, and bits $\iota _{2,i}$ are $P_2$’s input.

Fig. 1.

ZK Protocol (1) for circuit $\gamma$

Fig. 2.

Definition of circuit $\gamma ^{(1)}{}$

ZK Protocol (1). In this protocol, $P_1$ proves to $P_2$ that homomorphic ciphertexts $c_{1,i}\leftarrow \textsf{Enc}(\iota _{1,i})$ encrypt all of $P_1$’s input bits $\iota _{i,i}$ used during a 2PC evaluation of $\gamma$. Assume that $P_1$ has already sent the $c_{1,i}$ to $P_2$.

The protocol is depicted in Fig. 1 and consists of two core building blocks: first, parties evaluate a modification of circuit $\gamma$ which we call $\gamma ^{(1)}{}$. We define circuit $\gamma ^{(1)}{}$ by specifying its input and output in Fig. 2. The second building block is an actual three move ZK proof which encompasses $\gamma ^{(1)}{}{}$.

First, $P_1$ selects a random masking bit $\mu _i$ and sends both $c_{1,i}$ and $m_i\leftarrow \textsf{Enc}(\mu _i)$ to $P_2$. At the same time, $P_2$ selects a random choice bit $\sigma _i$. Then, both parties use maliciously-secure 2PC and evaluate $\gamma ^{(1)}{}$ which internally computes $\gamma$ as a sub-routine. Party $P_1$ is the garbler and $P_2$ the evaluator. In addition to outputting the same bits as $\gamma$, it also outputs bit $t_i = \iota _{1,i}\oplus \mu _i$ (if $\sigma _i=0$) or $t_i=\mu _i$ (if $\sigma _i=1$) to $P_2$.

After 2PC, $P_2$ reveals their choice $\sigma _i$. If $\sigma _i=0$, then $P_1$ proves in ZK that the homomorphic XOR of ciphertexts $c_{1,i}$ and $m_i$ to $\textsf{Enc}(\iota _{1,i}\oplus \mu _i)$ really encrypts $t_i=\iota _{1,i}\oplus \mu _i$. If $\sigma _i=1$, then $P_1$ proves that $m_i$ encrypts $t_i=\mu _i$.

Output bit $\alpha =0$ in $\gamma ^{(1)}{}$ indicates protocol failure, i.e., non-matching commitments.

If $\sigma _{i,j}=0$, then $P_1$ and $P_2$ homomorphically compute $\text {ciphertext}_{i,j}=\textsf{Enc}(\iota _{1,i}\oplus \mu _{i,j})$ out of $c_{1,i}$ and $m_{i,j}$. If choice bit $\sigma _{i,j}=1$, then both parties set $\text {ciphertext}_{i,j}=m_{i,j}$. Party $P_1$ then sends a ZK proof that $\text {ciphertext}_{i,j}$ encrypts $t_{i,j}$ to $P_2$, e.g., by applying an efficient framework for ZK proofs [2].

Note the general structure of ZK Protocol (1), which is similar in the other two ZK Protocols. Each ZK Protocol comprises a circuit modification technique, here converting $\gamma$ to $\gamma ^{(1)}{}$, and a surrounding ZK proof. When we will combine ZK Protocols later, we merge circuit modifications, i.e., output of one ZK Protocol’s circuit modification will be input into another. Only surrounding ZK proofs require adoption.

ZK Protocol (2). This protocol reverses $P_1$’s and $P_2$’s roles in ZK Protocol (1). So, circuit $\gamma ^{(2)}{}$ is similar to $\gamma ^{(1)}{}$, with $P_1$ having choice bits (and randomness for commitments to them) as additional input, and $P_2$ has masking bits and commitments to choice bits as input. During 2PC, $P_1$ is the garbler and $P_2$ the evaluator. Also, the actual three-move protocol from ZK Protocol (1) is reversed, i.e., it is $P_2$ who starts by sending encryptions of input bits and masking bits. We omit further details to avoid repetition and refer to Fig. 1.

Fig. 3.

ZK Protocol (3)

ZK Protocol (3). In this protocol, $P_2$ proves to $P_1$ that encryptions $c_{\omega ,i}\leftarrow \textsf{Enc}(\omega _i)$ are encryptions of $P_2$’s output bits $\omega _i$. As ZK Protocol (3) is more involved, Fig. 3 starts by presenting a slightly simpler version with a ZK proof which is only Honest-Verifier-Zero-Knowledge (HVZK), and details for fully-malicious security follow.

As part of ZK Protocol (3), $P_1$ and $P_2$ run 2PC on a modification of circuit $\gamma$ called $\gamma ^{(3)}{}$, defined in Fig. 4.

Fig. 4.

Definition of circuit $\gamma ^{(3)}{}$

Before 2PC, $P_1$ selects, for an output bit $\omega _i$, two random bit strings $v_{0,1}\ldots {}v_{0,\lambda }$ and $v_{1,1}\ldots {}v_{1,\lambda }$ and sets $V_0=0||v_{0,1}\ldots {}v_{0,\lambda },V_1=1||v_{1,1}\ldots {}v_{1,\lambda }$. Here, “||” denotes concatenation, and $\lambda$ is a statistical security parameter. Then, $P_1$ encrypts and sends ciphertexts $\varGamma _0=\textsf{Enc}(V_0)$ and $\varGamma _1=\textsf{Enc}(V_1)$ to $P_2$. Circuit $\gamma ^{(3)}{}$ does not output $\omega _i$ to $P_2$, but instead outputs $V_{\omega _i}$ to $P_2$, i.e., either bit string $V_0$ or bit string $V_1$.

The first bit of strings $V_0,V_1$ is output bit $\omega _i$. That is, $\varGamma _{\omega _i}$ encrypts a bit string, where the first bit represents $P_2$’s output bit $\omega _i$. So, after evaluating $\gamma ^{(3)}{}$, $P_2$ gets $\omega _i$ and a length $\lambda$ bit string $(v_{\omega _i,1},\ldots ,v_{\omega _i,\lambda })$.

The trick is now that $P_2$ proves in ZK to $P_1$ that it knows a string $V_{\omega _i}$ which is either $V_0$ or $V_1$ and which matches encryption $c_{\omega ,i}$. Recall that the private key for homomorphic encryption $\textsf{Enc}$ is shared between $P_1$ and $P_2$, so none of the two parties can decrypt a ciphertext alone. After evaluating $\gamma ^{(3)}{}$, party $P_2$ sends $\lambda +1$ ciphertexts $c_{\omega ,i}\leftarrow \textsf{Enc}(\omega _i),\textsf{Enc}(v_{\omega _i,1}),\ldots ,\textsf{Enc}(v_{\omega _i,\lambda })$ to $P_1$. Both parties use these ciphertexts to homomorphically generate $\varGamma _2=\textsf{Enc}(V_{\omega _i})$, an encryption of the concatenation of $P_2$’s $\lambda +1$ bits $V_{\omega _i}$. As both parties know $\varGamma _0$ and $\varGamma _1$, they both homomorphically compute $\varDelta _0=\textsf{Enc}(V_{\omega _i}-V_0)$ and $\varDelta _1=\textsf{Enc}(V_{\omega _i}-V_1)$. Observe that, if $V_{\omega _i}$ is either $V_0$ or $V_1$, then one of $\varDelta _0, \varDelta _1$ encrypts a 0. Consequently, $P_2$ proves to $P_1$ in ZK that either $\varDelta _0$ or $\varDelta _1$ is an encryption of 0 (see below for details). If $P_1$ successfully verifies proofs, parties jointly decrypt $\varDelta '_{i,\pi (0)}$ and $\varDelta '_{i,\pi (1)}$. Note that decryption must include a ZK proof by $P_2$ about correct (partial) decryption [2, 7, 11].

We run the above techniques for each output bit $\omega _i$ in parallel.

ZK Proof of 0. Figure 3 also comprises details for the ZK proof, where $P_2$ proves that either $\varDelta _{i,0}$ or $\varDelta _{i,1}$ encrypts a zero. In Fig. 3, $P_2$ blinds $\varDelta _{i,0}$ and $\varDelta _{i,1}$ by a random $a_i$ resulting in $\varDelta '_{i,0}$ and $\varDelta '_{i,1}$. Then, $P_2$ prepares sub-ZK proof “Scalar$_i$” which proves that $\varDelta '_{i,0},\varDelta '_{i,1}$ are the result of multiplying $\varDelta _{i,0},\varDelta _{i,1}$ by the same secret scalar $a_i$. Such a proof is standard, e.g., $P_2$ could simply publish the encryption of $a_i$, and $P_1$ computes $\varDelta '_{i,0},\varDelta '_{i,1}$ themselves. Party $P_2$ completes the ZK proof by re-encrypting $\varDelta '_{i,0}$ and $\varDelta '_{i,1}$, choosing a random 1-bit permutation $\pi$ from $\varPi$, and preparing ZK proof Shuffle$_i$ which proves that $(\varDelta '_{i,\pi (0)},\varDelta '_{i,\pi (1)})$ is a random shuffle of $(\varDelta '_{i,0},\varDelta '_{i,1})$. Proofs of two-element shuffles are also straightforward. For example, $P_2$ could encrypt a random bit to ciphertext $\beta$, send $\beta$ to $P_1$, and prove that ciphertext $\beta -\beta ^2$ encrypts a 0. This standard technique to prove a shuffle is working for, e.g., FHE schemes with plaintext domain over prime fields GF(p) such as Fan and Vercauteren [24] and derivatives (SEAL). Other FHE schemes might use other types of shuffle proofs. Such proofs can be also implemented by, e.g., reverting to an efficient general proof [2] or by opening randomness of ciphertext $\beta -\beta ^2$. Finally, $P_1$ computes $\varDelta '_{i,\pi (0)}=\beta \cdot \varDelta '_{i,0}+(\textsf{Enc}(1)-\beta )\cdot \varDelta '_{i,1}$ and $\varDelta '_{i,\pi (1)}=(\textsf{Enc}(1)-\beta )\cdot \varDelta '_{i,0}+\beta \cdot \varDelta '_{i,1}$ themselves.

HVZK to Fully-Malicious Security. For fully-malicious security, we replace 2PC evaluation of $\gamma ^{(3)}{}$ from Fig. 3 by using ZK Protocol (1). More specifically, instead of 2PC evaluation of $\gamma ^{(3)}{}$, we run ZK Protocol (1) for circuit $\gamma ^{(3)}{}$ with both the $\iota _{1,i}$ and the $v_{i,0,j},v_{i,1,j}$ as $P_1$’s input bits, and the $\iota _{2,i}$ as $P_2$’s input bits. To run ZK Protocol (1), $P_1$ sends encryptions $\varGamma _{i,0,j},\varGamma _{i,1,j}$ to $P_2$ (as well as dummy encryptions of the $\iota _{1,i}$). As a result of running ZK Protocol (1) of $\gamma ^{(3)}{}$ instead of direct 2PC of $\gamma ^{(3)}{}$, $P_2$ can verify that the $\varGamma _{i,0},\varGamma _{i,1}$ are correct encryptions of $P_1$’s input to $\gamma ^{(3)}{}$. Note that the output bits received by $P_2$ after running ZK Protocol (1) comprise all output bits of circuit $\gamma ^{(3)}{}$.

3.2 Composition of ZK Protocols

Our ZK Protocols can be composed in a natural way, i.e., ZK Protocol (1), (2), and (3) can be jointly used on a single circuit $\gamma$. Protocol steps before and after 2PC evaluation of the modified circuit $\gamma$ are executed in parallel. Different modifications of ZK Protocols (1) to (3) to circuit $\gamma$ are merged into one large garbled circuit. This large circuit comprises $\gamma$’s and all modifications’ functionality and uses $P_1$’s and $P_2$’s input sets once. Thus, inputs $\iota _{1,i}$ and $\iota _{2, i}$ are only used once and their wires are connected to all sub-functions of the large circuit. All other necessary inputs $\mu _{i,j}$, $\sigma _{i,j}$, and $v_{\omega ,j}$ are present for their respective input and outputs. This ensures the same functionality of the large circuit as the sub-functions due to its security against malicious adversaries. Protocol steps outside of 2PC operate on distinct inputs and hence are non-interfering under parallel composition. We can compose the conversion routines in a natural way. Figures 5 and 6 depict the details of FHE to 2PC conversion and reverse, respectively.

3.3 Security Analysis

ZK Protocols (1) to (3) prove that the plaintext of an FHE ciphertext (under a shared key) and the input or output, respectively, of a 2PC are identical. They hence enable to compose FHE computations with 2PC protocols in a joint, maliciously secure protocol.

Theorem 1

(Proof in Appendix C). ZK Protocols (1) to (3) are (a) complete, i.e., an honest verifier accepts the proof, if the prover provides consistent input, (b) zero-knowledge, i.e., any verifier learns nothing about the prover’s witness except that it satisfies the proof, and (c) sound, i.e., an honest verifier rejects the proof with overwhelming probability in the security parameter $\lambda$, if the prover’s secret input is not a witness for the proof.

Fig. 5.

FHE to 2PC conversion

Fig. 6.

2PC to FHE conversion

4 Application to Private Set Disjointness

To indicate their usefulness, we apply our mixed-technique conversions to the area of private set analytics. In particular, we design a new solution to the problem of securely, yet efficiently computing private set disjointness (PSD). In PSD, parties compute whether their sets’ intersection is empty without revealing the intersection itself. While protocols computing PSD have been presented before [20, 25, 30, 37, 38, 48, 67], our new solution features several advantages which, in combination, is unique: any number of $d\ge {}2$ parties, fully-malicious security, circuit-based computations, and high efficiency (also due to a constant number of rounds). Computing PSD with a circuit-based approach is of special interest, as variations of PSD, like whether the size of the intersection is larger than a threshold, or other set statistics can then be computed easily, see discussions in [56, 58].

Each party $P_i$ has an n element input set $S_i=\{e_{i,1},\ldots ,e_{i,n}\}$ with elements $e_{i,j}\in \{0,1\}^\ell$. We present a protocol where parties securely compute whether the intersection of the $S_i$ is empty, i.e., $|\bigcap _{i=1}^d{S_i}|{\mathop {=}\limits ^{?}}0$. Crucially, we do not leak the size of the intersection or any other information about the intersection or elements $e_{i,j}$. Assume that parties have previously computed a distributed private key with corresponding public key for a fully or somewhat homomorphic encryption scheme. Separately, each party $P_i$ has a public-private key pair, where the public key is known to all parties. So, parties can securely communicate.

4.1 PSD Protocol Overview

We present a new circuit-based approach to compute PSD. At its core, parties compare their elements by evaluating a Boolean sub-circuit with pairwise 2PC in a star topology. The outcome of 2PC comparisons then serves as input to FHE evaluations.

Hash Table Preparation. Initially, parties hash their input elements into hash tables. This is a typical approach of recent protocols for PSI, see Pinkas et al. [57] for an overview. Specifically, each party $P_i$ starts by creating an empty hash table $T_i$ with $m\in {}O(\frac{n}{\log {n}})$ buckets. To cope with possible hash collisions with very high probability, each bucket comprises a total of $\beta \in {}O(\log {n})$ entries [59, 61]. Each entry has space to store $\ell$ bits. Let $T_{i}[j,k]$ denote the ${k}^{\text {th}}$ entry in the ${j}^{\text {th}}$ bucket $T_i[j]$ of $P_i$’s hash table $T_i$.

After initializing hash table $T_i$, each party $P_i$ iterates over their input elements, writing element $e_{i,j}$ into bucket $T_i[h(e_{i,j}),u]$, where u is the first empty entry in $T_i$’s ${m}^{\text {th}}$ bucket. All remaining entries in the hash table are filled with random bit strings.

Mixed-Circuit Evaluation. Parties elect a leader, w.l.o.g. the leader is $P_1$. The main idea to compute PSD is that, for a randomly chosen r, the following function F is evaluated securely:

$$F=r\cdot \sum _{j=1}^{m} \sum _{k=1}^{\beta } \prod _{i=2}^{d}\left[ \bigvee _{u=1}^{\beta } (T_{1}[j,k] {\mathop {=}\limits ^{?}} T_{i}[j,u])\right] .$$

Function F implements PSD, as sets $S_i$ are disjoint iff F evaluates to 0. The rationale behind F is that the intersection is not empty if and only if there exists an entry in a bucket of $P_1$’s table which equals an entry of the same bucket in all other parties’ tables.

We already define F using a mixed arithmetic and Boolean notation, suggesting a direct application of our mixed-techniques for 2PC-FHE evaluation. To securely evaluate F, we set up a simple star topology where leader $P_1$ interacts pairwise with each other party $P_i$ to compute inner parts $f_{i,j,k}= \left[ \bigvee _{u=1}^{\beta } (T_{1}[j,k] {\mathop {=}\limits ^{?}} T_{i}[j,u])\right]$ with 2PC. For the ${k}^{\text {th}}$ entry in their ${j}^{\text {th}}$ bucket $T_{1}[j,k]$, $P_1$ evaluates with $P_i$ a separate 2PC circuit which implements $f_{i,j,k}$. Using our 2PC to FHE conversion, output of each $f_{i,j,k}$ 2PC evaluation is a homomorphic encryption of its output bit which we denote by $\textsf{Enc}(f_{i,j,k})$. After all 2PC computations, $P_1$ sends the $\textsf{Enc}(f_{i,j,k})$ to all other parties which continue computing F homomorphically.

The final multiplication of the output by (a random) r in the encrypted domain is realized by each party $P_i$ randomly selecting $r_i{\mathop {\leftarrow }\limits ^{\$}}{}M$ and sending $\textsf{Enc}(r_i)$ to other parties. All parties homomorphically compute $\textsf{Enc}(r)=\sum _{i=1}^{d}\textsf{Enc}(r_i)$ and multiply the output by $\textsf{Enc}(r)$ to get $\textsf{Enc}(F)$ which is then jointly decrypted. Without multiplying by r, parties would learn the size of the intersection.

4.2 Malicious Security for PSD

Although 2PC, our conversion, and homomorphic evaluations are secure against malicious adversaries, we need to extend our current security model from two parties to the case of d parties. A few conditions apply to PSD that make this extension efficient. First, each party $P_i$ (except $P_1$) provides input only once, and all 2PCs are independent of other parties’ inputs. In consequence, no input commitments from $P_i$ are necessary, and only $P_1$ needs to use commitments. Furthermore, since there exists a pair of inputs for any output of the 2PC, the output of a 2PC between two malicious parties can be simulated with chosen inputs. Consequently, we now show that adding our ZK protocols leads to a multi-party protocol secure in the malicious model, despite the fact that both parties of a two-party computation can be malicious (including the leader). We leave the secure composition of 2PC to MPC in the star topology for the general case, when these conditions are not met, as future work.

Recall that after 2PC to FHE conversion, both parties $P_1$ and $P_i$ have proven to each other correct computation of $c=\textsf{Enc}(s)$ and $c'=\textsf{Enc}(s')$. They homomorphically combine c and $c'$ to $\textsf{Enc}(f_{i,j,k})=\textsf{Enc}(s\oplus {}s')$. The new challenge when dealing with $d>2$ parties is that both $P_1$ and $P_i$ can be malicious, fabricate various different $\textsf{Enc}(f_{i,j,k})$, and send different $\textsf{Enc}(f_{i,j,k})$ to different other parties.

To mitigate, one could somehow run ZK proofs in public such that all other parties automatically observe the correct $\textsf{Enc}(f_{i,j,k})$, but this is expensive. A more elegant solution would be that both parties $P_1$ and $P_i$ sign $\textsf{Enc}(f_{i,j,k})$ at the end of their conversion, and $P_i$ sends their signature to $P_1$. Then, $P_1$ could use secure echo broadcast [27] to send $\textsf{Enc}(f_{i,j,k})$ and both signatures of $\textsf{Enc}(f_{i,j,k})$ to all parties. As a result, all parties would receive the same $\textsf{Enc}(f_{i,j,k})$ and verify that $P_1$ and $P_i$ have agreed on it.

An interesting situation occurs when both $P_1$ and $P_i$ are malicious and agree on a wrong $\textsf{Enc}(f_{i,j,k})$. For example, $P_1$ and $P_i$ could agree on $\textsf{Enc}(0)$ even though $P_i$ has an entry $e_{i,u}$ in its ${j}^{\text {th}}$ bucket which equals an entry $e_{1,k}$ in $P_1$’s ${j}^{\text {th}}$ bucket. Note that this is not an attack, as the adversary can anyway control $P_i$’s input and set it to arbitrary values. So, the above case would be equivalent to the adversary setting $P_i$’s input $e_{i,u}$ to something different from $e_{1,k}$ in the first place. The only property $P_1$ and $P_i$ have to prove to all other parties is that ciphertext $\textsf{Enc}(f_{i,j,k})$ encrypts a bit.

As neither $P_1$ nor $P_i$ know $f_{i,j,k}$, we use a different strategy. Party $P_1$ proves in ZK that c encrypts a bit, and $P_i$ proves that $c'$ encrypts a bit. Parties broadcast c and $c'$ with both proofs. Using c and $c'$ all parties compute $\textsf{Enc}(f_{i,j,k})$ homomorphically.

Finally, to force $P_1$ to always use the same inputs during pairwise comparisons with different $P_i$, we require $P_1$ to initially commit to its input using FHE ciphertexts and securely broadcast those ciphertexts to all other parties. The consistency of inputs is then verified using ZK Protocol (1).

Joint Decryption. Recall that the 2PC to FHE conversion internally runs ZK Protocol (3) and requires a joint decryption between $P_1$ and $P_i$. In case of $d>2$ parties, joint decryption is still possible, but involves all d parties. So, both $P_1$ and $P_i$ broadcast a request to decrypt the current $\varDelta '_{i,\pi (0)}$ and $\varDelta '_{i,\pi (1)}$, and all parties reply to $P_1$ with their share of the decryption (plus proof of correct decryption). Note that this does not change our total message complexity. We need to run O(1) broadcasts for each $f_{i,j,k}$ anyway.

4.3 Complexity Analysis

Due to space constraints, we present and compare asymptotic complexities of our techniques for evaluating F with related schemes in the full version of this paper [10].

4.4 Implementation

We have implemented our private set disjointness variant with 2PC to FHE conversion and performed micro-benchmarks. We will release our code into open source upon publication of the paper.

Table 1. Online time (s) to evaluate F, our scheme vs semi-honest and maliciously secure SPDZ [35] vs BMR [34] vs FHE. 2PC: communication time for circuit evaluation of all $m\beta {}d$ circuits $((\gamma _{\textsf{Share}}{}'(1))(3))(1)$, BC: communication time for broadcasting shares and partial decryptions, FHE Comp: computation time for arithmetic part, DNF: does not finish in 15 min. Benchmarks from single 1.6 GHz Core i5, 32 GB RAM

Our implementation of 2PC-part $f_{i,j,k}$ is done in the framework by Wang et al. [65] and maliciously secure. Yet, none of the common FHE libraries (HELib, PALISADE, SEAL, TFHE) provides both distributed key generation with threshold encryption and ZK proofs, which we need for maliciously-secure conversion. Moreover, an implementation of a FHE scheme with threshold decryption and ZK proofs, e.g., based on the one by Asharov et al. [2], deserves its own paper. Thus, for the arithmetic part of F, we have only implemented and benchmarked arithmetic operations with FHE (using TFHE [16, 17] for its simplicity), but not FHE ZK proofs, i.e., a semi-honest secure conversion. We dub the security setting of our implementation as “semi-malicious”: 2PC is maliciously secure, but the conversion is only semi-honest secure. This setting is at least as strong as semi-honest security, but weaker than malicious security.

More specifically, we have implemented the actual circuit which is evaluated as part of the 2PC to FHE conversion of $f_{i,j,k}$, namely $((\gamma _{\textsf{Share}}{}'(1))(3))(1)$. Here, circuit $\gamma _{\textsf{Share}}{}'$ is the modification to $f_{i,j,k}$ due to conversion, $\gamma _{\textsf{Share}}{}'(1)$ is the modification implied by ZK Protocol (1) on top of that, $(\gamma _{\textsf{Share}}{}'(1))(3)$ the modification by ZK Protocol (3) on top of that, and $((\gamma _{\textsf{Share}}{}'(1))(3))(1)$ the modification by ZK Protocol (1) running inside ZK Protocol (3).

For all benchmarks, we set $m=\frac{n}{2}$, $\beta =\log {n}$, and consider $\ell =32$ bit integers as the elements in each party’s set. It is well known that communication time due to latency between parties is a dominating factor regarding total runtime, especially for the 2PC part. For example, raw computation time of evaluating a single $((\gamma _{\textsf{Share}}{}'(1))(3))(1)$ circuit for $\beta =5$ takes only 1.2 ms on a single 1.6 GHz Core i5 with 32 GB RAM, but all computations can run in parallel on different cores. So, an Amazon EC2 C5d instance with 96 cores computes 80, 000 circuits per second. However, network traffic, i.e., exchanging 177 KByte of data between $P_1$ and $P_i$ during evaluation of that circuit, cannot be parallelized. Instead, we can only sequentially send all data for all circuits, and network latency is here the crucial parameter. While latency of (intercontinental) WAN traffic is often unstable and can go over 250 ms [64], we run benchmarks on one machine to better control network behavior and use netem [53] to set latency to a modest 70 ms. As a result of this latency, we measured TCP data goodput to be only 330 MBit/s on the localhost network (a higher latency would imply less goodput).

In Table 1, 2PC denotes the time to compute all $((\gamma _{\textsf{Share}}{}'(1))(3))(1)$. BC denotes the time for all broadcasts of shares $c_i,c'_i$ after 2PC to all parties (one TFHE ciphertext has size 2.5 KByte) plus the time to broadcast a partial decryption of the final result after FHE from each party (a partial decryption is one TFHE ciphertext). FHE Comp is the time, for each party, to compute the arithmetic part of F in TFHE.

For comparison, we have also implemented F in the popular MP-SPDZ framework [33] and benchmarked with both their semi-honest (SPDZ$^{\text {SH}}$: no MACs, semi-honest OT [33]) and maliciously secure SPDZ variants [35] as well as BMR [34]. SPDZ Total and BMR Total are their total (online) times to compute F. FHE Total is the total time of a semi-honest “pure-FHE” implementation of F with TFHE, including broadcasting each party’s $m\beta \ell$ ciphertexts to all other parties. Note that BMR crashes even for a small number of parties, e.g., $n=128,d=10$, or quickly runs out of memory ($>32$ GB) for $d\ge {}20$ parties.

Looking at Table 1, our implementation outperforms semi-honest and maliciously secure SPDZ, BMR, and FHE in all considered settings. While SPDZ and BMR are competitive for a small number of parties, BMR fails due to its memory consumption, and our composition from 2PC clearly shows better scalability than SPDZ for larger numbers of parties.

While timings for our “semi-malicious” implementation look promising regarding a potential maliciously secure implementation, we do not have such an implementation for the above stated reasons. However, observing that our techniques outperform even semi-honest SPDZ while offering stronger security guarantees leads to an interesting conclusion of our evaluation. Our mixed-techniques protocols might already serve as an alternative to standard semi-honest MPC in scenarios with a star topology, i.e., where a multi-party protocol can be decomposed into multiple 2PC protocols.

5 Related Work

Mixed-Techniques MPC. Several previous works combine different MPC techniques to mitigate individual techniques’ drawbacks. Kolesnikov et al. [39] are among the first to present a conversion between garbled circuits and (additively) homomorphic encryption in the two-party semi-honest model [39, 41]. Extending their conversion to also support fully-malicious adversaries is non-trivial: in Appendix D of [40], they present honest-verifier zero-knowledge proofs which render the protocol secure only if at most one party is malicious. However, HVZK is insufficient, if proofs are part of a scenario with more than two parties where more than one party can be malicious.

A long line of research has focused on making mixed-techniques practical and efficient. Henecka et al. [29] design practical tools for conversion between garbled circuits and additively homomorphic encryption. Their conversion targets semi-honest adversaries and circuits for two parties. Demmler et al. [22] present a two party framework to convert between arithmetic sharing, Boolean sharing, and garbled circuits in the semi-honest model, and so do Riazi et al. [60]. Mohassel and Rindal [50] extend to three parties with malicious security. Again in the semi-honest model for two parties, Juvekar et al. [32] switch between garbled circuits and additively homomorphic encryption, and Büscher et al. [14] switch between arithmetic and Boolean sharing. The “(e)daBits” line of work [1, 23, 62] converts between MPC based on arithmetic secret sharing and garbled circuits with malicious security. In contrast, our work mixes FHE with garbled circuits, with the advantage of a (low) constant number of rounds during evaluation.

For completeness sake, we mention that other powerful MPC frameworks besides MP-SPDZ exist, e.g., the purely circuit-based EMP-Toolkit [66]. Also note that FHE is often combined with (arithmetic) MPC to prepare multiplication triplets during offline phases, as in, e.g., SPDZ and follow-up works [3, 36].

(Multi-Party) PSI and Disjointness. While seminal works in PSI are based on dedicated protocols [49], recent papers use a circuit-based approach (see Pinkas et al. [55] for an overview), culminating in solutions with asymptotically optimal communication complexity and practical constants [58]. In theory, such circuit-based approaches can be used to also compute disjointness, but they focus on the two-party setting with semi-honest security or multiple parties with semi-honest security [15]. Efficient maliciously-secure multi-party circuit-PSI has not yet been achieved.

Hazay and Venkitasubramaniam [28] present a maliciously-secure multi-party PSI protocol based on oblivious polynomial evaluation (OPE). Similar to previous ideas [25], OPE could then be combined with a maliciously-secure 2PC to compute disjointness. However, already computing the intersection is expensive with this approach, requiring $O(n^2)$ modular exponentiations. Kolesnikov et al. [42] present an efficient multi-party PSI protocol in the semi-honest model using only symmetric encryption. However, more fundamentally, PSI protocols cannot be easily converted into PSI analytics protocols (not disclosing the intersection) while maintaining efficiency [56, 58] and providing malicious security. Other works have considered computing set disjointness, but these target semi-honest security and/or only two parties [20, 25, 30, 37, 38, 48, 67]

Comparing to related work, our work fills a gap with 1) a solution which converts between FHE and garbled circuits, 2) supports any number of parties d, and 3) provides malicious security. We use this to present the first multi-party PSI analytics protocol whose communication complexity scales only quadratically in d.

Appendices

Appendix

A A Supporting Larger Plaintext Spaces

Our presentation describes arithmetic sub-circuits operating over single bits. There, each ciphertext encrypts a single bit and homomorphic operations are over bits. This can be inefficient, as parties often want to compute on larger integers, e.g., 32 Bit integers. Homomorphic encryption schemes anyway operate over large plaintext spaces, where addition of a large, multiple bit integer is a single homomorphic operation. A large plaintext space also allows for SIMD techniques.

To improve performance, we extend conversion from operating over GF(2) plaintexts to operate over arbitrary fields GF(q) by instituting the following two modifications. In our conversions, ZK Protocols, and ZK proofs, we replace using XORs to share a single bit or combine two shares to a bit by additions and subtractions over GF(q). Random bits serving as a share for a party become random elements of GF(q). Second, n single bit encryptions $c_i=\textsf{Enc}(b_i)$ output by our 2PC to FHE conversion are combined to a single n bit encrypted integer by each party computing $\sum ^{n-1}_{i=0}{2^{i}\cdot {}c_{i+1}}$.

B B $d\ge {}2$ Parties

Secure multi-party computation can be constructed from secure two-party computations in various ways. One standard way is a star topology as we present in Sect. 4. We emphasize, however, that our conversions are not limited to star topologies.

The main idea is that each party $P_i$ engages in secure two-party computation with a central party $P_1$ to compute some functionality. Such a centralized approach works for certain functionalities, e.g., equality of inputs, as equality is symmetric and transitive. If $P_i$’s input is equal to $P_1$’s and $P_j$’s input is equal to $P_1$’s, then $P_i$’s input is also equal to $P_j$’s. Hence, computation of the joint result using homomorphic encryption can leverage this relation.

This approach does not apply to other functionalities, e.g., larger-than comparison. If $P_i$’s input is larger than $P_1$’s, and $P_j$’s input is larger than $P_1$’s, then we cannot imply any larger-than relation between $P_i$’s and $P_j$’s input. Consequently, in this case, the alternative to maintain constant-round complexity is to engage all parties in pair-wise comparisons. This has been previously considered, e.g., in the context of sealed-bid auctions [9]. However, the result of each pairwise comparison is leaked in previous work, reducing security to a level comparable with order-preserving encryption. In contrast, constructions in this paper would enable computing the auction result, e.g., the largest input, using homomorphic encryption with constant round complexity.

In summary, there exist several practically relevant protocols with arithmetic relations between inputs which can be decomposed into an initial two-party phase followed by a combination phase of the inputs. We use secure two-party protocols during the first phase to achieve efficient implementations in a constant number of (communication) rounds. Similarly, to evaluate low multiplicative depth sub-circuits, we use homomorphic encryption efficiently. Our ZK protocols ensure that the conversion is secure against malicious adversaries.

C C Proof of Theorem 1

We emphasize that we only provide a proof-sketch that, however, should convince an expert reader about the correctness of our theorems and the security of our protocols. Before presenting this proof sketch of our main Theorem 1, we briefly recall completeness, zero-knowledge, and soundness definitions.

Let $P \in \{ P_1, P_2 \}$ be the prover and $V \in \{ P_1, P_2 \}$ be the verifier in a ZKP. Let $w \in R_C$ be a witness for the correct execution of a conversion which we denote as relation $R_C$. Let $\langle P(w), V \rangle$ be the execution of a ZKP protocol.

Completeness: An honest verifier accepts the proof, if the prover provides consistent input, i.e., $w \in R_C \Longrightarrow \langle P(w), V \rangle \wedge Pr[V = \textsf{accept}] = 1.$

Zero-Knowledge: The verifier learns nothing about the prover’s witness except that it satisfies the proof, i.e., there exists simulator $\textsf{Sim}_P$ such that $\langle P(w), V \rangle {\mathop {=}\limits ^{c}} \langle \textsf{Sim}_P, V \rangle .$

Soundness: An honest verifier rejects the proof with overwhelming probability in security parameter $\lambda$, if the prover’s secret input is not a witness for the proof, i.e., there exists extractor $\textsf{Ext}_V$ such that $V = \textsf{accept} \Longrightarrow \langle P(w), \textsf{Ext}_V \rangle \wedge Pr[\textsf{Ext}_V = w] = 1 - \textsf{negl}(\lambda ).$

Proof

(Theorem 1). Completeness of ZK Protocols (1) to (3) follows immediately from their construction, so we focus on Zero-Knowledge and Soundness.

Zero-Knowledge. To prove zero-knowledge, we construct simulators $\textsf{Sim}_{P_1}$ or $\textsf{Sim}_{P_2}$ in the hybrid model which do not know the witness of the individual ZK Protocols (ZKPs), create views for the adversary which are indistinguishable from the real protocol, and make the verifier accept the proofs. In the hybrid model, simulators can simulate any ZK sub-proofs invoked during the protocol.

First, observe that all messages from the prover to the verifier are semantically-secure ciphertexts, random numbers or other zero-knowledge proofs.

In ZKP (1) and (2), the simulator $\textsf{Sim}_{P_1}$, or $\textsf{Sim}_{P_2}$ (in ZKP (2)), randomly chooses inputs $\iota _{1, i}$ (or $\iota _{2,i}$) and masking bits $\mu _{i,j}$ as their input into 2PC. The verifier inputs $\sigma _{i,j}$ to the 2PC. After the 2PC, the simulator either receives verification bits $t_{i,j}$ (ZKP (1)) or outputs random verification bits (ZKP (2)).

In the last step, we apply the hybrid model. The simulator invokes the simulator of the ZKP for correct decryption using those (random) verification bits and the committed (random) input and masking ciphertexts, simulating a consistent execution of the ZKP.

In ZKP (3), $\textsf{Sim}_{P_1}$ does not have to output verification bits $v_{i,\omega _i,j}$, but the verification is done using ZK proofs Scalar$_i$ and Shuffle$_i$. Hence, the simulator for ZK Protocol (3) chooses a random $\omega _i$ and invokes the simulators for Scalar$_i$ and Shuffle$_i$.

Soundness. To prove soundness for ZKP (1) and (2), we construct extractors $\textsf{Ext}_{P_1}$ or $\textsf{Ext}_{P_2}$. We construct an extractor $\textsf{Ext}_{P_2}$ only for ZKP (1), but stress that the extractor $\textsf{Ext}_{P_1}$ for (2) is equivalent. The extractor starts the ZK proof and lets the prover commit to their inputs via homomorphic ciphertexts $c_{1,j}$ (for a known shared key). Then the extractor chooses challenge bits $\sigma _{i,j}$ and sends them to the 2PC. The prover outputs verification bits $t_{i,j}$. The extractor rewinds the prover to just before they received the challenge bits for the 2PC. The extractor negates all challenge bits to $\lnot \sigma _{i,j}$, sends them to the 2PC and continues the protocol. Let the prover’s verification bits after rewinding be $t'_{i,j}$. We assume that the prover has consistent inputs and hence these inputs are extractable: the prover’s inputs in ZKP (1) are $t_{i,j} \oplus t'_{i,j}$.

The soundness of ZKP (3) is a special case of authenticity of garbled circuits [6], and we do not need an extractor. Challenge bits $v_{i,0,j}$ and $v_{i,1,j}$ are input to the 2PC. Note that the soundness of the ZKP (1) ensures that the entire execution of the verifier is secure against malicious behaviour, including its conversion of the challenge bits from FHE to 2PC. The output depends on the output of the 2PC. Since the prover only evaluates the garbled circuit, it is bound to the correct or no output due to the authenticity property of garbled circuits. It can hence only produce one consistent set of output labels $v_{i, \omega _i, j}$.

This completes our security proof. Note that only the proof of ZKP (3) is recursive to the proof of ZKP (1), and hence all proofs are valid if ordered from (1) to (3). $\square$