Homomorphic Encryption for Multiple Users with Less Communications (cid:63)

. Keeping privacy for every entity in outsourced computation is always a crucial issue. For eﬃcient secure computation, homomorphic encryption (HE) can be one of nice solutions. Especially, multikey homomorphic encryption (MKHE) which allows homomorphic evaluation on encrypted data under diﬀerent keys can be one of the simplest solutions for a secure computation which handles multiple users’ data. However, the current main problem of MKHE is that the dimension of its evaluated ciphertext relies on the number of users. To solve this problem, there are several variants of multikey homomorphic encryption schemes to keep the size of ciphertext constant for a ﬁxed number of users. However, users interact one another before computation to provide their inputs, which increases setup complexity. Moreover, all the existing MKHE schemes and their variants have unique beneﬁts which cannot be easily achieved at the same time in one scheme. In other words, each type of scheme has a suitable computational scenario to put its best performance. In this paper, we suggest more eﬃcient evaluation key generation algorithms (relinearization key and bootstrapping key) for the existing variants of MKHE schemes which have no ciphertext expansion for a ﬁxed number of users. Our method only requires a very simple and minor pre-processing; distributing public keys, which is not counted as a round at all in many other applications. Regarding bootstrapping, we ﬁrstly provide an eﬃcient bootstrapping for multiple users which is the same as the base single-key scheme thanks to our simpliﬁed key generation method without a communication. As a result, participants have less communication, computation, and memory cost in online phase. Moreover, we provide a practical conversion algorithm between the two types of schemes in order to eﬃciently utilize both schemes’ advantages together in more various applications. We also provide detailed comparison among similar results so that users can choose a suitable scheme for their homomorphic encryption based application scenarios.

multiple users than single-key HE; input privacy and output privacy. We call it multikey security. Indeed, MKHE seems much more suitable in real application scenarios than just single-key HE. In real worlds, many of companies have their own private data which might be confidential or involved in patenting issue, they do not want to reveal the data to others. At the same time, all they need is to compute a function value with their data such as predicted value of a machine learning model. On the other hand, in this case, the input security cannot be naturally achieved by using single-key HE. If all the companies share the same key (using single-key HE), dishonest companies can decrypt other honest parties' inputs. Then the input security may not be fully achieved. In order to prevent this, one may assume or build a specific computing environment where the transmit channel between a user and the server is private, hence no one can obtain other's information without permission. This kind of assumption is somewhat strong so that it seems quite expensive to be instantiated in practice.
Even though MKHE schemes have been implemented with practical results [CDKS19,CCS19], the ciphertext expansion during homomorphic operation is still the main issue to be solved. That is, the ciphertext size grows relying on the number of users, which results in increasing both computation and communication cost proportional to the number of users (say k). Even though the size of ciphertext in MKHE is significantly reduced (from quadratic to linear on k) [BP16], the computation time and memory costs still at least k times more than underlying single-key scheme. This structure seems inevitable to keep on-the-fly property which is a strong benefit of homomorphism between ciphertext and plaintext. The property lets a new user join an ongoing computation at any point, freely. So no information about participants are not needed to be known ahead of time. This is specifically called dynamic computation which is useful in general, but the current problem of the schemes having the property is that the ciphertext size, more precisely, the dimension of ciphertext vector, grows depending on the number of users. For a certain computation scenario with pre-defined number of users (i.e when there is no new dynamic computation), it is not fully recommended to use such scheme sacrificing efficiency. In the case, the short ciphertext size and multikey security are essential for an efficient and secure computation among pre-defined users.
As a partial solution to achieve constant size of ciphertext, there are variants of MKHE schemes which only work when participants are fixed, by creating a common public key among pre-defined multiple parties. We categorize those all as a compact MKHE scheme throughout this paper since they achieve multikey security, and have no ciphertext expansion relying on the number of users. All existing approaches [AH19, MTPBH21] have the same structure based on threshold FHE (ThFHE) [AJLA + 12] where more than t out of N parties can decrypt an evaluated ciphertext encrypted under N different secret keys (if t = N , it is called multikey variant Threshold FHE [BGG + 17]). In threshold FHE based schemes, users generate a common public key, therefore, the asymptotic complexity of the scheme becomes as same as its base single-key HE scheme with multikey security. However, each has been built upon a particular computing scenario and their evaluation key generation procedure is a protocol by taking some interactions among users. In other words, users need to be online to generate such keys. Then homomorphic operation can be performed with those keys. Even, key switching and bootstrapping steps also require an interaction among users. Hence, such schemes have lost on-the-fly property to some extent. Especially, dynamic computation is hardly achievable.
Overall, the suggested two types of schemes (MKHE and multikey variant Threshold FHE) are the most suitable solutions for computations handling multiple users' data based on homomorphic encryption. However, they have very different advantages. And one is not simply compatible with the other. Furthermore, the suggested multikey-Threshold FHE schemes are not optimized in the sense of communication round complexity. In practice, it is always better to minimize the communication among multiple users for efficiency in terms of storage, computation, and more. Therefore, it is important to provide an efficient solution to take both advantages for more application scenarios.

Our Contribution
In order to solve the aforementioned issues, we first present efficient evaluation key generation algorithms (for relinearization and bootstrapping) for a compact MKHE scheme where the size of ciphertext does not grow depending on the number of users. The main goal is to generate evaluation keys by taking no interaction among pre-defined users. The procedure is not a protocol anymore so that the scheme becomes more user-friendly by reducing computation, storage cost per user than other works [AH19, MTPBH21]. Regarding bootstrapping, we firstly provide an efficient bootstrapping for multiple users which is the same as the base single-key scheme thanks to our simplified key generation method without a communication. To do this, we need a simple pre-processing step, distributing public keys to all, which is not a big deal in realistic scenarios such as in public key infrastructure (PKI). We use the latest multikey variant of Threshold FHE scheme [MTPBH21] as a base scheme to apply our evaluation key generation algorithms. Also, our method is always applicable to every such ciphertext format encrypted under the secret key (s 1 + s 2 + · · · + s k , 1), where s i is the i-th user's secret.
Moreover, thanks to the minimal communication, we could suggest an efficient method to connect existing compact MKHE schemes and other (non-compact) MKHE schemes to maximize the performance in a various computation environment. For example, compact schemes have no ciphertext expansion for a fixed number of users, but on-the-fly computation is not directly applicable for new users. On the other hand, the non-compact schemes have ciphertext expansion but easily allow to join on-going computation at any point. In order to compensate each negative point, it is the best way to make one to be compatible with the other efficiently. In particular, the conversion from non-compact to compact scheme is very meaningful to reduce the network cost. The conversion is efficient since a server only runs key switching algorithm without requiring any interaction among users. Our algorithms are instantiated based on BFV homomorphic encryption scheme [FV12], but the same idea can be applied to other FHE schemes such as BGV [BGV12] and CKKS [CKKS17].
Main idea behind the contribution Existing compact MKHE schemes [AH19, MTPBH21] employ the interactive evaluation key generation algorithm [AJLA + 12] for relinearization. In fact, after the tensor product of two multikey ciphertexts, ct 1 and ct 2 encrypting m 1 and m 2 , respectively, under sk = (s 1 + s 2 + · · · + s k , 1), the resulting ciphertext So ct ⊗ is a degree 2 ciphertext which should be reduced to a degree 1 ciphertext as the original ciphertexts in the end. To do this, one can homomorphically relinearize the degree 2 ciphertext and this method requires some additional key K ∈ R ×2 q such that K[1](s 1 + · · · + s k ) + K[2] = (s 1 + · · · + s k ) 2 g + e for some error e and a gadget vector g ∈ R q . Then relinearization performs ct × to generate the final ciphertext ct × of degree 1. As a result, ct ⊗ , sk ⊗ sk ≈ ct × , sk .
What [AJLA + 12] based schemes are trying to do is to generate a pseudo encryptions of (s 1 + . . . + s k ), K, under (s 1 + . . . + s k ) by combining all single-key encryptions of s i encrypted under its own key s i for each user i ∈ [k] at the end. The way to transform a single-key ciphertext into multikey one takes some interaction, resulting in 2 rounds. Then a server collects the final information and adds them to obtain K.
However, it becomes much simpler if each user generates a multikey encryption of s i under a common public key from the beginning, since the public keys are already known. As a result, the essential number of interaction is reduced to one from two; distributing public keys which can be saved in a certain computation scenarios such as PKI. Then no interaction is required.
This solution reduces computational burden such as time memory, etc. on the user's side when such schemes are applied to real computation scenarios. More importantly, it strikes a better balance between two different types of schemes which have distinct benefit. Therefore, the existing compact MKHE schemes become simpler to be compatible with original MKHE schemes, which may provide more convenient computing tool for users.

Related Works
Multikey homomorphic encryption scheme is firstly introduced by López-Alt et al. [LTV12] based on NTRU. Then a multikey version of GSW scheme [CM15] was introduced for the first time. It was developed to achieve round optimal multiparty computation [MW16]. Also there were plausible results to get rid of CRS [BHP17, KLP20] among multiple users based on GSW scheme. Other works allowed multi-hop (dynamic) property [PS16,BP16] in MKHE schemes. Brakerski and Perlman [BP16] proposed the shorter size of ciphertext which has linear growth on the number of users at first. Then other FHE primitives were naturally transformed to multikey variants such as multikey BGV [CZW17], multikey TFHE [CCS19, LP19], and multikey BFV, and CKKS [CDKS19] with linear growth ciphertext length.
In order to have constant size of ciphertext size (to achieve a compact MKHE), there is a multikey variant of Threshold FHE [AH19, MTPBH21], where a joint public keys are computed by users employing the idea of [AJLA + 12] taking two rounds, hence the ciphertext size remains constant for a fixed number of users. The protocol takes four rounds in total. Due to their round complexity, it is not fully practical even in their specific computation scenarios; specifically, the work [AH19] is recommended to an outsourced computation with multiple model providers which are usually fixed and clients who can be anyone. Then the model provider uses multikey ThFHE and the clients use the original MKHE schemes for dynamic property. Mouchet et al. [MTPBH21] suggests their scheme for multiparty computation where multiple parties jointly compute a function value and computing materials such as evaluation keys. Again, each is still not fully practical for its best case since users need some interactions for homomorphic evaluation. There is a detailed survey about the line of works [AHSL20].

A note on compact MKHE
We define a compact MKHE (CMKHE) if an MKHE scheme or its variant supports that the ciphertext size remains constant for a polynomially many number of users. Hence, the asymptotic complexity of computation and communication of CMKHE schemes remains as same as single-key homomorphic encryption. Therefore, CMKHE can be an efficient solution for secure computations handling multiple users' data.
The first MKHE scheme [LTV12] is based on NTRU problem and it is a compact MKHE without creating a joint key among users. Moreover, it allows dynamic property directly as well. More importantly, the participants are not need to be pre-defined. However, the scheme is too inefficient due to its large parameters. Furthermore, it was broken by subfield attacks [ABD16, CJL16]. Hence, so far, the only method to instantiate a secure and efficient lattice based compact MKHE is based on Threshold FHE [AH19, MTPBH21], where users jointly generate a common public key. Due to a common public key, the size of ciphertext does not increase depending on the number of joint users. It is still an open problem to build a secure and efficient compact MKHE scheme without any interaction among users before computation.

Preliminaries
Notation: We let λ denote the security parameter. Vectors and matrices are denoted in lowercase bold and uppercase bold, respectively. We denote by v, w the dot product of two vectors v, w. For a vector x, x[i] denotes the i-th component scalar. Let R and R q denote Z[X]/(X N + 1) and Z[X]/(X N + 1) mod q, respectively, for positive integers q, N . For a real α > 0, D α denotes the Gaussian distribution of standard deviation α. The key distribution χ is the uniform distribution over the set of binary polynomials. log(·) is binary logarithm. We also denote the set {1, . . . , n} by [n]. If an element a ≈ 0 mod p for some a ∈ R, a − 0 = 0 mod p for some modulus p.
[b] q for b ∈ R means b mod q. U (R q ) denotes uniform distribution over R q . We denote Var(a) is the maximum variance of each coefficient of a ∈ R. Then the variance of the product of two polynomials in R is that Var(ab) = n Var(a) Var(b) for a, b ∈ R. Var(a) is defined as i=1 1 a[i] for a polynomial vector a ∈ R . The error contained in a ciphertext ct ∈ R 2 is denoted by Err(ct). Let X and Y be two distributions over a finite domain. X comp ≈ Y if they are computationally indistinguishable

Ring Learning With Errors
We recall the decisional ring learning with error (RLWE) problem which is a simple ring-based version of the LWE problem [Reg09].
Definition 1. For security parameter λ, let Φ m (X) be a cyclotomic polynomial with degree φ(m) and set R = Z[X]/(Φ m (X)). Let q = q(λ) ≥ 2 be an integer. For a fixed secret random element s ∈ R q and a distribution χ = χ(λ) over R, the decisional RLWE problem says the distribution outputting (a, [a · s + e]), where a and e is chosen uniformly at random from R q and χ, respectively, and the distribution outputting (a, u) chosen uniformly at random from R 2 q are computationally indistinguishable. The sample (a, [a · s + e]) ∈ R 2 q is called RLWE sample. We assume the above problem for our scheme. For a simple and convenient use like many schemes, we set Φ(X) = X N + 1, where N is a power of 2.

BFV Homomorphic Encryption Scheme
We briefly introduce BFV homomorphic encryption scheme [Bra12, FV12]. We call the scheme as single-key BFV scheme throughout the paper. BFV scheme is derived from LPR [LPR10] public key encryption scheme. Let R p be plaintext space, where p > 1 is plaintext modulus. We define ∆ = q p , where q is ciphertext modulus such that q p. Let χ be a secret key distribution. Note that EvalKeyGen generates (public) evaluation keys used in evaluation algorithm Eval.
For the message m ∈ R t , and public key pk = (a, b), it outputs a fresh ciphertext ct = (ua + e 1 , ub + ∆m + e 2 ) mod q ∈ R 2 q , where u ← χ uniformly at random and e 1 , e 2 ← D α .
A canonical RLWE based ciphertext like BFV ciphertext is a form of RLWE sample, which is, (a, b) ∈ R 2 q . Homomorphic multiplication over this kinds of ciphertext contains computing tensor product of two ciphertexts, in general. So the size of ciphertext grows to square and there is non-linear element in the result. To fix the problems, a procedure called relinearization is performed after tensor product (step (2) of Mult), which requires additional evaluation keys.

Basic Scheme for Multikey variant of Threshold FHE based on BFV
We recall a multikey ThFHE scheme based on BFV [MTPBH21] since we improve the evaluation key generation algorithm of existing compact MKHE schemes. As we mentioned in Section 1, the existing such works are instantiated multikey-threshold homomorphic encryption. So we choose this scheme [MTPBH21] to apply our new technique. Let p and q be a plaintext modulus and a ciphertext modulus, respectively, and q p. ∆ = q/p as defined in original BFV.
-CMKHE . Setup(1 λ ) → params: It takes security parameter λ and outputs public parameter params = {N, χ, p, q, α, a}, where N is a polynomial degree, χ is a secret key distribution, α is a standard deviation of Gaussian distribution and a ∈ R q is CRS. -CMKHE . KeyGen(params) → (sk, pk): Given params, • set a secret key sk = s ∈ R q , where s ← χ over R q • set a public key pk = (a, b) ∈ R 2 q , where b ← (−as + e) and e ← D α over R q .
After Key generation, all users share their public keys through public channel. Then parties generate a common public key by adding the second component of all given public keys.
-CMKHE . ComKey(pk 1 , . . . , pk k ) →pk: Given all parties' public keys (pk i = (a, b i ), it outputs a common public keypk := (a, It takes a common public keypk and a message m ∈ R p on input, it outputs a fresh ciphertext ct.
and a ciphertext ct, • Setŝk = (s 1 + · · · + s k , 1) ∈ R 2 q , where each s i from sk i . • Compute 1 ∆ ct,ŝk ≈ m mod p As we can see, a fresh ciphertext is encrypted under all involved users' keys. Therefore, the public keys of different users are simply added with a common randomness. More precisely, ct i is decrypted with all associated secret key elements s 1 , . . . , s k , that is, 1 where e c is an error, s i is a secret element of i-th user. The ciphertext space is just as same as the space of single-key BFV, working as a single-key homomorphic encryption.

Multikey Homomorphic Encryption based on BFV
The existing multikey BFV scheme [CDKS19] is a generalization of the above single-key BFV scheme. They let a server expand a single-key BFV ciphertext using other public materials given by all users. That is, each user generates key pair independently and encrypts each message only with its own public key, hence users do not need to know one another before computation. Therefore, its key generation and encryption algorithm are just as same as single-key BFV scheme. However, the size of evaluated ciphertext grows linearly in the number of users.
For example, A fresh ciphertext encrypting m i of the i-th user is ct i = (c 1 , c 2 ) ∈ R 2 q and it is decrypted with a corresponding secret key sk i = (s i , 1) as p q ct i , sk i = c 1 s i + c 2 ≈ m i mod p. Each operation (either addition or multiplication) with other user's fresh ciphertext adds one more component in a ciphertext i.e. ct = (c 1 , c 2 , c 3 ) ∈ R 3 q , if there are two users. More precisely, if we add two fresh ciphertexts ct 1 and ct 2 of two parties, first rearrange the ciphertext entries by increasing the dimension of input ciphertexts such as ct 1 = (ct 1 [1], 0, ct 1 [2]), ct 2 = (0, ct 2 [1], ct 2 [2]) then their underlying secret key sk is (s 1 , s 2 , 1). For addition, just add the two expanded ciphertexts, i.e. ct + := ct 1 + ct 2 mod q ∈ R 3 q . For multiplication, tensor product is used between two expended ciphertexts as single-key BFV does. We first do tensor product which outputs ct ⊗ = ct 1 ⊗ ct 2 ∈ R 9 q . Then ct satisfies ct ⊗ , sk ⊗ sk = ct 1 , sk · ct 2 , sk . We then relinearize it by using additional material (evaluation keys) since there is some non-linear parts such as s 1 · s 2 . Then the final evaluated ciphertext ct × ∈ R 3 q satisfies q p ct × , sk ≈ m 1 m 2 mod p After computation with k users, the evaluated ciphertext isĉt = (c 1 , . . . , c k+1 ) ∈ R k+1 q , which is decrypted as p q ĉ t,ŝk ≈ f (m 1 , . . . , m k ) mod p, whereŝk = (s 1 , . . . , s k , 1) and f (m 1 , . . . , m k ) is a desired function value of all users.

Main Technique
In this section, we present an efficient evaluation key (also bootstrapping key) generation algorithm for compact MKHE scheme to be round optimal. We assume that a common random string (CRS) is given to all users from a trusted generator in the following scheme.

Evaluation key generation algorithm
We recall a gadget vector which is g = (g 1 , . . . , g ) ∈ R q (usually, g i = g i−1 for some g ∈ Z q ). The gadget vector is widely used in homomorphic encryption schemes to control noise growth since the gadget decomposition (inverse of g, g −1 ) keeps the size of output less than min{g i }. Furthermore, if g −1 is randomized (output follows subguassian distribution), it gives a tight bound for error analysis due to independent error term [AP14, GMP19, JLP21]. Note that g −1 : R q → R , which outputs g −1 (a) = (u 1 , . . . , u ) for a ∈ R q , such that g 1 u 1 + . . . + g u = a mod q, = O(log g q).
We first define our simple evaluation key generation algorithm for relinearization. This process is simple and no much noise is contained in the output keys. Once joint parties' public keys are known, no interaction is required for generating a ciphertext and evaluation keys among participants, which makes our scheme more practical than other similar approaches [AJLA + 12, AH19, MTPBH21].
Let K i be an evaluation key of i-th user. Then for some error vectorê i ∈ R q . Note that a of the common public keypk is the same common random parameter given by a trusted setup in this section. In fact, the keys are pseudo-encryptions of secret key. Hence we assume circular security as general homomorphic encryption schemes do. The keys are securely encrypted by multiple users' secret keys, which we will discuss in A by proving this pseudo-encryptions of secrets are computationally indistinguishable to uniform random elements by RLWE assumption. Therefore, any secret key information is not leaked at all unless all of the users agree on it. Now we define our evaluation algorithm consisting of addition and multiplication over ciphertexts. We note that a server can use the master evaluation key by adding all given individual evaluation keys from k users to save memory and computation cost. Then the evaluation algorithm is just as same as the one of the underlying single-key FHE scheme. LetK := k t=1 K t be the master evaluation key. Let ct i = (c i,1 , c i,2 ) ∈ R 2 q , ct j = (c j,1 , c j,2 ) ∈ R 2 q be two multikey ciphertexts encrypted under k different keys, and m i , m j be a corresponding plaintext respectively, for i, j ∈ [k] (i and j are possibly same).
After the first step (tensor product), the output ct satisfies ct , sk ⊗ sk = ct i , sk · ct j , sk , where sk = (s 1 + · · · + s k , 1). Then 1 ∆ [ct [1](s 1 + · · · + s k ) 2 + (ct[2] + ct[3])(s 1 + · · · + s k ) + ct [4]] ≈ m i m j . Therefore, the dimension of ct is increased and the ciphertext contains some non-linear parts such as s i · s j . So we use relinearization algorithm to reduce the dimension as the original one. The third step of the multiplication is relinearization. The computation complexity is as same as single-key BFV since there is no ciphertext expansion.
Correctness of evaluation: Letŝk = (s 1 + · · · + s k , 1) ∈ R 2 q be a corresponding secret key of a multikey ciphertext. For addition, we can easily check that For multiplication, we first note that ct satisfies the following equation with a secret keyŝk ⊗ŝk: After relinearization (step (3)) with evaluation keys, it satisfies that where e ∈ R q andẽ ∈ R q are some errors.

Bootstrapping for CMKHE
Bootstrapping of standard FHE is not straightforward to do and even requires large size of additional key materials (encryptions of secret key). Moreover, a server needs much larger storage and takes more computation time for MKHE scheme (at least k times more than its single-key scheme). Even though it seems inevitable to take all key elements from each user, we can reduce the computation time of a server at least since we use compact MKHE. We follow the bootstrapping of [CDKS19], but ours is much simpler since the size is reduced to single-key version. Moreover, there is no interaction among users for bootstrapping, even creating a bootstrapping key unlike [MTPBH21]. Everything we need to modify is evaluation of Galois automorphisms which is a linear transformation requiring rotations on encrypted elements since the rest is as same as an improved single-key BFV bootstrapping procedure [CH18]. It is mainly based on key switching such as using a map τ t : P (X) → P (X t ), where P (X) is a polynomial in R q . We denote τ t (a) = (τ t (a 1 ), . . . , τ t (a d )) for a d-dimensional vector a = (a 1 , . . . , a d ). It is easy to see that τ t (ct) is encrypting τ t (m) under a secret key τ t (sk), where CMKHE . Dec(ct, sk) = m, sk = (s, 1). To bootstrap an evaluated multikey ciphertext, it requires secret key elements, say, µ s ∈ R q , which is generated by additional algorithm only for bootstrapping key in [CDKS19]. We first generate an key generation algorithm which takes a secret key element on input. Let pk be a common public key of k users.
(2) Parsepk = (a , b ) such that a ( We can easily check key satisfies the following equation: Then one may transform a ciphertext encrypted under s to an encryption of the same plaintext under different secret key s . Then we use key switching algorithm similarly defined in [CDKS19] but more efficient than that since we only require one 2 ring multiplication rather than 2k . Let ct be a ciphertext encrypted under s and the key is encrypting s under the secret s. Then, in our case, bootstrapping key (also called Galois key) is generated by running CMKHE . EncSKGen algorithm as [CDKS19]. We define Galois key generation algorithm below.
(1) Runs CMKHE . EncSKGen(pk, τ t (s i )) → key i,t (2) Outputs GK i,t := key i,t In fact, like the master evaluation key, a server can save the master bootstrapping key by adding all bootstrapping keys of users. It can save memory consumption of a server definitely. An evaluation of Galois automorphism on a compact MKHE ciphertext is easily done by running key switching algorithm CMKHE . KeySwitch taking bootstrapping key on input. For simplicity and efficiency, we useĜK t := k i=1 GK i,t as the master bootstrapping key. Now we check the correctness of key switching with the master bootstrapping key. Correctness: We show that ct ,ŝk = τ t ( ct,ŝk ) mod q, whereŝk = (s 1 + · · · + s k , 1).
where e ∈ R q is an error.

Security
We can prove that the distribution of our evaluation keys are computationally indistinguishable to uniform distribution, since the evaluation keys are only different to existing secure constructions [AH19, MTPBH21]. We define the CMKHE . EvalKeyGen (resp. CMKHE . EncSKGen)is an encryption algorithm of message m under a public key generated from CMKHE . KeyGen. We prove that the encryption algorithm is semantically secure, then equivalently we conclude that the evaluation keys do not leak any information about underlying message (secret key) against passive adversaries by assuming circular security.
For MKHE security with multiple decryptor, it is recommended to prove that the scheme is secure against both internal adversary and external adversaries [LP19]. However, we only care of the internal adversary which is one of participants for evaluation keys, since the keys are not used for decryption process. We show the entire security proof of the proposed scheme in Appendix C with the brief explanation about proper adversaries.
Theorem 1. The distribution of evaluation keys are computationally indistinguishable to uniform distribution over R ×2 q by assuming underlying RLWE assumption with the parameter (n, q, χ, D α ) is hard and circular security.
Proof. Let k be the number of users, (pk i , sk i ) ← CMKHE . KeyGen (params), where params ← CMKHE. Setup for i ∈ [k], and we set pk i = (a i , b i ), sk i = s i . Let K b ← CMKHE . EvalKeyGen(pk, b) be a relinearization key encrypting a bit b under k users' secrets. Let key b ← CMKHE . EncSKGen(pk, b) be a bootstrapping key of encryption a bit b under k user's keys. Without loss of generality, we assume k = 2. Here, the challenge ciphertext is an evaluation key K b (resp. key b ). We denote an internal adversary of CMKHE by A and an RLWE distinguisher by B. In the security game for internal adversary [KLP20], A performs what he can do such as accessing certain oracle after receiving a challenge ciphertext K b (resp. key b ) from a challenger of a security game, sends the value to B by letting him guess which b was chosen by the challenger. Then A forwards the answer of B to the challenger.
It is clear to see that the challenge ciphertext K b (resp. key b ) encrypting b under pk 1 and pk 2 . Then the internal adversary who holds sk 2 (assume he is the second user), can partially decrypt K b (resp. key b ) with its key by performing (K b [1, j], K 2,j ), sk 2 for some j ∈ [ell], resulting in an element au j s 1 + b · s 2 · g j + e j ∈ R q denoted by b j . Now we can see that (a, b j ) is an RLWE sample under the given parameter. Then the adversary sends b 1 with a which is a uniform random element and pk 1 to B. In other words, the advantage of A becomes the advantage of the adversary B. which is negligible by RLWE assumption with the given parameter.
Therefore, we conclude that the encryption scheme for evaluation keys are IND-CPA secure assuming circular security and that RLWE assumption is hard with such parameter set. Equivalently, the keys are computationally indistinguishable to R ×2 q , hence do not leak any information about secret key through public channel against passive adversary.

Cons
Dynamic computation takes some rounds Ciphertext size grows linearly in the number of users Users should be pre-defined Compact MKHE schemes we present above are as efficient as its base single-key HE schemes. However, they are not always better than other existing schemes. In order to show the different ability of MKHE schemes and their variants depending on computing environment, we denote our scheme by CMKHE and a multikey BFV scheme [CDKS19] by MKHE in this section,.
We let the key generation of MKHE be same as CMKHE's in the presence of CRS. We summarize the properties of each scheme which may affect on a computation in a positive or negative way in Table 1. It is interesting to see that the benefit that one scheme posses is what the other scheme cannot achieve directly. That is to say, in all existing CMKHE schemes, there is no ciphertext expansion for pre-defined users, but dynamic computation is hardly achievable directly. On the other hand, MKHE allows dynamic computation for free but the ciphertext size grows linearly in the number of users.
In fact, it would be the best if the dynamic computation is possible between different schemes to achieve the best performance using each benefit. Therefore, we suggest practical methods to convert one scheme into the other to compensate the negative point of a scheme by the positive point of the other to some extent.
-The conversion from MKHE to CMKHE is meaningful if a server has lack of its computation power at some point or no more new users join the computation. Moreover, it can be used to reduce communication cost by a server without any interaction with users after evaluation a function value. -We recommend the opposite direction (from CMKHE to MKHE) for a case that new users often take part in a computation after computing a joint function value among a fixed number of users.
We note that these conversion algorithms are also applicable to existing compact MKHE schemes [AH19, MTPBH21] since they have basically the same structure but it is preferable to use ours due to lower round complexity.
We only consider the issue on adding new users in the paper since we can remove users by using multikey proxy re-encryption [YKHK18] regardless of type of schemes. If a user wants to stop continuing the computation, we have to make sure that anything about security issue can not happen. To do this, there is no other efficient solution than multikey proxy re-encryption so far. With all users' proxy re-encryption keys, the server partially decrypt the output then sends to the user. And user can finally decrypt the output with its own key, while the server can continue further computation with the rest of users' information.

Conversion CMKHE into MKHE
The conversion from CMKHE to MKHE is pretty straightforward. Just add a new component for a new user by extending ciphertext dimension. To do this, however, users' evaluation keys of MKHE should be previously generated and sent to a server(or a computing party). For example, let ct = (a, b) ∈ R 2 be an CMKHE ciphertext encrypting m under secret s 1 + s 2 and let ct 3 = (a 3 , b 3 ) be a MKHE ciphertext encrypting m 3 under s 3 . The server expands ct to ct = (a, 0, b) and ct 3 to ct 3 = (0, a 3 , b 3 ), of which underlying secret key is (s 1 + s 2 , s 3 , 1). Then a server computes a function f over ct and ct 3 by using MKHE . Eval algorithm with evaluation keys of MKHE, i.e., addition and multiplication are performed as MKHE's evaluation procedure, then the output is ct = (a 1 , a 2 , b) ∈ R 3 such that b + a 1 (s 1 + s 2 ) + a 2 s 3 ≈ ∆f (m, m 3 ).
We note that this conversion is actually used in [AH19] to collaborate both schemes by giving a particular example (between a model owners who use a compact MKHE scheme and users who are dynamically join the computation by using MKHE). We say that this conversion can be extended to more general cases with less communication among users.
If a group of new users are joining at the same time, it would be better to extend only one component for the new group of which information is encrypted by using CMKHE than adding every component according to the number of new users. Then run MKHE . Eval algorithm between two groups (the old and the new). If new users unexpectedly join the computation, it is better to use MKHE is used from then.

Conversion MKHE into CMKHE
Before going to the conversion, we note that it is the most efficient way to use our scheme among any other CMKHE schemes such as [AH19, MTPBH21] for the conversion because it takes no round for that. Server can do everything with previously given information.
We assume a CRS for large number of k and that public keys are known to one another. Let k users have jointly computed a function value f (m 1 , . . . , m k ) based on MKHE, where the resulting evaluated MKHE ciphertext ct ∈ R k+1 q which satisfies 1 ∆ [ ct, (s 1 , . . . , s k , 1) ] q ≈ f (m 1 , . . . , m k ) mod p. A server converts it to CMKHE ciphertext for a further computation with a function g with the same joint users. Let MKHE pubic key of each user be (a, b i ) ∈ R 2 q , and secret key be s i for i ∈ [k], where a is CRS. Then the protocol between k users and a server is following: -Setup: Before computation, users share their public keys to create a common public keypk then generate conversion keys CK i (for i ∈ [k]) by running ConvKeyGen which can be precomputed. Then sends them to a server. -Server: • runs MKHEtoCMKHE(ct, The setup phase can be considered as pre-processing in many of applications. Now, we define the conversion key generation algorithm ConvKeyGen and the conversion algorithm MKHEtoCMKHE. It is basically, running similar process in key switching CMKHE . KeySwitch algorithm with conversion keys of k users. - 1 , a 2 , . . . , a k , b).
We note that the conversion key's security is also guaranteed as we discussed of the security of the evaluation keys in Section 3. Table 2. Complexity comparison between our work and other similar works. We let k be the number of users, n be a degree of ciphertext polynomial, be evaluation key parameter, σg be the variance of the gadget decomposition algorithm.

Complexity comparison with similar works
We show the complexity comparison between multikey [CDKS19] scheme and compact MKHE schemes ( [MTPBH21] and ours) in Table 2 based on what we mentioned in this section. Since both [MTPBH21] and [AH19] (as model owners side) schemes basically have same structure but [MTPBH21] improved the noise growth, so we compare [MTPBH21] as a representative previous compact MKHE scheme. We also show two kinds of MKHE [CDKS19] in the presence of pre-processing. They suggest pre-processing model to improve the time cost of relinearization by generating a common evaluation key as a setup process. Therefore, the number of users should be pre-defined in this case. As a trade-off, their storage for keys increased quadratically in k, compared to O(k) in others.
Relin noise denotes the complexity of noise growth after relinearization with evaluation keys. EvalKeyGen p user denotes the complexity of evaluation key generation algorithm per user. | evk | denotes the evaluation key (relinearization) key size which a server stores for homomorphic multiplication. Pre-processing denotes the server's computation complexity for combining evaluation keys to generate a common relinearization key before computation starts. And we show how many interactions among users for homomorphic operation are needed in general and in PKI model where public keys are stored in advance, respectively. The last column shows that if the users are required to know each other to use each scheme. We let k be the number of users.
We first look into the noise after relinearization. The compact MKHE schemes have the same k 2 factor in noise complexity as original non-compact MKHE scheme [CDKS19]. In compact MKHE schemes, the sum of k independent noise of distinct public keys are contained in a common public keys, hence, this factor influences in each evaluation key. Since the common evaluation key is the sum of k users' evaluation keys, total k 2 factors are inevitable in this construction. Regarding the noise, MKHE with pre-processing has the large complexity since they deal with large size of key sets. We show our noise analysis in Appendix A.
Then we compare the complexity of the evaluation key generation algorithm for each user in every scheme. Interactive protocols take k evaluation key materials in each round, whereas each user in MKHE scheme and ours scheme only generates its evaluation key without interaction. More precisely, in [MTPBH21] (also in [AH19]), every user generates an evaluation key material in the first round and publishes all to every user. After that, users can generate the final material by combining previously given materials and publish them to all. After gathering all final information, a common evaluation key is then generated. Therefore, they have k factor in the computation complexity since they are dealing with k information in every round, whereas users in our scheme only generate a common evaluation key on their own without interaction if public keys are known. As a result, previous CMKHE schemes [MTPBH21,AH19] takes 2 rounds for homomorphic operations and our work needs one round; distributing public keys. If we assume a public key infrastructure (PKI) as a pre-processing model, we have no round at all, whereas [MTPBH21, AH19] still require one round to generate a common evaluation key by combining additional materials.
Users in MKHE with pre-processing generate its public key and evaluation key on their own and send them to a server (or a computing party). Then the server computes a shared evaluation key by taking non-negligible time due to its large key size comparing to relatively negligible time in other CMKHE schemes. Also the server uses large storage due to large size of keys with k 2 factor. MKHE without pre-processing does not generate a shared relinearization key so a server stores all k evaluation keys of users. However, a server only stores a common evaluation key of CMKHE schemes, which occupies the smallest storage.
Consequently, we present the most efficient compact MKHE scheme for arithmetic operation until now. Moreover, in practice, our scheme may outperform than MKHE with pre-processing in terms of time, noise, memory, and network cost since it anyway requires pre-defined users, even though ours needs one round interaction among users. If a computation keeps adding new users' information, it is recommended to use practical MKHE schemes [CCS19, CDKS19] since the conversion from CMKHE to MKHE is a non-negligible time algorithm.

Conclusion
We propose an efficient evaluation key generation method for compact MKHE schemes where the size of ciphertext does not depend on the number of users. Hence, no further interaction is needed for homomorphic evaluation. Moreover, we suggest a practical conversion algorithm to efficiently convert non-compact one to compact one and the inverse direction in order to utilize unique advantages of both schemes together. In other words, compact MKHE scheme is as efficient as single-key preserving individual input privacy for free, but dynamic computation is not easily achievable since it only works for pre-defined number of users. On the other hand, original non-compact scheme allows new users to join on-going computation freely, but having ciphertext expansion. As a result, we provide multiple choices to users for their practical secure computation.

A Noise analysis on evaluation
We can provide an average-case noise analysis on variance of the noise instead of the use of other measures such as infinity norm if we use a heuristic assumption that all the coefficients of the noise independently follows subgaussian distribution or we use a real subgaussian sampling [JLP21, GMP19] for g −1 (·). We define the secret key is sampled the uniform distribution over the set of binary polynomials.
Since other algorithms are as same as previous works, we only look into the noise contained in evaluation key first. As denoted in this section, the noise contained inK i isê i .ê i = ( k t=1 s t )e i + e pk u i + e i , where e pk is an error contained in a public key. Therefore, Var(Err(K i )) = Var(ê i ) ≈ knα 2 + nα 2 + α 2 = (kn + n + 1)α 2 .
Hence, the variance of the noise in the common evaluation key is Var(Err(K)) ≈ k(nk + n + 1)α 2 . Comparing to other work [MTPBH21] which significantly reduces the output noise in evaluation key as opposed to the technique in [AJLA + 12] and its extension [AH19], we have similar (a bit smaller) noise in evaluation keys. Now we observe the error after relinearization. As we can see that, The relinearization error is g −1 (c 1 ), Err(K) The variance of this noise is following: Var Relin (ct × ) = n Var(g −1 (c 1 )) · Var(Err(K)) As a result, compact MKHE schemes have the same k 2 factor in noise complexity as original non-compact MKHE scheme [CDKS19]. In compact MKHE schemes, the sum of k independent noise of distinct public keys are contained in a common public keys, hence, this factor influences in each evaluation key. Since the common evaluation key is the sum of k users' evaluation keys, total k 2 factors are inevitable in this construction.

B Different Types of Decryption
We can use several proposed decryption algorithms depending on processing environment. In single decryptor setting, where the trusted party holds all the involved secret keys, the one can simply run CMKHE . Dec algorithm as [LTV12].
In the multi decryptor setting, where all involved users jointly decrypt a common ciphertext, the decryption is a protocol, more precisely, distributed decryption protocol taking one round. The protocol consists of two algorithms PartDec, FinDec run by each user. The FinDec is originally proposed as a public algorithm of which all inputs are public elements, but it may leak output information to the one who watch the public channel and run the public algorithm on its own, hence, it is modified to an algorithm requiring a valid secret key as an input to achieve output privacy of multikey ciphertext [LP19].
We can use all the existing solutions for different cases, hence, introduce the methods to decrypt evaluated ciphertexts of our scheme: (1) If the output privacy is not concerned such as standard MPC protocol or users employ their own secure channel, they can use the one round distributed decryption protocol [CCS19] with noise flooding technique.
(2) To achieve the output privacy through public channels, users use a decryption protocol suggested in [LP19], with re-encrypting the output of PartDec. It requires more communication cost than (1). (3) As proposed in [YKHK18], a server can run partial decryption algorithm on behalf of each user using re-encryption key given in advance, hence, there is no communication among users at decryption phase, requiring large storage and computation time of a server instead.

C Security of proposed Scheme
We first recall static adversaries of multikey homomorphic encryption schemes [LP19]. There are two types of adversaries; the internal adversary who is a member of joint users, and the external adversary who does not take part in a computation but can see what is transmitted through a public channel. The input security is achieved by the multikey IND-CPA security [KLP20] which models the same adversary as IND-CPA security except that the adversary (internal adversary) can perform the decryption by its own secret key before and after challenge phase (also with challenge message). The output security models adversaries who is an adversary of IND-CPA security except that he (external adversary) can additionally access the partial decryption oracle for each party' secret key before and after challenge step (also with challenge message) [LP19].
she can obtain the output but wishes to learn other users' inputs. The external adversary is not taking part in a computation but able to see users' transmit channel hoping to learn both input and output.
Therefore, if a scheme considers a single decryptor, it only focus on internal adversaries for security. For multi decryptor setting, a scheme should be secure against both internal and external adversaries. We show that our scheme is semantically secure in the multi decryptor setting to consider both adversaries. We follow the security game and the proof of [LP19,KLP20] Theorem 2. The scheme CMKHE with multi decryptor is semantically secure if underlying single-key BFV is semantically secure under RLWE assumption.
Proof. Let k be the number of users, (pk i , sk i ) ← CMKHE . KeyGen(params), where params ← CMKHE. Setup for i ∈ [k], and we set pk i = (a i , b i ), sk i = s i . ct be a multikey ciphertext under the common public key pk. Let {K i ← CMKHE . EvalKeyGen(pk, s i )} be evaluation keys of i-th user. Let key i ← CMKHE . EncSKGen(pk, s i ) be bootstrapping key of each user. Without loss of generality, we assume k = 2. We denote any kind of adversary of CMKHE by A and the adversary which breaks underlying BFV scheme by B. In each security game per each type of adversary [KLP20,LP19], A performs what he can do such as accessing certain oracle after receiving a challenge ciphertext ct b from a challenger of a security game, sends the value to B by letting him guess which b was chosen by the challenger. Then A forwards the answer of B to the challenger. We note that A and B cannot learn anything from {K i } and {key i } by RLWE assumption as we proved in 3.
1. For input security against an internal adversary, it is clear to see that the challenge ciphertext ct b encrypting m b under pk 1 and pk 2 . Then the internal adversary who holds sk 2 (assume he is the second user), can partially decrypt ct b with its key by performing ct b , sk 2 , resulting in a ciphertext ct b which is a BFV ciphertext encrypted under sk 1 . Then the adversary sends ct b and pk 1 to an adversary who breaks BFV scheme. In other words, the advantage of A becomes the advantage of BFV adversary B which is negligible by RLWE assumption. 2. For output security against the external adversary A which does not have any associated secret keys, we consider the decryption of [LP19] consisting of two algorithms PartDec and FinDec. For more detail, we focus on other transmitted information, partial decryption which is the output of PartDec. Our PartDec partially decrypts a multikey ciphertext with its own key then re-encrypt the result with BFV scheme by the receiver's public key. Recall the security game of [LP19], the challenge ciphertext ct b is encrypted under sk 1 , sk 2 , encrypting m b . The adversary can access to partial decryption oracle to obtain partial decryption information d 1 and d 2 , which is a BFV encryption under sk 1 and sk 2 , respectively. Then A forwards d 1 , d 2 and pk 1 , pk 2 to the BFV adversary B. Since the advantage of B is negligible due to RLWE assumption, so is A's.