Multikey Verifiable Homomorphic Encryption

A homomorphic encryption (HE) scheme is an advanced encryption technology which allows any user receiving ciphertexts to perform computations over them in a public manner. An important application of an HE scheme is a private delegating computation where clients encrypt their secret data, send the ciphertexts to a (computationally powerful) server who perform computations over encrypted data. In this application, one of the crucial problems is that the delegated server might be not trusted one and in this case, we cannot believe that a server always returns correct computation results. To solve this problem, Lai et al. (ESORICS 2014) proposed a verifiable homomorphic encryption (VHE) as a core primitive realizing private and verifiable secure delegating computation. However, their VHE scheme only supports homomorphic evaluation over ciphertexts generated by a single user. In this paper, we propose a formalization and its construction of multi-key verifiable homomorphic encryption (MVHE), which is a new cryptographic primitive for realizing private and verifiable delegated computation in the multi-client setting. Our construction can be obtained by combining a multi-key homomorphic encryption scheme and a multi-key homomorphic encrypted authentication scheme, which is also a new primitive provided in this work.


I. INTRODUCTION
A homomorphic encryption (HE) scheme is a novel and powerful cryptographic primitive having various applications. This primitive allows anyone to perform computations over encrypted data with the data kept secret from it. One of the most practically important applications of an HE scheme is private delegating computations (over clouds). Consider a situation where there are a client who has only a relatively weak computational device and a server who has more powerful computational resources. In this situation, we assume that a client wants to securely outsource his data to the (possibly malicious) remote server (for getting some computation result over his data), while allowing it to reliably perform computations over the data. Utilizing an HE scheme, we can easily realize this demand (as we call private delegating The associate editor coordinating the review of this manuscript and approving it for publication was Mohamad Afendee Mohamed . computations). Concretely, a client generates a ciphertext of his secret data and sends it to a server. Then, the server get a ciphertext of the computation result by performing (possibly heavy) homomorphic evaluations on the client's ciphertext and return it to the client. Finally, the client decrypts the evaluated ciphertext and get the computation result. 1 Obviously, as an important requirement on efficiency, the computation cost for a client should be independent from the size of a delegated function.
While this cryptographic protocol is already attractive, it has a significant concern regarding the integrity of computation results by a server. More precisely, there may be an incentive for a server trying to cheat and return an incorrect computation result to the client. This incentive might be 1 Note that a more advanced situation where a client wants computations requiring multiple inputs (by this single user) also can be solved by using an HE scheme. VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ occurred due to the nature of the performed computation (such as, the case that the server wants to convince the client of a particular result when it will give the server some benefits) or just the server's laziness for heavy computations. This problem motivates us to consider a more desirable protocol called private and verifiable delegating computation enabling a client to verify the given computation result is correct as well as get the result. 2 As a natural core cryptographic primitive for obtaining private and verifiable delegating computation, Lai et al. [20] proposed a verifiable homomorphic encryption (VHE) scheme. As the name suggests, a VHE scheme allows a user to not only decrypt the computation result but also check it is the correct evaluated value. Obviously, if given an VHE scheme, we can obtain private and verifiable delegating computation immediately. At first glance, one might think that the above private and verifiable delegating computation is sufficiently enough for practical applications. However, when taking into account of the real-world setting, we can see that it is not true. Specifically, it is important for us to consider private and verifiable delegating computations in the multi-client setting, which enables secure delegating computations on data by multiple users who have their own respective secret keys. 3 Actually, when considering some practically important applications (such as, big data analysis for medical cares), it is inherently required to support computations on data given multiple users and it is not reasonable to assume that all of the users share only one key (used both for encryption and decryption procedures). Unfortunately, almost of the previous private and verifiable delegating computations support only computations on data given by a single user. Especially, the existing Lai et al. 's VHE scheme [20] only supports homomorphic evaluation on the ciphertexts generated using the same secret key.

A. OUR CONTRIBUTION
In this paper, as a core cryptographic primitive for private and verifiable delegating computations in the multi-user setting, we propose multi-key verifiable homomorphic encryption (MVHE). Roughly, an MVHE scheme is a primitive has following features: 4 • Each user U i (having its secret key sk i ) to generate a ciphertext c i of its message m i .
• Receiving a function f (for a homomorphic evaluation) and users' ciphertexts (c i ) i∈ [n] , anyone can perform homomorphic evaluations and get an evaluated ciphertext c f for the value y = f (m 1 , · · · , m n ).
• By using all of the secret keys (sk i ) i∈ [n] , we can decrypt the evaluated ciphertext c f and verify that the evaluated value y is correct as well as get the result.
In order to obtain an MVHE scheme, we also propose a new notion of multi-key homomorphic encrypted authentication (MHEA), which is a multi-key variant of homomorphic encrypted authentication (HEA) introduced by Lai et al. [20] as a building block. 5 6 We show that an MVHE scheme can be constructed by combining a multi-key homomorphic encryption (MHE) scheme [21] and an MHEA scheme. As we will see below, MVHE plays an important role to realize private and verifiable delegating computations in the multi-client setting. We explain how to obtain a private and verifiable delegating computation in the multi-user setting by utilizing an MVHE scheme MVHE (with a multi-party computation (MPC) protocol with semi-honest security 7 ). For clarity and concreteness, we assume the situation where there are many clients (with only weak computational devices) who want to get a (shared) prediction model, while keeping all their training data secret, and there is one (malicious) server with an enough computational power for generating the prediction model. More precisely, we consider a situation where there are multiple clients (C i ) i∈ [n] and a (computationally powerful) server S and each client C i has its (secret) training data data i and they hope to get an efficient prediction model f (data 1 , · · · , data n ) computed from a (public) learning program f and their training data (data i ) i∈ [n] . Here, we assume that all of the clients (C i ) i∈ [n] are semi-honest and the server S is malicious, where ''semi-honest'' means that the (possibly corrupted) clients follow the specified protocol and nothing is leaked in the transcript. As a preparation phase, each client generates their own secret key sk i of MVHE, computes a ciphertext c i of data i using sk i by itself, and sends the ciphertext c i to S. 8 Then, given all users' ciphertexts (c i ) i∈ [n] , the server S performs the evaluation algorithm of MVHE on a (public) function f and ciphertexts (c i ) i∈ [n] for obtaining a ciphertext c f encrypting f (data 1 , · · · , data n ) and returns to the users. Upon receiving an evaluated ciphertext c f from S, the users run the decryption algorithm of MVHE (hardwired the evaluated ciphertext c f ) on a semi-honest MPC protocol given the secret keys (sk i ) i∈[n] as secret inputs. We note that 5 Note that, when referring (multi-key) homomorphic (encrypted) authentication, we only consider one requiring a secret key in the verification process, that is, the message authentication code setting. 6 We can see that MHEA is also an extension of multi-key homomorphic authentication (MHA), which was introduced in [11], with an additional property. More precisely, MHEA is MHA having a privacy requirement that ensuring that the information of an authenticated message is not revealed from the corresponding authentication. In this sense, MHEA is a stronger primitive than MHA and our construction of MVHE requires MHEA essentially for ensuring its privacy. 7 We note that various MPC protocols with semi-honest security can be constructed based solely on secret sharing schemes [4], [17]. 8 While in an actual MVHE scheme, in addition to secret keys, each user generates an (public) evaluation key ek i used by a server S for executing homomorphic evaluations including a ciphertext generated on sk i , we omit these evaluation keys for simplifying explanations. this MPC procedure among clients does not depend on the size of f due to the succinctness of the evaluated ciphertext c f . When this MPC procedure is done, all of the users can get the information of an evaluated prediction model f (data 1 , · · · , data n ). 9

B. RELATED WORKS
We briefly recall some previous related works on (fully) MHE, (fully) MHA, and private and verifiable delegating computation.

1) MULTI-KEY HOMOMORPHIC ENCRYPTION
López-Alt et al. [21] proposed the notion of MHE and its concrete construction based on the NTRU lattice. Clear and McGoldrick [8] proposed a general transformation from (fully) HE into (fully) MHE based on the learning with errors (LWE) assumption over lattices. As a result, they obtain the first MHE scheme based on the LWE assumption. Mukherjee and Wichs [23] presented a new construction of MHE having a single round threshold decryption process based on the LWE assumption by simplifying the Clear et al.'s MHE scheme. Peikert and Shiehian [25] proposed a notion of multi-hop MHE, which enables that homomorphic evaluated ciphertexts can be reused in the following homomorphic evaluations involving additional users, and its construction based on the LWE assumption (with a restriction that the number of users are limited). Brakerski and Perlman [5] proposed a similar notion called fully dynamic MHE, which is different from multi-hop MHE in that the number of users are not a-priori bounded at the setup phase, and its construction based on the LWE assumption. Chen et al. [9] proposed the first multi-hop MHE scheme based on the ring LWE assumption. Recently, Ananth et al. [1] proposed the first MHE scheme in the plain model (which does not require any trusted setup phase) based on the LWE, ring LWE, and decisional small polynomial ratio assumption.

2) MULTI-KEY HOMOMORPHIC AUTHENTICATION
(M)HA is divided into two types depending on whether a verifier's is secret or not. In the former case, an MHA is also referred as multi-key homomorphic message authentication code (MHMAC), while in the latter case referred as multi-key homomorphic signature (MHS). Gennaro and Wichs [19] proposed the first fully HMAC scheme based on a (fully) HE scheme (and pseudorandom functions). Then, Gorbunov et al. [18] proposed the first fully HS scheme based on the short integer solution (SIS) assumption. By extending the Gorbunov et al.'s HS scheme, Fiore et al. [11] proposed the first fully MHS scheme based on the SIS assumption. Lai et al. [22] introduced a new security notion called unforgeability under insider corruptions for MHS and showed that an MHS scheme satisfying such a strong security notion can be constructed from zero-knowledge succinct non-interactive arguments of knowledge (ZK-SNARK) [2], [12]. Fiore and Pagnin [14] proposed a compiler called Matrioska which transforms any (single-key) HA scheme for polynomial-sized circuits into a fully MHA scheme.

3) PRIVATE AND VERIFIABLE DELEGATING COMPUTATION
Gennaro et al. [15] firstly considered the formal notion of private and verifiable delegating computation (called verifiable computation (VC) scheme for short) and proposed its construction based on a fully HE scheme and garbled circuits. Then, Parno et al. [24] (resp., Goldwasser et al. [16]) proposed the first VC scheme based on an attribute-based encryption scheme (resp., a succinct single-key functional encryption scheme). Lai et al. [20] proposed a VHE scheme as a building block for VC. Fiore et al. [10] proposed a generic construction of VC based on a fully HE scheme and a (non-private) VC scheme and its practically efficient instantiation. Recently, Fiore et al. [13] extended the approach of [10] to support public verifiability and the evaluation of more than quadratic functions. Moreover, Bois et al. [3] proposed an improved protocol which solved the restriction on the modulus of the underlying HE scheme used in [13].
Finally, as one of the most important related works, Choi et al. [7] proposed a cryptographic protocol called a multi-client VC scheme which allows multiple clients to outsource the computation of a function f of their inputs to a server. They construct a multi-client VC scheme by combining a Gennaro et al.'s (single-client) VC scheme [15] and a proxy oblivious transfer protocol. Although their multi-client VC scheme is similar to our private and verifiable delegating computation in the multi-user setting, we have important differences between these. Firstly, before running the delegated computation, their multi-client VC scheme requires one client to execute a heavy preprocessing computation depending on the size of a function f as a setup phase. Compared to theirs, our protocol does not require any client to execute such a heavy setup phase. Secondly, while their multi-client VC scheme does not need any interaction among clients, our protocol needs to interact each other when running the decryption procedure since we execute a semi-honest MPC protocol. Compared to each other, both of them have (dis)advantages, we can say that these two notions are incomparable. 10

II. PRELIMINARIES
In this section, we provide (basic) notations and the definition of multi-key homomorphic encryption (MHE).

A. BASIC NOTATIONS
In this paper, x ← X denotes sampling an element x from a finite set X uniformly at random. y ← A(x; r) denotes that 10 One might see that these two primitives are same one except that they have different advantages.  a probabilistic algorithm A outputs y for an input x using a randomness r, and we simply denote y ← A(x) when we need not write an internal randomness explicitly. Also, x := y denotes that x is defined by y. λ denotes a security parameter. A function f (λ) is a negligible function in λ, if f (λ) tends to 0 faster than 1 λ c for every constant c > 0. negl(λ) denotes an unspecified negligible function. PPT stands for probabilistic polynomial time. ∅ denotes an empty set. If n is a natural number, [n] denotes the set of integers {1, · · · , n}. Also, if a and b are integers such that a ≤ b, [a, b] denotes the set of integers {a, · · · , b}. For convenience, we also give a table of our (basic) notations in Table 1.

B. MULTI-KEY HOMOMORPHIC ENCRYPTION
In this section, we review the definition of multi-key homomorphic encryption (MHE) and its IND-CPA security. In the following, for a polynomial t := t(λ), sets M and ID, and a function family F := {f : M t → M}, we define a program P = (f , id 1 , · · · , id t ) as a tuple of a function f and t identities id 1 , · · · , id t ∈ ID.

2) EVALUATION CORRECTNESS
Let λ ∈ N, t := t(λ) be some polynomial, pp ← MHE.Setup(1 λ ), a set of tuples of (honest) evaluation keys and secret keys {(ek id , sk id )} id∈ ID for some ID ⊆ ID, and any set of triples of programs, plaintexts, and ciphertexts

We say that an MHE scheme MHE satisfies evaluation correctness if we have
Next, we will recall IND-CPA security for MHE. Definition 2 (IND-CPA Security): Let MHE be an MHE scheme. Let n := n(λ) be a polynomial in λ. Consider the following game between a challenger C and an adversary A.
1) C chooses a challenge bit b ← {0, 1} and generates a public parameter pp ← MHE.Setup(1 λ ) and keys . Then, C sends pp and (ek 1 , · · · , ek n ) to A and prepares lists L ch := ∅ and L corr := ∅. 2) A can make polynomially many challenge queries and corruption queries as follows: , sends c to A, and appends i to L ch . Corruption Queries.When C receives a corruption query j, it checks whether j ∈ L ch holds. If this is the case, then C returns ⊥ to A. Otherwise, C sends sk j to A and appends j to L corr .
In this game, we define the advantage of the adversary A as We say that MHE satisfies IND-CPA security if for any PPT adversary A, Adv ind-cpa MHE,A (λ) = negl(λ) holds.

III. MULTI-KEY HOMOMORPHIC ENCRYPTED AUTHENTICATION
In this section, as a building block for our MVHE scheme, we provide a new cryptographic primitive called multikey homomorphic encrypted authentication (MHEA). One can see that an MHEA scheme is an extension of a multi-key homomorphic authentication (MHA) scheme given by Fiore et al. [11]. Roughly, a MHA scheme enables users (U i ) i∈[n] (having their own (distinct) secret keys (sk i ) i∈ [n] ) to generate authentications σ m i for (possibly different) messages m i . Then, based on the original authentications (σ m i ) i∈ [n] , anybody (who does not know secret keys) can homomorphically perform an arbitrary program P over the authenticated messages (m i ) i∈[n] to generate a new short authentication σ P(m 1 ,··· ,m n ) for the message P(m 1 , · · · , m n ), which ensures the validity of y = P(m 1 , · · · , m n ) as the output of P. In addition to this property of an MHA scheme, an MHEA scheme has a privacy requirement ensuring that the information of an authenticated message is not revealed from the corresponding authentication.
In the following, in Section III-A, we firstly provide the syntax of MHEA. Then, in Section III-B, we give the security notions for MHEA, unforgeability and privacy. Finally, in Section III-C, we show a candidate of instantiation of MHEA. Although the syntax and unforgeability of MHEA is the same as one of MHA given by Fiore et al. [11], we provide their formal descriptions for completeness.

A. SYNTAX
In this section, we provide the syntax of MHEA. (For convenience, in Table 1, we give a table of our notations used in Section III.) Firstly, we recall the definition of labeled programs given in [19].
Definition 3 (Labeled Programs): Let f : M t → M be a function on t variables and l i ∈ {0, 1} * for i ∈ [t] the label of the i-th input of f . A labeled program P is defined as a tuple (f , l 1 , · · · , l t ). A labeled program can be composed as follows. Given some labeled programs P 1 , · · · , P t and a function g : M t → M, the composed program P * is obtained by evaluating g on the outputs of P 1 , · · · , P t , and it is denoted as P * = g(P 1 , · · · , P t ). (The labeled inputs with the same label are grouped together and considered as a unique input of P * .) Let f id : M → M be the identity function and l ∈ {0, 1} * be any label. We refer to I l = (f id , l) as an identity program with a label l. Note that a program P = (f , l 1 , · · · , l t ) can be expressed as the composition of t identity programs f (I l 1 , · · · , I l t ).
Depending on the definition of labeled programs, we can provide the syntax and its authentication correctness, evaluation correctness, and succinctness of MHEA as follows.
Definition 4 (Multi-Key Homomorphic Encrypted Authentication): An MHEA scheme MHEA consists of the following five PPT algorithms.

MHEA.Setup:
The setup algorithm, given the security parameter 1 λ , outputs a public parameter pp. This parameter consists of a description of a tag space T , an identity space ID, a message space M, and a set of admissible functions F. Given T and ID, a label space is defined as L := ID × T . For a labeled program P = (f , l 1 , · · · , l t ) with labels , we use id ∈ P as a compact notation for id ∈ {id 1 , · · · , id t }.
The public parameter pp is an input to all of the following algorithms, even when not specified.

MHEA.KG:
The key generation algorithm, given a public parameter pp and an identity id, outputs a public evaluation key ek id and a secret authentication key sk id . MHEA.Auth: The authentication algorithm, given an authentication key sk id , a dataset identifier , a message m, a label = (id, τ ), outputs an authentication σ . MHEA.Eval: The evaluation algorithm, given a n-input where each σ i is an authentication and each EKS i is a set of evaluation keys, outputs an evaluated authentication σ * . MHEA.Ver: The verification algorithm, given a labeled program P = (f , l 1 , · · · , l t ), a dataset identifier , a set of authentication keys {sk id } id∈P corresponding to the identities involved in the program P, a message m and an authentication σ , outputs 1 (meaning ''accept'') or 0 (meaning ''reject'').

2) EVALUATION CORRECTNESS
Intuitively, we say that an MHEA scheme MHEA satisfies evaluation correctness when we run the evaluation algorithm on signatures (σ 1 , · · · , σ t ) such that each σ i verifies for m i as the output of a labeled program P i over a dataset , the output signature σ verifying for the message f (m 1 , · · · , m t ) which is the output of the composed program f (P 1 , · · · , P t ) over the dataset . More formally, let t := t(λ) be some polynomial in λ, a public parameter pp from MHEA.Setup(1 λ ), a set of key holds.

3) SUCCINCTNESS
Intuitively, an MHEA scheme MHEA is succinct if the size of every authentication depends only logarithmically on the size of a dataset. Here, we allow authentication to depend on the number of keys involved in the computation.

B. SECURITY DEFINITIONS
In this section, we provide the definitions of unforgeability and privacy for MHEA.
Definition 5 (Unforgeability for MHEA): Let MHEA be an MHEA scheme. We define the unforgeability game between a challenger C and an adversary A as follows.
2) A may adaptively make polynomially many authentication queries, verification queries, and corruption queries.
where is a dataset identifier, l = (id, τ ) is a label in ID × T and m ∈ M, it answers as follows: is the first query for the dataset , C initializes an empty list L := ∅ and proceeds as follows. b) If (id, ·) / ∈ L key holds, C generates keys (ek id , sk id ) ← MHEA.KG(pp, id) (that are implicitly assigned to identity id), gives ek id to A, and updates the list L key : ∈ L , C computes σ l ← MHEA.Auth(sk id , , l, m) (note that C has already generated keys for the identity id), returns σ l to A, and updates the list L ← L ∪ that the adversary had already made a query ( , l, m ) for some message m ), C ignores the query.
Verification Queries. When C receives (P, , m, σ ), it answers as follows: {sk id } id∈P , m, σ ) to A (using the keys in L key ). Corruption Queries. When C receives an identity id, it answers as follows: a) If (id, ·) / ∈ L key holds, then C generates (ek id , sk id ) ← MHEA.KG(pp, id) and updates the list L key := L key ∪ {(id, sk id )}. b) C returns sk id to A (stored in L key ) and updates L corr := L corr ∪ {id}.
In the above game, we say that an event Forge occurs if MHEA.Ver(P * , * , {sk id } id∈P * , m * , σ * ) = 1 for all id ∈ P * , id / ∈ L corr , and either one of the following condition holds: Type 1:L * has not been initialized during the game (i.e., the dataset * was never queried). .

C. INSTANTIATION
In this section, we show a candidate of instantiation of MHEA. An instantiation of MHEA can be obtained by applying the compiler ''Matrioska'' [14], which turns any (sufficiently expressive) single-key homomorphic authentication (HA) into a multi-key one, to the existing single-key fully HA scheme proposed by Gennaro and Wichs [19]. In the following, we explain about this instantiation. As shown by Lai et al. [20], Gennaro et al.'s HA scheme satisfies privacy in the above sense, that is, their HA scheme is already a HEA scheme due to its construction. More precisely, their scheme is constructed based on a (singlekey) fully homomorphic encryption (FHE) scheme and a pseudorandom function (PRF) F. Roughly, an authentication σ on a message m and a label τ generated in their scheme consists of (c 1 , · · · , c λ , ν), where c i is a FHE ciphertext of the message m for i ∈ [λ] and ν = F(τ ) is a value independent of m. Obviously, if the underlying FHE scheme satisfies standard IND-CPA security, then each c i does not leak any information of m, that is, their scheme satisfies privacy.
We note that, as mentioned in [19], the complexity of the verification algorithm of this HEA scheme requires at least that of executing the evaluated program P. That is, if we apply this HEA scheme to verifiable delegating computation without any efficiency improvement on the verification complexity, clients are required to perform some heavy computation which is larger than the size of P. This is not preferable to the setting of verifiable delegating computation. Gennaro et al. showed as a solution that their construction can be extended to an HEA scheme whose verification complexity is independent of the size of P by utilizing succinct non-interactive arguments for polynomial-time deterministic computations (SNARGs for P). Roughly, using the fact that the heavy computation (included in the verification step) is independent of the (authenticated) message, their trick is to delegate even the above heavy computation to the server as a homomorphic evaluation based on SNARGs for P. From the recent work [6], SNARGs for P can be constructed based on the learning with errors (LWE) assumption over lattices. Thus, we can say that this problem on efficiency is solved reasonably.
By applying the compiler Matrioska to the above (singlekey) HEA scheme, we obtain the first MHEA scheme for all polynomial-sized circuits. In fact, due to its mechanism, Matrioska inherits the privacy of a single-key HEA scheme to the (obtained) MHEA scheme. We note that, due to the restriction due to the underlying single-key HEA scheme and Matrioska, our MHEA scheme (i) is resilient to only fixed a-priori bounded number of verification queries and (ii) supports only constant number of users. These restrictions on our MHEA scheme are inherited to our MVHE scheme given in Section IV. We leave as an interesting open problem to examine how to construct a fully secure HEA scheme for all polynomial-sized circuits overcoming these restrictions. VOLUME 10, 2022

IV. MULTI-KEY VERIFIABLE HOMOMORPHIC ENCRYPTION
In this section, we introduce our target cryptographic primitive called multi-key verifiable homomorphic encryption (MVHE). Roughly, an MVHE scheme is a multi-key variant of verifiable homomorphic encryption (VHE). An MVHE scheme allows each user U i (i ∈ [n]) (having its secret key sk i ) to generate a ciphertext c i of its message m i . Then, receiving a polynomial-sized function f and their ciphertexts (c i ) i∈ [n] , anyone can perform homomorphic evaluations and get an evaluated ciphertext c f encrypting the value y = f (m 1 , · · · , m n ). By using all of the secret keys (sk i ) i∈[n] , we can decrypt the evaluated ciphertext c f and verify that the evaluated value y is correct as well as get the value y.
In the following, in Section IV-A, we provide a formal syntax and security definitions (privacy and unforgeability) of MVHE. Then, in Section IV-B, we give our construction of MVHE based on an MHE scheme and an MHEA scheme. Finally, in Section IV-C, we provide the security proofs for our MVHE scheme.

A. FORMALIZATION
In this section, we provide the formal definition of MVHE (based on the definition of labeled programs). Firstly, we give the syntax of MVHE. (For convenience, in Table 1

MVHE.Setup:
The setup algorithm, given the security parameter 1 λ , outputs a public parameter pp. This parameter consists of a description of a tag space T , an identity space ID, a plaintext space M, and a set of admissible functions F. Given T and ID, a label space is defined as L := ID × T . For a labeled program P = (f , l 1 , · · · , l t ) with labels l i := (id i , τ i ) ∈ L for any i ∈ [t], we use id ∈ P as compact notation for id ∈ {id 1 , · · · , id t }. The public parameter pp is an input to all of the following algorithms, even when not specified.

MVHE.KG:
The key generation algorithm, given a public parameter pp and an identity id, outputs an evaluation key ek id and a secret key sk id . 12 MVHE.Enc: The encryption algorithm, given a secret key sk, a dataset identifier , a label l = (id, τ ), and a message m ∈ M, outputs a ciphertext c. MVHE.Dec: The decryption algorithm, given a labeled program P, a dataset identifier , a set of secret keys (sk id ) id∈P , and a ciphertext c, outputs a messagem ∈ M ∪ {⊥}.

MVHE.Eval: The homomorphic evaluation algorithm, given a function f : M t → M and a set {(c i , EKS i )} i∈[t] , outputs an evaluated ciphertext c f , where each EKS i is a set of evaluations keys.
As the basic properties for MVHE, we require that MVHE satisfies ordinary correctness, evaluation correctness, and succinctness.  ( , l, m 0 , m 1 ) is the first query for the dataset , C initializes an empty list L = ∅ and proceeds as follows. b) If ( , l, m) is the first query with identity id (that is, (id, ·, ·) / ∈ L key ), C generates (ek id , sk id ) ← MVHE.KG(pp, id) (that are implicitly assigned to the identity id), gives ek id to A, appends (id, sk id ) to L key , and proceeds as follows. c) If ( , l, m 0 , m 1 ) is such that (l, ·) / ∈ L , C checks whether id ∈ L corr holds. If this is the case, then C returns ⊥ to A. Otherwise, C computes c l ← MVHE.Enc(sk id , , l, m b ) (note that C has already generated keys for the identity id), gives c l to A, and updates the lists L ← L ∪ (which means that A had already made a query ( , l, m ) for some plaintext m ), C ignores the query. Corruption Queries. When C receives a corruption query id, it answers as follows: a) C checks whether id ∈ L ch holds. If this is the case, then C returns ⊥ to A. b) C generates keys (ek id , sk id ) ← MVHE.KG(pp, id), gives sk id to A, and appends id to L corr .

3) A outputs a bit b ∈ {0, 1}.
In this game, we define the advantage of the adversary A as We say that MVHE satisfies privacy if for any PPT adversary A, Adv priv MVHE,A (λ) = negl(λ) holds. Definition 9 (Unforgeability for MVHE): Let MVHE be an MVHE scheme. We define the unforgeability game between a challenger C and an adversary A as follows.
2) A can adaptively make polynomially many authentication queries, verification queries, and corruption queries as follows: Authentication Queries. When C receives an authentication query ( , l, m), where is a dataset identifier, l = (id, τ ) is a label in ID × T , and m ∈ M, it answers as follows: • If ( , l, m) is the first query for the dataset , C initializes an empty list L := ∅ and proceeds as follows.

Type 3:There exists a label l
We say that an MVHE scheme MVHE satisfies unforgeability if for any PPT adversary A, We can easily see that the ordinary correctness, evaluation correctness, and succinctness of MVHE are followed due to the ordinary correctness, evaluation correctness, and succinctness of MHE and MHEA.

C. SECURITY PROOF
In this section, we show that our MVHE scheme MVHE satisfies privacy (Theorem 1) and unforgeability (Theorem 2).
Theorem 1: If MHE satisfies IND-CPA security and MHEA satisfies privacy, then MVHE satisfies privacy.
Proof of Theorem 1: Let Q key := Q key (λ) be an arbitrary polynomial that denotes the number of key pairs generated in the privacy game. Let A be any PPT adversary that attacks the privacy of MVHE. We proceed the proof via a sequence of games by introducing the following games: Game 0 : This is the original privacy game for MVHE conditioned on b = 0. The detailed description is as follows: 1) The challenger C proceeds as follows: a) C generates pp MHE ← MHE.Setup(1 λ ) and pp MHEA ← MHEA.Setup(1 λ ) and sets pp := (pp MHE , pp MHEA ). b) C gives pp to A and prepares lists L key := ∅, L ch := ∅, and L corr := ∅. 2) When A makes challenge queries and corruption queries, C answers as follows: Challenge Queries. When C receives a challenge query ( , l = (id, τ ), m 0 , m 1 ), it proceeds as follows: a) If ( , l, m 0 , m 1 ) is the first query for the dataset , C initializes an empty list L := ∅. b) If (id, ·) / ∈ L key holds, C proceeds as follows: , gives ek id to A, and appends (id, sk id ) to L key . c) If ( , l, m 0 , m 1 ) is such that (l, ·) / ∈ L , C proceeds as follows: i) C checks whether id ∈ L corr holds. If this is the case, then C returns ⊥ to A.  = (id, τ ), m 0 , m 1 ). Note that this game is the same as the original privacy game for MVHE conditioned on b = 1.
For i ∈ [0, 2], let Win i be the event that A outputs b = 0 in Game i . By using triangle inequality, we have

It remains to show how each | Pr[Win
To this end, we will show the following lemmata.  In the following, we let β be the challenge bit for B 2 in the privacy game (of MHEA). We can see that B 2 perfectly simulates Game 1 for A if it receives the challenge authentication σ MHEA ← MHEA.Auth(sk MHEA id , , l, m 0 ) from its challenger. This ensures that the probability that B 2 outputs 0 when β = 0 is exactly the same as the probability that Proof of Theorem 2: Let A be any PPT adversary that attacks the unforgeability of MVHE. The original unforgeability game is described as follows.

V. CONCLUSION
In this paper, we propose a new notion of multi-key verifiable homomorphic encryption (MVHE) as a core cryptographic primitive for realizing private and verifiable delegating computation in the multi-user setting as an application. Concretely, we provide a formal syntax and security definitions for MVHE and the generic construction based on an MHE scheme and an MHEA scheme. As mentioned in Section III-C, due to the restriction for our MHEA scheme occurred by the previous frameworks, our MVHE scheme (i) is resilient to only fixed a-priori bounded number of verification queries and (ii) supports only constant number of users. Then, we leave as an interesting open problem to examine how to construct a fully secure VHE scheme for all polynomial-sized circuits overcoming these restrictions. Also, since our work provides only a generic construction and its theoretical feasibility, we also leave to provide an efficient concrete construction of MVHE as a future work.