Keywords

1 Introduction

Homomorphic Encryption (HE) enables computation over encrypted data without decryption. It prevents the leakage of private information while evaluating data within an untrusted environment. However, HE requires a large resource even when it computes a simple arithmetic operation such as multiplication. As a result, HE is particularly well-suited for implementation in cloud systems that can supply large computing power for evaluation.

A typical HE only supports computations between data encrypted by the same key. Consequently, when multiple data owners are involved, it relies on a trusted third party who possesses a key distributed to each party for encryption. Still, this merely transfers the trust problem from the cloud service provider to the new third party and thus does not provide an acceptable solution to this problem. To overcome this challenge, extensive research has explored the use of distributed trust in designing HE schemes involving multiple parties.

In the context of multiple parties, two important lines of HE schemes have emerged: Threshold HE and Multi-Key HE (MKHE). In Threshold HE [5, 8, 30, 31, 33], multiple parties collaborate to generate a joint public key, and encryption is performed under this joint key. Threshold HE has a t-out-of-n (\(t \le n\)) access structure where any t parties can reconstruct the secret key to decrypt the ciphertext. Studies on Threshold HE are again diverged into two different directions: the case where \(t<n\) and the case where \(t=n\). In our work, we focus on the case when \(t=n\), which is referred as Multi-Party HE (MPHE). Like any other Threhold HE schemes, MPHE is comparable to that of the single-key HE schemes since encryption and homomorphic computation are performed in a similar manner with the joint key. However, the set of participants should be determined beforehand and fixed in the preparation phase and no other parties can join the computation in the middle. Moreover, the existing MPHE schemes are based on a multi-round key generation protocol in which the involved parties should interact with each other.

On the other hand, MKHE [12, 13, 18, 29, 32, 34] features a distributed setup phase where each party independently generates its own key pair, without requiring any information about other participants. The encryption can be done by an individual key, and it allows to perform arithmetic operations on ciphertexts that do not necessarily have to be encrypted under the same key. The main advantage of MKHE lies in its flexibility: it is not necessary to pre-determine the list of participants or the computational task. From the performance perspective, however, the size of ciphertexts increases with the number of involved parties, and so does the complexity of homomorphic operations.

1.1 Our Contributions

Formalization of Multi-group HE. We propose a novel variant of HE designed for multiple parties, called Multi-Group HE (MGHE), and define its security notion. An MGHE scheme can be viewed as a generalization of both MPHE and MKHE, which enjoys the best of both primitives. In MGHE, a group of parties collaboratively generates a public key that is commonly used among the parties for encryption. Hence, MGHE behaves like an MPHE scheme in a single group. Moreover, an MGHE scheme has the capability to perform arbitrary computations on encrypted data, regardless of whether the input ciphertexts are encrypted under the same group key or not, a crucial property of MKHE.

Construction of MGHE. We construct an MGHE scheme and provide a rigorous proof of its semantic security. Our MGHE scheme regards an MPHE ciphertext as a single-key encryption under the joint secret key so that ciphertexts corresponding to different group keys can be operated in a MKHE manner. Consequently, our MGHE scheme has a hierarchical structure where a ciphertext is decryptable by the joint secret keys of the associated groups, each of which is additively shared among the group members. From the perspective of MPHE, it is also the first construction of the MPHE scheme with non-interactive key aggregation where the joint encryption and evaluation keys are obtained from independently generated individual keys by simply summing them.

Building Multi-party Computation Protocol from MGHE. We build a round-optimal Multi-Party Computation (MPC) protocol on top of our MGHE scheme, which is naturally derived from the non-interactive key aggregation (setup). We show that the protocol is secure against semi-malicious adversaries in the dishonest majority setting, relying on the semantic security of MGHE.

Experimental Results. We implement our MGHE scheme based on both BFV and CKKS and provide a basic benchmark compared to the previous MPHE and MKHE works.

1.2 Technical Overview

At the heart of our construction lies a non-interactive key generation algorithm. This allows the joint key of a group to be constructed non-interactively from independently generated keys of the group members. The key generation follows a hybrid construction between MPHE (the encryption key aspects) and MKHE (the relinearization mechanisms).

Fig. 1.
figure 1

A schematic presenting the overall structure of MGHE schemes. Each boxed group of participants acts as an MPHE scheme. The secret keys and ciphertext equations for each group and the entire set of participants (including between groups) are described above.

We assume that each party is identified as a unique index i and let I be a group of parties. The homomorphic property of LWE makes the summation of public and secret key pairs be a valid key pair. To be precise, an MPHE scheme behaves like a single-key HE scheme where the joint secret key \(s=\sum _{i\in I} [s]_i\) is additively shared among the members of I. We make the Common Random String (CRS) assumption to construct a joint public (encryption) key: given a random polynomial \(a\in R_q\), each party \(i\in I\) generates \([b]_i=a\cdot [s]_i+[e]_i \pmod q\) for some error \([e]_i\), then the joint public key is obtained as \(b=\sum _{i\in I} [b]_i \approx a\cdot s \pmod q\). However, it is more challenging to generate a joint evaluation key, especially a relinearization key, because the relinearization key is usually supposed to be an ‘encryption’ of \(s^2\) which has quadratic structure with respect to the individual secrets \([s]_i\). In the previous constructions [5, 31], the key generation procedure involves a multi-round protocol among the parties: (1) parties publish individual encryption keys to build a joint encryption key, then (2) use it to generate ‘encryptions’ of \([s]_i\cdot s\) and broadcast them to construct a joint evaluation key.

To reduce the multiple rounds of the protocol, we propose a new key generation algorithm which is nearly linear with respect to the secret key. This property enables the non-interactive key generation in that each party independently generates and broadcasts its public key \([\textsf{pk}]_i\) once, which adds up to the joint public (encryption and evaluation) key \(\textsf{pk}=\sum _{i\in I}[\textsf{pk}]_i\) corresponding to the joint secret \(s=\sum _{i\in I} [s]_i\).

To construct our MGHE scheme, we apply this key generation protocol to support homomorphic computation between ciphertexts under different keys. For example, if we perform homomorphic computation on MPHE ciphertexts \(\textsf{ct}_j\) under the joint secret keys \(s_j=\sum _{i\in I_j}[s]_i\) of groups \(I_j\) for \(1\le j\le k\), then it outputs a ‘multi-group’ ciphertext under the secret \((s_1, \dots , s_k)\). In particular, the joint public keys of the involved groups themselves are used in the relinearization process of multi-group ciphertexts so that no further interaction is required among the parties. The technical details of our MGHE constructions are described in Sect. 4. Thus, our MGHE scheme behaves as if it is an MKHE scheme in which each key is jointly generated by a group of parties (akin to MPHE). This makes MGHE an ideal generalization of both these HE variants and the hierarchical key structure allows an MGHE scheme to take advantage of strengths of both MPHE and MKHE.

1.3 Related Work

We first remark that the terminology for HE-like primitive has not been agreed upon yet in the literature. We use the terms ‘MPHE’ and ‘MKHE’ to classify the related works.

Asharov et al. [5] designed the first MPHE scheme from BGV [10]. Mouchet et al. [31] proposed a simplified construction from BFV [9, 20] and presented some experimental results. Park [33] recently modified the key generation protocol to reduce the interaction and also suggested a conversion between MPHE and MKHE. To the best of our knowledge, all known MPHE schemes require a multi-round protocol among the parties to generate a shared key pair.

On the other hand, there have been several attempts to construct an MKHE scheme by generalizing single-key HE schemes. López-Alt et al. [29] designed the first MKHE from NTRU [25], and [18, 32, 34] studied multi-key variants of GSW [22]. Then, Brakerski and Perlman [11] presented an LWE-based MKHE [11], followed by Chen et al. [12] who presented a multi-key variant of TFHE [16]. Other works [13, 14] studied MKHE schemes from batched HEs such as BGV [10], BFV [9, 20] and CKKS [15]. Ananth et al. [4] proposed a general methodology to design an MKHE scheme in the plain model. The construction is done by combining an oblivious transfer protocol and MKHE schemes with limited functionality or trusted setup.

We remark that some MKHE schemes can be converted into MGHE: if the key generation algorithm of an MKHE scheme has the homomorphic property, then we can simply operate on the public keys of multiple parties to build a shared key for the group. For example, multi-key GSW schemes [18, 32, 34] hold the condition since GSW does not require an evaluation key for multiplication.

Aloufi et al. [3] combined MPHE and MKHE to perform computation on ciphertexts under two different keys: a joint key of model owners and the other of a client. It can be viewed as a special case of MGHE in which there are two groups consisting of model owners and a client. However, its key generation procedure also involves an interactive protocol to obtain an evaluation key.

Boneh et al. [8] suggested the notion of threshold FHE that has t-out-of-n access structure protocol by splitting the secret key into shares. Its key generation is based on a Shamir secret sharing scheme where each party receives a share of the secret key.

2 Background

2.1 Notation

Let N be a power of two. We denote by \(R={\mathbb Z}[X]/(X^N+1)\) the ring of integers of the (2N)-th cyclotomic field and \(R_q={\mathbb Z}_q[X]/(X^N+1)\) the residue ring of R modulo an integer q. An element of R (or \(R_q\)) is uniquely represented as a polynomial of degree less than N with coefficients in \({\mathbb Z}\) (or \({\mathbb Z}_q\)). We identify \(a=\sum _{0\le i<N} a_i\cdot X^i\in R\) with the vector of its coefficients \((a_0, \dots , a_{N-1})\in {\mathbb Z}^N\). For \(\sigma >0\), we denote by \(D_\sigma \) a distribution over R which samples N coefficients independently from the discrete Gaussian distribution of variance \(\sigma ^2\) and \(\chi \) as a key distribution.

2.2 Ring Learning with Errors

Given the parameters \((N, q, \chi , \sigma )\), consider the samples of the form \(b_i = s \cdot a_i + e_i \pmod q\) for polynomial number of i’s where \(a_i \leftarrow U(R_q)\) and \(e_i \leftarrow D_\sigma \) for a fixed \(s \leftarrow \chi \). The Ring Learning with Errors (RLWE) assumption states that the RLWE samples \((b_i, a_i)\)’s are computationally indistinguishable from uniformly random elements of \(U(R_q^2)\).

2.3 Gadget Decomposition and External Product

A function \(h:R_q\rightarrow R^d\) is called a gadget decomposition if there exists a gadget vector \({\textbf{g}}= (g_i) \in {\mathbb Z}_q^d\) such that \(a=\left\langle h(a), {\textbf{g}}\right\rangle \pmod q\) for all \(a\in R_q\). Typical examples are bit decomposition [9, 10], digit decomposition [16], and Residue Number System (RNS) based decompositions [6, 24]. Our implementation is based on an RNS-friendly decomposition for efficiency.

For \(\mu \in R\), we call \({\textbf{U}}=({\textbf{u}}_0, {\textbf{u}}_1)\in R_q^{d\times 2}\) a gadget encryption of \(\mu \) under a secret s if \({\textbf{u}}_0+s\cdot {\textbf{u}}_1=\mu \cdot {\textbf{g}}+{\textbf{e}}\pmod q\) for some \({\textbf{e}}\) sampled from an error distribution. Chillotti et al. [16] formalized external product operation between RLWE and RGSW ciphertexts. We adopt and generalize this concept as follows: for \(c\in R_q\) and \({\textbf{v}}\in R_q^d\), the external product is defined as \(c\boxdot {\textbf{v}}:=\left\langle h(c), {\textbf{v}}\right\rangle \pmod q\). We also write \(c\boxdot {\textbf{U}}= (c\boxdot {\textbf{u}}_0, c\boxdot {\textbf{u}}_1)\) for \({\textbf{U}}=({\textbf{u}}_0, {\textbf{u}}_1)\in R_q^{d\times 2}\). We note that if \({\textbf{U}}\) is a gadget encryption of \(\mu \) such that \({\textbf{u}}_0+s\cdot {\textbf{u}}_1=\mu \cdot {\textbf{g}}+{\textbf{e}}\pmod q\) for some \({\textbf{e}}\), then the external product \((c_0, c_1)\leftarrow c\boxdot {\textbf{U}}\) satisfies that \(c_0+c_1\cdot s=c\boxdot ({\textbf{u}}_0+s\cdot {\textbf{u}}_1)= c\cdot \mu +\left\langle h(c), {\textbf{e}}\right\rangle \pmod q\) .

The gadget decomposition technique is widely used in HE schemes to reduce the noise growth of homomorphic operations. In addition, it is often combined with the special modulus technique [21]. Although the special modulus technique is applied to the external product in our implementation, we do not describe it in the main body of this paper for simplicity.

3 Formalizing Multi-group Homomorphic Encryption

The ordinary HE schemes support computation on ciphertexts, but the same key should be used for encryption. This major constraint raises the key management problem and makes it difficult to apply the HE technology to a variety of applications. For the last few years, substantial research has been undertaken to solve the issue by distributing the authority of HE system. Currently, there are two main approaches to extend the functionality of HE to the multi-party setting: Threshold HE (ThHE) and Multi-Key HE (MKHE).

First, Threshold HE (e.g.  [5, 8, 30, 31, 33]) is similar to HE, except the fact that the secret key is shared among several parties. In particular, most studies are dedicated to the case of \(t=n\), which we call Multi-party HE (MPHE), while there have been limited results for \(t<n\). In practice, ThHE (or MPHE) schemes are derived from single-key HEs by replacing their key-generation algorithms with distributed protocols, while the evaluation procedures remain the same. To the best of our knowledge, all existing schemes require interaction between the parties to build a relinearization key for multiplication. This approach tends to be more efficient, but it is required to fix the parties at the setup phase which cannot change during the entire operation.

Meanwhile, Multi-key HE (e.g. [12, 13, 18, 29, 32, 34]) is another variant of HE with different pros and cons. In this primitive, each party can generate its own key and use it to encrypt data without any interaction with other users. Moreover, it is possible to evaluate a circuit over ciphertexts under different keys, which results in a multi-key ciphertext decryptable by the associated parties. The MKHE schemes enjoy better flexibility and dynamism since it allows a new party to join the computation anytime. On the other hand, they suffer from relatively poor performance where the space and time complexity grow depending on the number of parties involved in the computation.

In this section, we propose a new variant of HE for multiple parties, called Multi-Group HE (MGHE), which allows the seamless integration of MPHE and MKHE and has the best of both worlds.

3.1 Definition

An MGHE scheme consists of several algorithms and protocols below:

  • \(\texttt{Setup}(1^\lambda , 1^d)\): Given the security parameter \(\lambda \) and the maximal level d, the setup algorithm generates a public parameter set \(\mathsf {{pp}}\).

  • \(\texttt{KeyGen}(\{P_i: i\in I\})\): A set of parties \(\{P_i: i\in I\}\) execute the key-generation protocol to jointly generate a public key \(\textsf{pk}\). Each party \(P_i\) also obtains a secret share \([\textsf{sk}]_i\).

  • \(\texttt{Enc}(\textsf{pk}; m)\): Given a public key \(\textsf{pk}\) and a message m, the encryption algorithm returns a ciphertext \(\textsf{ct}\).

  • \(\texttt{Eval}(\{\textsf{pk}_1, \dots , \textsf{pk}_k; C, \textsf{ct}_1, \dots , \textsf{ct}_k)\): Given a circuit C, ciphertexts \(\textsf{ct}_1, \dots , \textsf{ct}_k\) and their associated public keys \(\textsf{pk}_1, \dots , \textsf{pk}_k\), the evaluation algorithm outputs a ciphertext \(\textsf{ct}\).

  • \(\texttt{DistDec}(\{P_i: i\in I\}; \textsf{ct})\). Given a ciphertext \(\textsf{ct}\), the associated parties execute the distributed decryption protocol and recover a message m.

First of all, the key-generation protocol can be conducted by a set of parties (which we call a group) to build a public key and corresponding secret key shares. A group of parties \(\{P_i: i\in I\}\) will be represented as an index set I. Unlike MPHE, it is not necessary to specify a group at the setup phase, but any group of parties can execute the protocol at any time. In addition, each party may join several groups and run the key-generation protocol with different parties. A data owner needs to pick a public key in the encrypt algorithm so that the output ciphertext is collaboratively decryptable by the corresponding group of parties. We require that an MGHE scheme is semantically secure in the semi-honest model. In other words, the adversary learns no information about the message if at least one party in the group is honest.

The evaluation algorithm of MGHE allows us to compute a circuit on encrypted messages, which are not necessarily encrypted under the same key. To be precise, if we evaluate a circuit over ciphertexts associated with groups \(I_1, \dots , I_k\), then the output ciphertext is no longer decryptable by a single group but its decryption requires all parties in \(I:=I_1\cup \dots \cup I_k\) to be involved in the distributed decryption protocol.

In the security game, we assume that the key-generation protocol is executed honestly by the parties. The correctness guarantees that the output of evaluation and decryption protocols in MGHE is same as the result of the evaluation circuit with plain messages. The security of MGHE indicates that when there is at least one honest party among sets of parties, an encryption for that party does not reveal any information about the message.

Definition 1 (Security)

Let \(I_1, I_2, \dots , I_k\) be sets of parties and let \(I = \cup _{1 \le j \le k}I_j\). Let \(A \subseteq I\) denote the set of adversarial parties and \(H = I \backslash A\). An MGHE scheme is said to be secure if the advantage of \(\mathcal {A}\) in the following game is negligible for any PPT adversary \(\mathcal {A}\):

  • The challenger generates a public parameter \(\mathsf {{pp}}\leftarrow \texttt{Setup}(1^\lambda , 1^d)\).

  • The challenger executes the key generation protocol \(\texttt{KeyGen}(\mathsf {{pp}}, I_j)\) for all \(1\le j\le k\). The challenger sends the public keys \(\textsf{pk}_1, \dots , \textsf{pk}_k\) and secret shares \(\{[\textsf{sk}_j]_i:i\in A, 1\le j\le k\}\) of A to the adversary.

  • The adversary chooses messages \(m_0, m_1 \in \mathcal M \) and picks an index j such that \(I_{j} \nsubseteq A\), and sends them to the challenger. The challenger samples a random bit \(b \in \{0, 1\}\) and sends \(\texttt{Enc}(\textsf{pk}_{j};m_b)\) back to the adversary.

  • The adversary \(\mathcal A\) outputs a bit \(b'\). The advantage is defined as \(\left| \Pr [b=b'] - \frac{1}{2}\right| \).

Definition 2 (Correctness)

Let \(\mathsf {{pp}}\leftarrow \texttt{Setup}(1^\lambda , 1^d)\). For \(1\le i\le k\), let \(\textsf{pk}_i\leftarrow \texttt{KeyGen}(I_i)\) be a public key generated by a set of parties \(\{P_j: j\in I_i\}\) and \(\textsf{ct}_i\leftarrow \texttt{Enc}(\textsf{pk}_i; m_i)\) be an encryption of a message \(m_i\). An MGHE scheme is said to be correct if for any circuit \(C:\mathcal M^k\rightarrow \mathcal M\) whose depth is bounded by d, the following holds with an overwhelming probability in \(\lambda \):

$$\texttt{DistDec}\left( \big \{P_i: i\in \bigcup _{1\le i\le k} I_i\big \}; \texttt{Eval}(\textsf{pk}_1, \dots , \textsf{pk}_k; C, \textsf{ct}_1, \dots , \textsf{ct}_k)\right) = C(m_1, \dots , m_k).$$

3.2 Relations with MPHE and MKHE

Let us explain how MGHE is related with other approaches, MPHE and MKHE. As mentioned before, these primitives differ in various respects such as key structure and functionality. Recall that all parties use the same public key for encryption and evaluation in the MPHE setting, while an MKHE scheme allows each party to generate a key pair independently so that different keys can be involved in the computation.

Our suggestion, the MGHE primitive, can be viewed as a generalization of both primitives. In other words, MPHE and MKHE are special instantiations of MGHE with different group structures. First, suppose that all parties join a single group in the MGHE setting. Then, they share the same key for encryption and the whole evaluation is done within the group, similar to the case of MPHE. Conversely, if each user forms a group alone, then the group key is solely generated and owned by a single party and the evaluation across different parties are performed in the MKHE manner.

Moreover, in these examples, our security definition of MGHE corresponds to the security definitions of MPHE and MKHE. In the single-group case, there is only group to be chosen by the adversary, so the security game is exactly the same as that of MPHE [28]. On the other hand, if every group consists of a single party, then our security game for MGHE defines the ordinary semantic security for (MK)HE.

4 MGHE Construction

In this section, we present a concrete instantiation of MGHE from the BFV scheme. Recall that, in the MGHE setting, we can perform computation over ciphertexts which are not necessarily encrypted under the same key. In addition, our idea is easily applicable to design multi-group variants of other HE schemes such as BGV [10] and CKKS [15]. In particular, we implement MGHE schemes from both BFV and CKKS and present experimental results in Sect. 6. We also provide a formal description of multi-group CKKS in Appendix A.1.

In Sects. 4.1 and 4.2, we outline the basic scheme consisting of setup, key generation, encryption, and decryption of the MGHE scheme. In Sects. 4.3 and 4.4, we provide the algorithms of arithmetic operations and automorphism of MGHE, respectively, with its correctness proof and we provide the security analysis of MGHE in Sect. 4.5.

4.1 Key Generation

In this section, we describe a key generation procedure of our MGHE scheme. Our scheme is based on the CRS model, i.e., all parties have access to the same random string. A parameter set also includes the RLWE dimensions, ciphertext modulus, the key distribution, as well as the error parameter. We firstly explain the setup phase which is a stage to determine some parameters for further procedures with a certain security level before introducing the key generation.

\(\bullet \) \(\underline{\texttt{Setup}(1^\lambda )}\): Set the RLWE dimension N, the plaintext modulus t, the ciphertext modulus q, the key distribution \(\chi \) over R, and the error parameter \(\sigma \). Choose a gadget decomposition \(h:R_q\rightarrow R^d\) with a gadget vector \({\textbf{g}}\in R_q^d\). Sample random vectors \(\textbf{a}, {\textbf{u}}\) and \({\textbf{k}}_1, \dots , {\textbf{k}}_L\) from \(U(R_q^{d})\) where L is the number of different automorphisms to be used in the evaluation process. Return the public parameter \(\mathsf {{pp}}=(N,t,q,\chi , \sigma , {\textbf{g}}, h)\) and common random string \(\mathsf {{crs}}=(\textbf{a}, {\textbf{u}}, {\textbf{k}}_1, \dots , {\textbf{k}}_L)\). We write \(\varDelta =\left\lfloor {q/t}\right\rceil \).

Our scheme generates several CRSs in the setup phase, but this can be implemented efficiently using a keyed pseudo-random function (PRF). This allows us to rely on the CRS assumption for a fixed-size seed, regardless of the number of common random polynomials used for public and automorphism keys.

Recall the definition of MGHE in Sect. 3.1: a group of parties executes the key generation protocol to build a joint public key while each party obtains its own secret. In our construction, the key generation proceeds in two steps of generating individual secret keys and aggregating them into a public key. To be precise, each party \(P_i\) first generates its own key pair \(([\textsf{sk}]_i, [\textsf{pk}]_i)\) and broadcasts the public component \([\textsf{pk}]_i\). We stress that the generation of an individual key pair can be done locally by each party without any interaction with other parties. In the following step, a public key for a group of parties \(\{P_i: i\in I\}\) can be obtained from the individual public keys \([\textsf{pk}]_i\) of the group members. This aggregation can be done by a public cloud without further interaction between the parties. We note that a public key includes an encryption key, a relinearization key for multiplication and automorphism keys for homomorphic rotation.

Note that the individual key generation can be regarded as a preprocessing phase of the key generation protocol since other parties do not affect and thus each party is able to run this protocol at any time. In addition, even if a party belongs to several groups, the party generates only one key pair of its own and uses it several times to create multiple public keys corresponding to the groups that the party belongs to. It makes our construction more efficient because the party does not need to generate a new key pair for each key aggregation step. We guarantee that the MGHE scheme is secure and the security proof is described in Sect. 4.5.

\(\bullet \) \(\underline{\texttt{IndKeyGen}(P_i; \{\psi _\ell \}_{1\le \ell \le L})}\): Each party \(P_i\) generates individual secret and public keys as follows:

  • Sample \([s]_i \leftarrow \chi \) and set the secret key as \([\textsf{sk}]_i=s_i\).

  • Sample \([r]_i\leftarrow \chi \) and \([{\textbf{e}}_{0}]_i,[{\textbf{e}}_{1}]_i,[{\textbf{e}}_{2}]_i \leftarrow D_\sigma ^d\), and compute

    $$\begin{aligned}{}[{\textbf{b}}]_i&=-[s]_i\cdot \textbf{a}+[{\textbf{e}}_{0}]_i \pmod q, \\ [{\textbf{d}}]_i&=-[r]_i\cdot \textbf{a}+[s]_i\cdot {\textbf{g}}+[{\textbf{e}}_{1}]_i \pmod q, \\ [{\textbf{v}}]_{i}&=-[s]_i\cdot {\textbf{u}}-[r]_i\cdot {\textbf{g}}+[{\textbf{e}}_{2}]_i \pmod q. \end{aligned}$$
  • For given automorphisms \(\psi _1, \dots , \psi _L\), sample \([{\textbf{e}}_\ell ']_i\leftarrow D_\sigma ^d\) and compute

    $$[{\textbf{h}}_\ell ]_i = -[s]_i \cdot {\textbf{k}}+ \psi _\ell ([s]_i) \cdot {\textbf{g}}+ [{\textbf{e}}_\ell ']_i \pmod q$$

    for \(1\le \ell \le L\). Set the public key as \([\textsf{pk}]_i= ([{\textbf{b}}]_{i},[{\textbf{d}}]_{i},[{\textbf{v}}]_{i}, [{\textbf{h}}_1]_i, \dots , [{\textbf{h}}_L]_i)\).

\(\bullet \) \(\underline{\texttt{JointKeyGen}(\{[\textsf{pk}]_i:i\in I\})}\): Let I be the index set for a group of parties. Given the collection of public keys \([\textsf{pk}]_i\) with \(i\in I\), compute the public key as \(\textsf{pk}=\sum _{i\in I}[\textsf{pk}]_i\), i.e., \(\textsf{pk}=({\textbf{b}},{\textbf{d}},{\textbf{v}},{\textbf{h}}_1, \dots , {\textbf{h}}_L) \in R_q^{d\times 4}\) where

$$\begin{aligned} {\textbf{b}}=\sum _{i\in I} [{\textbf{b}}]_i,~~~ {\textbf{d}}=\sum _{i\in I} [{\textbf{d}}]_i,~~~ {\textbf{v}}=\sum _{i\in I} [{\textbf{v}}]_i,~~\text {and}~~{\textbf{h}}_\ell = \sum _{i \in I}{[{\textbf{h}}_\ell ]_i} \pmod q \end{aligned}$$

for \(1\le \ell \le L\). Specifically, we denote the encryption key as \(\textsf{ek}=({\textbf{b}}[0], \textbf{a}[0])\), the relinearization key as \(\textsf{rlk}=({\textbf{b}}, {\textbf{d}}, {\textbf{v}})\), and the automorphism keys as \(\textsf{ak}_\ell ={\textbf{h}}_\ell \).

Each component of the public key \([\textsf{pk}]_i\) forms a gadget encryption with a CRS under the secrets \([s]_i\) or \([r]_i\). We call \(s=\sum _{i\in I} [s]_i\) the (implicitly defined) secret key for the group I. The individual secrets \([s]_i\) can be viewed as additive shares of s. Furthermore, the public key \([\textsf{pk}]_i\) is nearly linear with respect to \([s]_i\) and \([r]_i\) so that the joint public key \(\textsf{pk}=({\textbf{b}},{\textbf{d}},{\textbf{v}}, {\textbf{h}}_\ell )_{1 \le \ell \le L}\) satisfies the same properties as the individual keys:

$$\begin{aligned} {\textbf{b}}&\approx -s\cdot \textbf{a}\qquad ~~~ \pmod q, \qquad {\textbf{d}}\approx - r\cdot \textbf{a}+ s\cdot {\textbf{g}}\pmod q \\ {\textbf{v}}&\approx -s\cdot {\textbf{u}}-r\cdot {\textbf{g}}\pmod q, \qquad {\textbf{h}}_\ell \approx -s\cdot {\textbf{k}}_\ell + \psi _\ell (s)\cdot {\textbf{g}}\pmod q \end{aligned}$$

Non-interactive Key Aggregation. In the construction of existing MPHE, the main challenge is to generate the relinearization key for a group of parties. To be precise, the relinearization key of BFV is a key-switching key from \(s^2\) to s, or equivalently, a gadget encryption of \(s^2\) under s. However, the secret key is additively shared among the parties in the multi-party setting, so it is not easy to generate the relinearization key in a distributed manner due to its quadratic structure. Therefore, the existing MPHE schemes [5, 31, 33] had a common limitation in that they rely on a multi-round key generation protocol requiring interaction between the parties.

For instance, the public key generation of [33] consists of two steps: all parties broadcast individual encryption keys \([b]_i\approx a\cdot [s]_i \pmod q\) to build a joint encryption key \(b=\sum _{i\in I}[b]_i\) first, then use it to generate a gadget encryption of \([s]_i\cdot s\) and aggregate them to build a gadget encryption of \(s^2\).

In this work, we solve the issue by introducing a novel key-generation algorithm such that the public key is nearly linear with the corresponding secret key. In other words, our relinearization key has a completely different structure where the summation of \([\textsf{pk}]_i\) for \(i\in I\) becomes a valid public key corresponding to the secret \(\sum _{i\in I}[\textsf{sk}]_i\). Our key-generation algorithm is inspired from the idea of Chen et al. [13] introducing the second secret \([r]_i\) to reconstruct the relinearization key structure. Although the prior method is not nearly linear so cannot be directly used in the MPHE construction, we achieve the desired property by making an additional CRS assumption.

Consequently, our MGHE scheme allows each party to independently generate an individual public key once even without any information about other parties, and the public key for a group can be built on the server by simply adding individual public keys. This ‘non-interactive’ nature of key aggregation offers several advantages, including performance and flexibility. For instance, if a party \(P_i\) belongs to several groups, it suffices to generate a single individual public key \([\textsf{pk}]_i\) and reuse it across all groups, instead of joining the key-general protocol repeatedly once for each group. More discussions on this feature will be given in Sect. 5.1.

4.2 Encryption and Decryption

As explained above, the encryption key \(\textsf{ek}=({\textbf{b}}[0], \textbf{a}[0])\) satisfies \({\textbf{b}}[0]+\textbf{a}[0]\cdot s \approx 0 \pmod q\), so it can be viewed as an RLWE instance with secret s. Therefore, we use the same BFV encryption and decryption algorithms in our scheme as follows.

\(\bullet \) \(\underline{\texttt{Enc}(\textsf{ek}; m)}\): Given a message \(m\in R_p\) and the joint encryption key \(\textsf{ek}\), sample \(w \leftarrow \chi \) and \(e_{0}, e_{1} \leftarrow D_\sigma \). Return the ciphertext \(\textsf{ct}= w\cdot \textsf{ek}+(\varDelta \cdot m+e_0, e_1) \pmod q\).

Suppose that a message m is encrypted using a public key generated by a group of parties \(\{P_i: i\in I\}\). Then, the output ciphertext \(\textsf{ct}=(c_0, c_1)\leftarrow \texttt{Enc}(\textsf{ek}, m)\) satisfies that \(c_0+c_1 s \approx \varDelta m \pmod q\) where \(s=\sum _{i\in I} [s]_i\) is the secret key for the group I. Therefore, it is required to store the information

In our MGHE scheme, it is As we discussed in Sect. 3.1, an MGHE ciphertext holds the references to the associated public keys. In our scheme, each ciphertext stores an ordered set of the involved groups. For example, a fresh ciphertext encrypted by a joint public key \(\textsf{pk}=\sum _{i\in I}[\textsf{pk}]_i\) is linked to the set containing a single element I. More generally, a multi-group encryption of m corresponding an ordered set of k groups \(\{I_1, \dots , I_k\}\) is an \((k+1)\) tuple \(\textsf{ct}=(c_0, c_1, \dots , c_k)\in R_q^{k+1}\) satisfying \(c_0+c_1\cdot s_1+\dots +c_k\cdot s_k=\varDelta \cdot m+e \pmod q\) for some error e where \(s_j=\sum _{i\in I_j} [s]_i\) is the joint secret key of \(I_j\) for \(1\le j\le k\).

Finally, we present a basic (ideal) decryption algorithm and a distributed decryption protocol. For given a ciphertext \(\textsf{ct}=(c_0, \dots , c_k)\) which is linked to k groups \(I_1\), \(\dots \), \(I_k\), the basic algorithm takes as input the joint secret keys \(s_i\) of the associated groups \(I_i\) and recovers the plaintext message while the distributed decryption protocol let the parties in \(\bigcup _{1\le j\le k} I_j\) perform the same computation securely in a distributed manner. As we mentioned before, we describe how to set concrete \(\sigma '\) for the distributed decryption in Sect. 5.2.

\(\bullet \) \(\underline{\texttt{Dec}(\textsf{sk}_1, \dots , \textsf{sk}_k;\textsf{ct})}\): Given a ciphertext \(\textsf{ct}=(c_0, c_1,\dots , c_k)\) and joint secret keys \(\textsf{sk}_j=s_j\) for \(1\le j\le k\), return \(m=\left\lfloor {(t/q) \cdot (c_0+\sum _{1\le j\le k} c_j\cdot s_j)}\right\rceil \pmod t\).

\(\bullet \) \(\underline{\texttt{DistDec}(\{[\textsf{sk}]_i:i\in \cup _{1\le j\le k} I_j\}, \sigma ';\textsf{ct})}\): Let \(\textsf{ct}=(c_0, \dots , c_k)\) be a multi-group ciphertext corresponding to an ordered set of groups \((I_1, \dots , I_k)\). The distributed decryption protocol consists of the following procedures:

  • Partial decryption: Let \(I=\cup _{1\le j\le k} I_j\). Each party \(i\in I\) samples \([e']_i\leftarrow D_{\sigma '}\), then broadcasts \([\mu ]_i=\left( \sum _{1\le j\le k,~i\in I_j}c_j\right) \cdot [s]_i + [e']_i \pmod q.\)

  • Merge: Compute \(m=\left\lfloor {(t/q)\cdot \left( c_0+\sum _{i\in I} [\mu ]_i\right) }\right\rceil \pmod t\).

4.3 Arithmetic Operations

Homomorphic operations include a pre-processing step that aligns the components of input ciphertexts as follows. For given two multi-group ciphertexts, we consider the corresponding ordered sets and compute their union, say \(\{I_1, \dots , I_k\}\). Then, we extend the input ciphertexts by padding some zeros and rearranging their components so that both ciphertexts are decryptable with respect to the same secret \(\overline{\textsf{sk}}=(s_1, \dots , s_k)\) where \(s_j\) is the joint secret of group \(I_j\), \(1\le j\le k\). We assume that this pre-processing is always performed on the input ciphertext and the output ciphertext is linked to the union \(\{I_1, \dots , I_k\}\) of ordered sets even if it is not explicitly mentioned in the algorithm description.

Algorithm 1
figure a

. Relinearization procedure of MGHE

\(\bullet \) \(\underline{\texttt{Add}(\textsf{ct}, \textsf{ct}')}\): Given two ciphertexts \(\textsf{ct}\) and \(\textsf{ct}'\), return the ciphertext \(\textsf{ct}_{add}=\textsf{ct}+ \textsf{ct}' \pmod q\).

\(\bullet \) \(\underline{\texttt{Mult}(\textsf{rlk}_1, \dots , \textsf{rlk}_k; \textsf{ct}, \textsf{ct}')}\): Given two multi-group ciphertexts \(\textsf{ct}=(c_0, \dots , c_k)\), \(\textsf{ct}'=(c_0', \dots , c_k')\) and k joint relinearization keys \(\textsf{rlk}_1, \dots , \textsf{rlk}_k\), compute \(\textsf{ct}_\mathsf {{mul}}= (c_{i,j})_{0\le i,j\le k}\) where \(c_{i,j}=\left\lfloor {(t/q) \cdot c_i c_j'}\right\rceil \pmod q\) for \(0\le i,j\le k\). Return the ciphertext \(\textsf{ct}_\mathsf {{relin}}\leftarrow \texttt{Relin}(\textsf{rlk}_1, \dots , \textsf{rlk}_k; \textsf{ct}_\mathsf {{mul}})\) where \(\texttt{Relin}(\cdot )\) is the relinearization procedure described in Algorithm 1.

We remark that the relinearization algorithm can be shared between our MGHE scheme and the previous MKHE scheme [13] as they have the same ciphertext structure. Our relinearization algorithm is an improvement of the previous method which reduces the number of external products by almost a factor of 2. More formally, the prior algorithm computes lines 8–11 of Algorithm 1 by repeating the following computation iteratively over \(1\le i,j\le k\):

$$\begin{aligned} (c^*_0, c^*_i) \leftarrow (c^*_0, c^*_i) + (c_{i, j} \boxdot {\textbf{b}}_j) \boxdot ({\textbf{v}}_i, {\textbf{u}}) \pmod q. \end{aligned}$$

We observe that \(\sum _{1\le j\le k}c_{i,j}\boxdot {\textbf{b}}_j\) is pre-computable and reusable for the relinearization of multiple ciphertext components. This idea consequently reduces the number of external products down to \(2k^2+2k\) in total, compared to the former method which requires \(4k^2\) external products. We refer the reader to Appendix B for details about the noise analysis.

Correctness of Homomorphic Multiplication. Suppose that \(\textsf{ct}\) and \(\textsf{ct}'\) are encryptions of m and \(m'\) under secret \(\overline{\textsf{sk}}=(s_1, \dots , s_k)\), respectively, and let \(\textsf{ct}_\mathsf {{mul}}=(c_{i,j})_{0\le i,j\le k}=\left\lfloor {(t/q)\cdot \textsf{ct}\otimes \textsf{ct}'}\right\rceil \pmod q\). Then, it satisfies following relation: \(\left\langle \textsf{ct}_\mathsf {{mul}}, (1, \overline{\textsf{sk}})\otimes (1, \overline{\textsf{sk}})\right\rangle \approx \varDelta \cdot mm' \pmod q\). We claim that if \(\textsf{ct}_\mathsf {{relin}}\leftarrow \texttt{Relin}(\{\textsf{rlk}_j\}_{1 \le j \le k}; \textsf{ct}_\mathsf {{mul}})\), then the output ciphertext \(\textsf{ct}_\mathsf {{relin}}=(c_0^*,\dots , c_k^*)\) satisfies \(c_0^*+\sum _{1\le j\le k}c_j^*\cdot s_j\approx \sum _{0\le i,j\le k}c_{i,j}\cdot s_{i}s_j\) and thereby is a valid encryption of \(mm'\).

First, we have

$$c_0^*+\sum _{1\le j\le k} c_j^*\cdot s_j= c_{0,0}+\sum _{1\le j\le k}(c_{0,j}+c_{j,0})\cdot s_j+\sum _{1\le i,j\le k}(c_{i,j}\boxdot {\textbf{d}}_i)\cdot s_j+\sum _{1\le i\le k}c_i''\boxdot ({\textbf{v}}_i+s_i\cdot {\textbf{u}})$$

where \(c_i''=\sum _{1\le j\le k}c_{i,j}\boxdot {\textbf{b}}_j\) from the definition of Algorithm 1.

We also consider the properties \(s_j\cdot {\textbf{d}}_i\approx -r_is_i\cdot \textbf{a}+s_is_j\cdot {\textbf{g}}\approx r_i\cdot {\textbf{b}}_j+s_is_j\cdot {\textbf{g}}\pmod q\) and \({\textbf{v}}_i+s_i\cdot {\textbf{u}}\approx -r_i\cdot {\textbf{g}}\pmod q\) of the joint public keys and deduce the following equations:

$$\begin{aligned} \sum _{1\le i,j\le k} (c_{i,j}\boxdot {\textbf{d}}_i ) \cdot s_j &\approx \sum _{1\le i,j\le k} r_i\cdot (c_{i,j} \boxdot {\textbf{b}}_j) +\sum _{1\le i,j\le k}c_{i,j}\cdot s_is_j\pmod q,\\ \sum _{1\le i\le k}c_i''\boxdot ({\textbf{v}}_i+s_i\cdot {\textbf{u}})&\approx -\sum _{1\le i\le k} r_i\cdot c_i''=-\sum _{1\le i,j\le k}r_i\cdot (c_{i,j}\boxdot {\textbf{b}}_j) \pmod q.\end{aligned}$$

Putting them all together, we obtain

$$c_0^*+\sum _{1\le j\le k}c_j^*\cdot s_j\approx c_{0,0}+\sum _{1\le j\le k}(c_{0,i}+c_{i,0})\cdot s_j+\sum _{1\le i,j\le k} c_{i,j}\cdot s_is_j=\sum _{0\le i,j\le k}c_{i,j}\cdot s_is_j \pmod q$$

which completes the correctness proof of the relinearization algorithm.

Asymptotically Faster Multiplication. Recent research [26] has enhanced the multiplication of BFV and CKKS in MKHE to achieve a linear time complexity. They leverage a newly proposed concept called homomorphic gadget decomposition, which satisfies \(\left\langle h(a) \odot h(b), {\textbf{g}}\right\rangle = ab \pmod q\) for \(a, b \in R_q\), to replace the term \(h(c_{i,j})\) with \(h(c_i) \odot h(c'_j)\). As our MGHE is a natural extension of MKHE, we can directly adopt their algorithm to both BFV and CKKS. Notably, their multiplication in BFV entails additional (homomorphic) gadget decomposition \(\tilde{h}: R_{\tilde{q}} \rightarrow R^{\tilde{d}}\) on \(\tilde{q} := q^2\) with a gadget vector \(h \in R_{\tilde{q}}^{\tilde{d}}\) and the corresponding external product \(c \tilde{\boxdot } {\textbf{v}}= \left\langle \tilde{h}(c), {\textbf{v}}\right\rangle \pmod {\tilde{q}}\). We refer the reader to [26] for further details.

4.4 Automorphism

The packing technique of the BFV scheme enables us to encode multiple values in a finite field into a single plaintext polynomial for better efficiency [10]. The (un)packing algorithm has a similar algebraic structure with the canonical embedding map over the cyclotomic field \(K=\mathbb Q[X]/(X^N+1)\), and the automorphisms in the Galois group \(\mathcal Gal(K/\mathbb Q)\) provide special functionality on the plaintext slots such as rotation.

We present a multi-group variant of homomorphic automorphism such that the joint automorphism key is generated non-interactively. Given a multi-group ciphertext \(\textsf{ct}=(c_0, \dots , c_k)\) linked to k groups \(I_1, \dots , I_k\), the joint automorphism key of \(I_j\) is used to perform the key-switching procedure of the j-th entry \(\psi (c_j)\) during the homomorphic evaluation of \(\psi _\ell \in \mathcal {G}\textsf{al}(K/\mathbb Q)\). For simplicity, we will describe the case with one automorphism for simplicity in the following sections.

\(\bullet \) \(\underline{\texttt{Auto}(\textsf{ak}_1, \dots , \textsf{ak}_k;\textsf{ct})}\): Given a ciphertext \(\textsf{ct}=(c_0, c_1, \dots , c_k)\) and the joint automorphism keys \(\textsf{ak}_j={\textbf{h}}_j\) for \(1\le j\le k\), compute and return the ciphertext \(\textsf{ct}_\mathsf {{aut}}=(c_0',c_1',\dots , c_k')\) where \(c_0'=\psi (c_0)+\sum _{1\le j\le k} (\psi (c_j) \boxdot {\textbf{h}}_j) \pmod q\) and \(c_j'=\psi (c_j)\boxdot {\textbf{k}}\pmod q\) for \(1\le j\le k\).

Correctness of Homomorphic Automorphism. We show below the correctness of multi-group homomorphic automorphism algorithm:

$$\begin{aligned} c_0'+\sum _{1\le j\le k}c_j'\cdot s_j &= \psi _\ell (c_0)+\sum _{1\le j\le k} \psi _\ell (c_j)\boxdot ({\textbf{h}}_j+s_j\cdot {\textbf{k}})\\ &\approx \psi _\ell (c_0)+\sum _{1\le j\le k} \psi _\ell (c_j)\cdot \psi _\ell (s_j) = \psi _\ell (c_0+\sum _{1\le j\le k} c_j\cdot s_j) ~ \pmod q \end{aligned}$$

where \(\textsf{ct}=(c_0, \dots , c_k)\) and \(\textsf{ct}_\mathsf {{aut}}=(c_0', \dots , c_k')\leftarrow \texttt{Auto}({\textbf{h}}_1,\dots ,{\textbf{h}}_k; \textsf{ct})\).

4.5 Security

In this section, we show that our MGHE scheme achieves a semantic security that we defined in Sect. 3.1 under the RLWE assumption.

Lemma 1 (Security of MGHE)

The MGHE scheme described above is semantically secure under the RLWE assumption with parameter \((n, q, \chi , \sigma )\).

Proof

Let \(I_i\) be sets such that \(I = \cup _{0 \le i \le k}{I_i}\) and \(H = I \backslash A\) for any set \(A \subsetneq I\). We define some hybrid games as follows:

  • Game 0: This is a real world execution of the security game defined in Definition 1.

  • Game 1: It is similar to Game 0, but the challenger samples \([\textsf{pk}]_i\) uniformly at random from \(R_q^{d\times 4}\) for \(i \in H\).

  • Game 2: It is similar to Game 1, but the challenger encrypts 0 instead of \(m_b\).

Let \([\textsf{pk}]_i=([{\textbf{b}}]_i,[{\textbf{d}}]_i,[{\textbf{v}}]_i,[{\textbf{h}}]_i)\) be the public key of party \(i\in H\). Since \(([{\textbf{b}}]_i, \textbf{a})\) and \(([{\textbf{v}}]_i, {\textbf{u}})\) follow the RLWE distribution of secret \([s]_i\), a pair (\([{\textbf{b}}]_i, [{\textbf{v}}]_i\)) is indistinguishable from a uniform distribution over \(R_q^{d \times 2}\). In addition, \(([{\textbf{d}}]_i,\textbf{a})\) follows the RLWE distribution of secret \([r]_i\), \([{\textbf{d}}]_i\) is also indistinguishable from a uniform distribution over \(R_q^{d}\). Meanwhile, \(([{\textbf{d}}]_i,\textbf{a})\) and \(([{\textbf{v}}]_i,{\textbf{u}})\) can be viewed as a ‘chain’ of two gadget encryptions of \([s]_i\) and \(-[r]_i\) under secrets \([r]_i\) and \([s]_i\), respectively. Here we make an additional circular security assumption which guarantees that our scheme remains secure even if \([{\textbf{d}}]_i\), \([{\textbf{v}}]_i\), and \([{\textbf{h}}]_i\) are public. On the other hand, \([{\textbf{h}}]_i\) is an gadget encryption of \(\psi ([s]_i)\) under \([s]_i\) with a random vector \({\textbf{k}}\). Therefore, Game 0 and Game 1 are computationally indistinguishable.

In both Game 1 and Game 2, the adversary sends a group index j to the challenger in the security game. The encryption key \({\textbf{b}}[0]\) used in these games is given by \({\textbf{b}}[0]=\sum _{i\in I_j \cap A} [{\textbf{b}}]_i[0] + \sum _{i\in I_j \cap H} [{\textbf{b}}]_i[0]\). Since \(I_j\cap H\) is non-empty and each \([{\textbf{b}}]_i\) is uniformly sampled from \(R_q^d\) for all \(i\in H\), \({\textbf{b}}[0]\) is computationally indistinguishable from a uniform random variable over \(R_q\). Thus, under the RLWE assumption, the encryptions of 0 and \(m_b\) in both games are also computationally indistinguishable. Therefore, the difference in advantage between these two games is negligible.

According to the aforementioned reasons, we can conclude that the advantage of the adversary in Game 0 is negligible. Since Game 0 is a real world-execution game with the MGHE scheme, our MGHE scheme achieves semantic security against semi-malicious corruptions.    \(\square \)

5 Constructing MPC from MGHE

The MGHE sheme, being a generalization of both the MKHE and MPHE primitives, can serve as a drop-in replacement for these primitives in any application built with them. As a result, MGHE can be effectively utilized in general 2-round MPC computation [32], outsourced computation applications [31], and distributed machine learning setups [19]. Additionally, it can be employed as a building block in MPC protocols that require varying number of parties [17].

5.1 Overview

MPHE and MKHE are both viable options for building an MPC protocol [29, 31, 32], but each has limitations that restrict their usefulness in certain applications. For example, MPHE-based MPC protocols require parties to communicate with each other to generate a shared key. On the other hand, MKHE schemes are more time and space intensive than MPHE because ciphertexts expand as they interact with other ciphertexts under different keys. Thus, an MGHE scheme that integrates the strengths of both these schemes can be used to construct round-efficient MPC protocols. In Fig. 2, we describe a high-level structure of an MPC computation in three phases. Here, we assume three entities consisting of key owners, data owners, and a cloud server.

Fig. 2.
figure 2

MPC protocol using MGHE and previous work [31]. In [31], \(\text {cpk}\) and \(\text {rlk}\) represent the common public key for encryption and evaluation key, respectively. In our MGHE scheme, these keys can be obtained from the joint public key \(\text {jpk}\) directly.

  • [Phase I] Setup: In the first step of the protocol, key owners generate their key pairs and broadcast the public keys. We can treat this step as an offline phase since these procedures have to be run only once and each party is able to produce a key pair independently. When Phase I is ended, a joint public key is built publicly by summing up the individual public keys without any interaction between the parties.

  • [Phase II] Encryption: After encrypting inputs with the joint encryption key, the ciphertexts are provided to the server which may be an external entity such as a cloud service provider. In general, semi-honest cloud service providers or parties themselves in MPC may play the role of computing party. When Phase II is ended, the circuit is evaluated using the homomorphic properties of the encryption scheme and thus does not require any interaction.

  • [Phase III] Decryption: When the evaluation is over, we use an interactive protocol known as distributed decryption to securely decrypt the result without revealing the secret key of each party. In the protocol, each party partially decrypts the ciphertext using its own secret key with noise smudging technique [5], and the output message is obtained by adding all of the partially decrypted results.

Implication of Non-interactive Key Aggregation. Recall that all prior MPHE yields multi-round key generation in Phase I due to the quadratic structure of the evaluation key with respect to the individual secret keys. In the MPC protocol derived from the previous MPHE, each party broadcasts twice for the key generation: (1) individual encryption key to generate the joint encryption key and (2) individual evaluation key, which is constructed using the joint encryption key, to generate the joint evaluation key. In other words, it requires an interaction between parties for key aggregation during the setup. In our scheme, the novel refactoring of the evaluation key enables the parties to broadcast their keys only once. Each party broadcasts the individual public key, which implicitly contains the shares of the evaluation key. Then, the joint public key is generated publicly to be used for encryption and evaluation. By sharing the individual key pair in the first round itself, each party does not require interaction with other parties in the rest of the process (and can be offline until the decryption process). Thus our setup phase is non-interactive in the sense of Non-Interactive MPC [7, 23] that each party independently and asynchronously broadcasts a single message.

The advantages of this non-interactivity are even more pronounced when a key owner belongs to multiple groups. For example, in the MPC protocol with interactive setup, a key owner must join several key generation protocols to generate joint public keys corresponding to the groups containing the party. Moreover, all parties in the group have to participate simultaneously since the key generation requires communications between the parties. However, with the non-interactive key aggregation, the server or the parties can generate joint public keys after each party broadcasts its own public key without any interaction with other parties. Therefore, we can achieve better efficiency since there is no need to participate in the key generation protocol multiple times and each party can broadcast its own key at any time before generating the joint public key.

Fig. 3.
figure 3

\(\pi _{C}\): MPC protocol for a circuit C using MGHE

5.2 MPC Protocol Secure Against Semi-malicious Corruptions

We provide a concrete MPC protocol in Fig. 3 for a polynomial-time deterministic circuit C. The correctness of the protocol follows from the correctness of the MGHE construction. In this section, we prove the protocol’s security against a semi-malicious adversary which the definition is referred from [5]. Note that a semi-malicious adversary follows the honest protocol specification with arbitrary values for their random coins [5, 29, 32].

To prove the security of the MPC protocol from MGHE, we begin by demonstrating the simulation security [27] of the distributed decryption process in MGHE. For a circuit C, let us denote by \(B_C\) an error bound of a ciphertext obtained by evaluating the circuit C over fresh ciphertexts. Given \(B_C\), we can guarantee the correctness and simulation security of the distributed decryption if \(\sigma '\) is exponentially larger than the bound \(B_C\).

Lemma 2 (Correctness of Distributed Decryption)

Let n be the number of parties in \(I = \cup _{1 \le j \le k} I_j\) and \(B_{\sigma '}\) be bound of the samples from \(D_{\sigma '}\) with non-negligible probability. If \(q \ge 2nt(B_C + B_{\sigma '})\), then the distributed decryption procedure \(\texttt{DistDec}\) satisfy correctness.

Proof

Given the partial decryptions \([\mu ]_i\) of parties \(i \in I\), we have

$$\begin{aligned} c_0 + \sum _{i \in I}\mu _i &= c_0 + \sum _{i \in I}\left( \sum _{1 \le j \le k, i \in I_j} c_j\right) \cdot [s]_i + \sum _{i \in I}[e']_i \\ &= \varDelta \cdot m + e + e' \end{aligned}$$

where e is bounded by \(nB_C\) and \(e' = \sum _{i \in I}[e']_i\) is bounded by \(nB_{\sigma '}\). Since \(q \ge 2nt(B_C + B_{\sigma '})\), we have \(|e + e'| \le q/2t\), which ensures the correctness.    \(\square \)

Lemma 3 (Security of Distributed Decryption)

If \(\sigma '>0\) is a real number such that the samples from \(D_{\sigma '}\) are larger than \(2^{\lambda } B_C\) without negligible probability, then the distributed decryption procedure \(\texttt{DistDec}\) achieves statistical simulation security against any static semi-malicious adversary corrupting exactly \(n-1\) parties.

Proof

Let a party h be the only honest party. We construct a simulator \(\mathcal {S}\) against the adversary \(\mathcal {A}\) which has an access to the inputs and secret keys of all parties except h and receives the output message m from the ideal functionality. For given evaluated ciphertext \(\textsf{ct}= (c_0, \dots , c_L)\), the simulator computes and publishes the simulated partial decryption \([\mu ]'_h\) of the honest party h using a smudging error \([e']_h^{sm}\leftarrow D_{\sigma '}\):

$$\begin{aligned}{}[\mu ]'_h = \varDelta \cdot m + [e']_h^{sm} -\sum _{i \ne h}{\gamma _i} - c_0 \end{aligned}$$
(1)

where \(\gamma _i=\left( \sum _{1 \le j \le k, i\in I_j}c_j\right) \cdot [s]_i\pmod q\) for \(i\ne h\).

Then, the partial decryption of h is generated from the partial decryptions of corrupted parties and the output message as \(\varDelta \cdot m + [e']_h^{sm} -\sum _{i \ne h}{\gamma _i} - c_0\). On the other hand, the real partial decryption also can be written as \(\varDelta \cdot m + e + [e']_h^{sm} -\sum _{i \ne h}{\gamma _i} - c_0\) where e is the noise in the ciphertext \(\textsf{ct}\). By the smudging lemma [5], the distributions of \([e']_h^{sm}\) and \(e + [e']_h^{sm}\) are statistically indistinguishable. It concludes that the simulated partial decryption and the real partial decryption are statistically indistinguishable.    \(\square \)

Theorem 1 (Security of MPC Protocol)

Given a poly-time computable deterministic circuit C with L inputs, the protocol \(\pi _{C}\) described in Fig. 3 UC-realizes the circuit C against any static semi-malicious adversary corrupting exactly \(n-1\) parties.

Proof

Let a party h be the only honest party. We construct a simulator \(\mathcal {S}\) against the adversary \(\mathcal {A}\) as follows.

The Simulator. In Phase I, the simulator samples the public key of h from uniform distribution over \(R^{d \times 4}_q\) instead of \(\texttt{IndKeyGen}(h)\). The simulator also plays Phase II honestly on behalf of the honest party, but encrypts 0 instead of the real input from h, if any. As the simulator has access to the inputs and secret keys of all parties except h from the witness tape, the simulator can evaluate the circuit C on ciphertexts \(\textsf{ct}_1, \dots , \textsf{ct}_L\) and obtain the resulting ciphertext \(\textsf{ct}\). In addition, it also receives the output message m from the ideal functionality. In Phase III, the simulator computes the partial decryption for the party h as same as the simulator introduced in the security proof of Lemma 3.

Now, we define some hybrid games and prove the computational indistinguishability between the real and ideal worlds.

  • The game \(REAL _{(\pi , \mathcal {A}, \mathcal {Z})}\): An execution of the protocol \(\pi \) in the real world with environment \(\mathcal {Z}\) and semi-malicious adversary \(\mathcal {A}\).

  • The game \(HYB ^{1}_{(\pi , \mathcal {A}, \mathcal {Z})}\): This is the same as \(REAL _{(\pi , \mathcal {A}, \mathcal {Z})}\) except the output of partial decrpytion of h. In Phase III, it publishes the simulated partial decryption which is computed via (1).

  • The game \(HYB ^{2}_{(\pi , \mathcal {A}, \mathcal {Z})}\): This is similar to \(HYB ^{1}_{(\pi , \mathcal {A}, \mathcal {Z})}\), but in Phase II the party h encrypts 0 instead of the real input if any.

  • The game \(IDEAL _{(\mathcal {F}, \mathcal {S}, \mathcal {Z})}\): It executes the MPC protocol with the simulator \(\mathcal {S}\). The difference from \(HYB ^{2}_{(\pi , \mathcal {A}, \mathcal {Z})}\) is that the public key of h is sampled from a uniform distribution over \(R^{d \times 4}_q\) instead of the individual key generation algorithm \(\texttt{IndKeyGen}(h)\) in Phase I.

From the above games, we consider the following claims.

Claim 1. \(REAL _{(\pi , \mathcal {A}, \mathcal {Z})}\) and \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\) are statistically indistinguishable.

Proof

According to the description of the simulator, the partial decryption of h in the game \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\) is generated from the partial decryptions of corrupted parties and the output message as \(\varDelta \cdot m + [e']_h^{sm} -\sum _{i \ne h}{\gamma _i} - c_0\), while the real partial decryption also can be written as \(\varDelta \cdot m + e + [e']_h -\sum _{i \ne h}{\gamma _i} - c_0\) where e is the noise in the ciphertext \(\textsf{ct}\). By Lemma 3, the distributions of \([e']_h^{sm}\) and \(e + [e']_h\) are statistically indistinguishable. This indicates that \(REAL _{(\pi , \mathcal {A}, \mathcal {Z})}\) and \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\) are also statistically indistinguishable.

Claim 2. \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\), \(HYB ^2_{(\pi , \mathcal {A}, \mathcal {Z})}\), and \(IDEAL _{(\mathcal {F}, \mathcal {S}, \mathcal {Z})}\) are computationally indistinguishable.

Proof

The differences in three games correspond to the differences in Game 0, Game 1, and Game 2 of Lemma 1. In detail, the difference between \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\) and \(HYB ^2_{(\pi , \mathcal {A}, \mathcal {Z})}\) is that the party h encrypts the real input in \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\) while it encrypts 0 in the game \(HYB ^2_{(\pi , \mathcal {A}, \mathcal {Z})}\), if any. Furthermore, the difference between \(HYB ^2_{(\pi , \mathcal {A}, \mathcal {Z})}\) and \(IDEAL _{(\mathcal {F}, \mathcal {S}, \mathcal {Z})}\) is in the public key \(\textsf{pk}_h\). In \(HYB ^2_{(\pi , \mathcal {A}, \mathcal {Z})}\), \(\textsf{pk}_h\) is a valid public key generated by h while it is sampled from a uniform distribution over \(R^{d \times 4}_q\) in the game \(IDEAL _{(\mathcal {F}, \mathcal {S}, \mathcal {Z})}\). Thus, by Lemma 1, the three games \(HYB ^1_{(\pi , \mathcal {A}, \mathcal {Z})}\), \(HYB ^2_{(\pi , \mathcal {A}, \mathcal {Z})}\), and \(IDEAL _{(\mathcal {F}, \mathcal {S}, \mathcal {Z})}\) are computationally indistinguishable.

According to the claims, we conclude that the MPC protocol \(\pi _{C}\) is secure in the semi-malicious model against \(n-1\) corrupted parties.    \(\square \)

To handle the arbitrary number of corruptions, we can establish security proof by constructing the extended protocol as outlined in [32]. In addition, we can transform our MPC protocol, which is secure against semi-malicious attackers, into a protocol that offers security against malicious corruptions without introducing any additional rounds. This transformation can be achieved by leveraging non-interactive zero-knowledge proofs, as described in [5].

6 Experimental Results

We implement our MGHE scheme based on BFV and CKKS. The source code is written in GO programming language and is built on Lattigo [1] version 2.3.0. We conducted experiments on a system equipped with Intel(R) Core(TM) i9-10900 CPU @ 2.80 GHz and 64 GB RAM. In our implementation, the key distribution \(\chi \) samples the coefficients from the ternary set \({-1, 0, 1}\) with equal probabilities of 0.25 for \(-1\) and 1, and a probability of 0.5 for 0. The error parameter is set to \(\sigma =3.2\).

Table 1. Performance of our MGHE schemes, the MKHE scheme by Chen et al. [13], and the MPHE scheme by Mouchet et al. [31]: execution times to operate homomorphic multiplication (Mult + Relin), taken in milliseconds (ms). N denotes the dimension of base ring, n and k denote the number of the associated parties and groups (keys), respectively, to the ciphertext. \(\text {Ours}^+\) refers to our MGHE scheme combined with the technique of [26].

Table 1 shows the execution time of multiplication of our MGHE scheme. The experiment was conducted using two different parameter sets: \((N, \lceil \log {pq} \rceil ) = (2^{14}, 438)\) and \((2^{15}, 880)\) where p is a special modulus. Both parameter sets ensure a security level of at least 128 bits [2]. Ours shows the performance of Algorithm 1 where a minor optimization is introduced and Ours\(^+\) shows that of multiplication algorithm which applies the technique of [26]. As our MGHE supports computation on groups of parties, we measured the performance varying the number of groups.

We also present the performance of the MKHE scheme [13] and MPHE scheme [31] for comparison. Since MKHE and MPHE are instances of MGHE where each group consists of a single party and single group, respectively, the MKHE scheme and MPHE scheme have its results in Table 1 only when \(n = k\) and \(k = 1\), respectively. Upon comparing the performance of MKHE and our method, the table shows that our multiplication algorithm exhibits slightly faster operation times than previous MKHE. This is due to our approach, as explained in Sect. 4.3, where we reduce the number of external products during the relinearization. Moreover, in the case of a large number of groups, it is even faster than our method when we apply the recent technique introduced in [26]. We also remark that although MPHE shows better performance than other methods, it requires interactions among the parties before the evaluation to generate the joint public key.