Decentralized Multi-Client Functional Encryption for Inner Product

. We consider a situation where multiple parties, owning data that have to be frequently updated, agree to share weighted sums of these data with some aggregator, but where they do not wish to reveal their individual data, and do not trust each other. We combine techniques from Private Stream Aggregation (PSA) and Functional Encryption (FE), to introduce a primitive we call Decentralized Multi-Client Functional Encryption (DMCFE), for which we give a practical instantiation for Inner Product functionalities. This primitive allows various senders to non-interactively generate ciphertexts which support inner-product evaluation, with functional decryption keys that can also be generated non-interactively , in a distributed way, among the senders. Interactions are required during the setup phase only. We prove adaptive security of our constructions, while allowing corruptions of the clients, in the random oracle model.


Introduction
Functional Encryption (FE) [9,15,18,28] is a new paradigm for encryption which extends the traditional "all-or-nothing" requirement of Public-Key Encryption in a much more flexible way. FE allows users to learn specific functions of the encrypted data: for any function f from a class F, a functional decryption key dk f can be computed such that, given any ciphertext c with underlying plaintext x, using dk f , a user can efficiently compute f (x), but does not get any additional information about x. This is the most general form of encryption as it encompasses identity-based encryption, attribute-based encryption, broadcast encryption.
However, whereas the input can be large, like a high-dimensional vector, the basic definition of FE implies that the input data comes from only one party: all the coordinates of the vector are provided by one party, and all are encrypted at the same time. In many practical applications, the data are an aggregation of information that comes from different parties that may not trust each other.
A naive way to distribute the ciphertext generation would be to take an FE scheme and to have a trusted party handling the setup and the key generation phases, while the encryption procedure would be left to many clients to execute by Multi-Party Computation (MPC). This straw man construction has two obvious weaknesses: 1. Generating any ciphertext requires potentially heavy interactions, with everybody simultaneously on line, and the full ciphertext has to be generated at once, with all the components being known at the same time; 2. Some authority (the trusted third party) reserves the power to recover every client's private data.
Multi-Client Functional Encryption [16,20] addresses the former issue of independent generation of the ciphertext, and we introduce Decentralized Multi-Client Functional Encryption to address the latter, without any central authority nor master secret key.
Multi-Client Functional Encryption. In Multi-Client Functional Encryption (MCFE), as defined in [16,20], the single input x to the encryption procedure is broken down into an input vector (x 1 , . . . , x n ) where the components are independent. An index i for each client and a (typically time-based) label are used for every encryption: (c 1 = Encrypt(1, x 1 , ), . . . , c n = Encrypt(n, x n , )). Anyone owning a functional decryption key dk f , for an n-ary function f and multiple ciphertexts for the same label , c 1 = Encrypt(1, x 1 , ), . . . , c n = Encrypt(n, x n , ), can compute f (x 1 , . . . , x n ) but nothing else about the individual x i 's. The combination of ciphertexts generated for different labels does not give a valid global ciphertext and the adversary learns nothing from it. MCFE is similar to the naive construction described above with MPC, except that ciphertext generation now simply takes one round, and each ciphertext c i can also be generated independently for the others.
Decentralized Multi-Client Functional Encryption. Still, MCFE requires a trusted party to generate a master key msk and to distribute the encryption keys ek i to the clients and the functional decryption keys dk f to the decryptors. In our scenario, however, the clients do not want to rely on any authority. We would thus be interested in a decentralized version of MCFE, where no authority is involved, but the generation of functional decryption keys remains an efficient process under the control of the clients themselves. We introduce the notion of Decentralized Multi-Client Functional Encryption (DMCFE), in which the authority is removed and the clients work together to generate appropriate functional decryption keys. We stress that the authority is not simply distributed to a larger number of parties, but that the resulting protocol is indeed decentralized : each client has complete control over their individual data and the functional keys they authorize the generation of.

A Use Case
Consider a financial firm that wants to compute aggregates of several companies' private data (profits, number of sales) so that it can better understand the dynamics of a sector. The companies may be willing to help the financial firm understand the sector as whole, or may be offered compensation for their help, but they don't trust the financial firm or each other with their individual data. After setting up a DMCFE, each company encrypts its private data with a time-stamp label under its private key. Together, they can give the financial firm a decryption aggregation key that only reveals a sum on the companies' private data weighted by public information (employee count, market value) for a given time-stamp. New keys can retroactively decrypt aggregates on old data.

Related Work
In their more general form, FE and MCFE schemes have been introduced in [5, 6, 10, 16-19, 27, 30] but unfortunately, they all rely on non standard cryptographic assumptions (indistinguishability obfuscation, single-input FE for circuits, or multilinear maps). It is more important in practice, and it is an interesting challenge, to build FE for restricted (but concrete) classes of functions, satisfying standard security definitions, under well-understood assumptions.
Inner-Product Functional Encryption. In 2015, Abdalla, Bourse, De Caro, and Pointcheval [1] considered the question of building FE for inner-product functions. In their paper, they show that inner-product functional encryption (IP-FE) can be efficiently realized under standard assumptions like the Decisional Diffie-Hellman (DDH) and Learning-with-Errors (LWE) assumptions [26], but in a weak security model, named selective security. Later on, Agrawal, Libert and Stehlé [4] considered adaptive security for IP-FE and proposed constructions whose security is based on DDH, LWE or Paillier's Decisional Composite Residuosity (DCR) [25] assumptions.
Private Stream Aggregation (PSA). This notion, also referred to as Privacy-Preserving Aggregation of Time-Series Data, is an older primitive introduced by Shi et al. [29]. It is quite similar to our target DMCFE scheme, however PSA does not consider the possibility of adaptively generating different keys for different inner-product evaluations, but only enables the aggregator to compute the sum of the clients' data for each time period. PSA also typically involves a Differential Privacy component, which has yet to be studied in the larger setting of DMCFE. Further research on PSA has focused on achieving new properties or better efficiency [8,11,13,21,23,24] but not on enabling new functionalities.
Multi-Input Functional Encryption. Goldwasser et al. [16] introduced the notion of Multi-Input Functional Encryption (MIFE) which breaks down a single input x into an input vector (x 1 , . . . , x n ) where the components are independent (as does MCFE), but for which there is no notion of ciphertext index or label: user i can enter x i and encrypt it as c i = Encrypt(x i ). Anyone owning a functional decryption key dk f , for an n-ary function f and multiple ciphertexts c 1 = Encrypt(x 1 ), . . . , c n = Encrypt(x n ), can compute f (x 1 , . . . , x n ) but nothing else about the individual x i 's. Numerous applications of MIFE have been given in detail in [16].
As with MCFE, general purpose MIFE schemes rely on indistinguishability obfuscation or multilinear maps, which we currently do not know how to instantiate under standard cryptographic assumptions. Extending IP-FE to the multi-input setting has proved technically challenging. [3] builds the first Multi-Input IP-FE, that is, each input slot encrypts a vector x i ∈ Z m p for some dimension m, each functional decryption key is associated with a vector y, and decryption recovers x, y where x := (x i · · · x n ), y ∈ Z n·m p , and n denotes the number of slots, which can be set up arbitrarily. They prove their construction secure under standard assumptions (SXDH, and in fact, k-Lin for any k ≥ 1) in bilinear groups. Concurrently, [22] build a two-input (i.e. n = 2) FE using similar assumptions in bilinear groups. Very recently, [2,12] gave a function-hiding multi-input FE for inner products, where the functional decryption keys do not reveal their underlying functions. [2] also gives a generic transformation from single to multi-input for IP-FE, which gives the first multi-input constructions whose security rely on DDH, LWE, or DCR.
In multi-input FE, every ciphertext for every slot can be combined with any other ciphertext for any other slot, and used with functional decryption keys to decrypt an exponential number of values, as soon as there are more than one ciphertext per slot. This "mix-and-match" feature is crucial for some of the applications of MIFE, such as building Indistinguishability Obfuscation [16]. However, it also means the information leaked about the underlying plaintext is enormous, and in many applications, the security guarantees simply become void, especially when many functional decryption keys are queried. In the case of inner product, as soon as m well-chosen functional decryption keys are queried (i.e. for linearly independent vectors), the plaintexts are completely revealed. In the multi-client setting however, since only ciphertexts with the same label (think of it as a time-stamp, for instance) can be combined for decryption, information leakage of the plaintext is much reduced.
The fact that clients have more control over how much information is leaked about their data, and that we remove the need for a central authority in the case of DMCFE, makes our schemes better suited for real-world use.

Multi-Client Functional Encryption
We remark that, as for MIFE, private-key MCFE is more relevant than its publickey counterpart (this is explained in [16], or [3] in the context of IP-FE).
Essentially, in a public-key MCFE, an encryption of unknown plaintext x i (for some label ) can be used together with encryptions of arbitrarily chosen values x j for each slot j ∈ [n] (for the same label ) and a functional decryption key for some function f , to obtain the value f (x 1 , · · · , x i1 , x i , x i+1 , · · · , x n ). Since the values x j for j = i are arbitrarily chosen, this reveals typically too much information on x i for practical uses. In the case of inner product, that means that, from Enc(i, x i , ), dk y , and the public key, one can efficiently extract the values x i y i + j =i x j y j for chosen x j , which exactly reveals the partial inner product x i y i (see [3] for more details on the limitations of public-key IP-FE in the multi-input setting).
Security is defined with an indistinguishability game, where the adversary has to distinguish between encryptions of chosen plaintexts (x 0 i ) i∈ [n] and (x 1 i ) i∈ [n] . The inherent leakage of information about the plaintext given by functional decryption keys dk f is captured by a Finalize procedure in the security game, where the advantage is set to zero if the adversary performed a trivial attack, in the sense that correctness allows the adversary to distinguish encryptions of ( , simply because the underlying functions f of the decryption keys tell apart these plaintexts, i.e. f (x 0 1 , · · · , x 0 n ) = f (x 1 1 , · · · , x 1 n ). In the public-key setting, in order to prevent the adversary from a trivial win, one should make the restriction that the adversary is only allowed to ask functional decryption keys dk f for functions f that satisfy f (x 0 1 , ·, . . . , ·) = f (x 1 1 , ·, . . . , ·), f (·, x 0 2 , . . . , ·) = f (·, x 1 2 , . . . , ·), . . . , f (·, ·, . . . , x 0 n ) = f (·, ·, . . . , x 1 n ). Again, this would essentially exclude any function. A private-key encryption solves this issue, and is still well-suited for practical applications.
In this paper, we will thus consider this private-key setting which naturally fits the MCFE (and DMCFE) model as each component in the plaintext is separately provided by a different client. In such a case, the corruption of some clients is an important issue, since several of them could collude to learn information about other clients' inputs. More precisely, we propose such an MCFE for Inner-Product functions in Section 4, that is secure even against adaptive corruptions of the senders.

Decentralized Multi-Client Functional Encryption
While it allows independent generation of the ciphertexts, MCFE (like MIFE) still assumes the existence of a trusted third-party who runs the SetUp algorithm and distributes the functional decryption keys. This third-party, if malicious or corrupted, can easily undermine any client's privacy. We are thus interested in building a scheme in which such a third-party is entirely taken out of the equation.
We thus introduce the notion of Decentralized Multi-Client Functional Encryption (DMCFE), in which the setup phase and the generation of functional decryption keys are decentralized among the same clients as the ones that generate the ciphertexts. We are interested in minimizing interactions during those operations. While one can do it, in a generic way, using MPC, our target is at least a non-interactive generation of the functional decryption keys, that we achieve in Section 5, again for Inner-Product functions. The one-time setup phase might remain interactive, but this has to be done once only.
SetUp Pick (si) i∈[n] at random Pick (si) i∈[n] at random and set vi = g s i

Technical Overview
We briefly showcase the techniques that allow us to build efficient MCFE and DMCFE schemes. The schemes we introduce later enjoy adaptive security (aka full security), where encryption queries are made adaptively by the adversary against the security game, but for the sake of clarity, we will here give an informal description of a selectively-secure scheme from the DDH assumption, where queries are made beforehand. Namely, the standard security notion for FE is indistinguishability-based, where the adversary has access to a Left-or-Right oracle, that on input (m 0 , m 1 ) either always encrypts m 0 or always encrypts m 1 . While for the adaptive security, the adversary can query this oracle adaptively, in the selective setting, all queries are made at the beginning, before seeing the public parameters.
We first design a secret-key MCFE scheme building up from the public-key FE scheme introduced by Abdalla et al. [1] (itself a selectively-secure scheme) where we replace the global randomness with a hash function (modeled as a random oracle for the security analysis), in order to make the generation of the ciphertexts independent for each client. The comparison is illustrated in Figure 1. Note that for the final decryption to be possible, one needs the function evaluation γ to be small enough, within this discrete logarithm setting. This is one limitation, which is still reasonable for real-world applications that use concrete numbers, that are not of cryptographic size.
If we write c 0 = g r in the single input case and c 0 = H( ) in the Multi-Client case, we have c i = g xi c 0 si for i ∈ [n] in both cases. In the public-key scheme from [1], s i was private, and only v i = g si was known to the encryptor. Since we are now dealing with private encryption, the encryptor can use s i . Correctness then follows from We further define this MCFE scheme and prove it selectively secure under the DDH assumption in Appendix B. We can easily decentralize the above protocol using standard MPC techniques, but as we mentioned, our main goal is to minimize interactions during the DKeyGen protocol. This simple protocol can illustrate our main insight: we need to provide the aggregator with the decryption key s, y . Since the s i 's are owned individually by the clients, we are interested in a protocol that would let them send shares from which the decryptor would recover an agreed upon Inner Product on their individual inputs. This sounds like a job for MCFE.
More precisely, sending Encrypt(s i ) under some other key t i would not solve our problem, because we would still need to provide t, y to enable decryption, so we send Encrypt(y i s i ) under t i . Now we only need to compute one decryption key: the key for the inner product with vector 1 = (1, . . . , 1), There is one final caveat. The result of the inner product evaluation requires a final discrete logarithm computation, and we are no longer operating on real-world data, but on random elements from Z p . Any attempt to recover the discrete logarithm is hopeless, and we are stuck with g s,y . We work around this issue by using pairings, which effectively enable us to decrypt using only g s,y . The standard SXDH assumption on pairing groups states that the DDH assumption holds in both groups, so introducing pairings doesn't compromise the security of our scheme. Our fully-secure DMCFE from pairings, that inherits from this approach, is described in Section 5.

Contributions
Practical constructions of functional encryption for specific classes of functions is of high interest. In this paper, we focus on MCFE and DMCFE for Inner Product.
We present the first solutions for Inner-Product Functional Encryption in the Multi-Client and Decentralized Multi-Client settings: 1. Efficiency: the proposed schemes are highly practical as their efficiency is comparable to that of the DDH-based IP-FE scheme from [4]. A value x i is encrypted as a unique group element C i . The setup phase, key generation and decryption all take time linear in the number of participants, and encryption takes time linear in its input. 2. Security under a standard assumption: our schemes are all adaptively secure under either the classical DDH assumption or the standard SXDH assumption. 3. Security against adaptive corruptions: In addition, we successfully address corruptions of clients, even adaptive ones in the MCFE setting, exploring what Goldwasser et al. [16] highlighted as an "interesting direction".

Non interactivity:
The DMCFE scheme we present in Section 5 has a key generation protocol that does not require interactions.
Refer to Figure 2  leave open the problems of considering LWE-based or Paillier-based constructions and of extending this work beyond inner-product functions.

Definitions and Security Models
This section is devoted to defining MCFE and DMCFE and the security models that are appropriate for those primitives, in the indistinguishability setting.

Multi-Client Functional Encryption
An MCFE scheme encrypts vectors of data from several senders and allows the controlled computation of functions on these heterogeneous data. We now define a private-key MCFE as in [16,20]: Definition 1 (Multi-Client Functional Encryption). A multi-client functional encryption on M over a set of n senders is defined by four algorithms: -SetUp(λ): Takes as input the security parameter λ, and outputs the public parameters mpk, the master secret key msk and the n encryption keys ek i ; -Encrypt(ek i , x i , ): Takes as input a user encryption key ek i , a value x i to encrypt, and a label , and outputs the ciphertext C ,i ; -DKeyGen(msk, f ): Takes as input the master secret key msk and a function f : M n → R, and outputs a functional decryption key dk f ; -Decrypt(dk f , , C): Takes as input a functional decryption key dk f , a label , and an n-vector ciphertext C, and outputs f (x), if C is a valid encryption of x = (x i ) i ∈ M n for the label , or ⊥ otherwise.
We make the assumption that mpk is included in msk and in all the encryption keys ek i as well as the functional decryption keys dk f . The correctness property states that, given (mpk, msk, (ek i ) i ) ← SetUp(λ), for any label , any function f : M n → R, and any vector The security model is quite similar to the one defined for FE, but as noted in [16,20], one has to consider corruptions, since the senders do not trust each other, and they can collude and give their secret keys to the adversary who will play on their behalf. . We note that any further query for the same pair ( , i) will later be ignored; -Functional decryption key queries QDKeyGen(f ): A has unlimited and adaptive access to the DKeyGen(msk, f ) algorithm for any input function f of its choice. It is given back the functional decryption key dk f ; -Corruption queries QCorrupt(i): A can make an unlimited number of adaptive corruption queries on input index i, to get the encryption key ek i of any sender i of its choice; -Finalize: A provides its guess b on the bit b, and this procedure outputs the result β of the security game, according to the analysis given below.
The output β of the game depends on some conditions, where CS is the set of corrupted senders (the set of indexes i input to QCorrupt during the whole game), and HS the set of honest (non-corrupted) senders. We set the output to β ← b , unless one of the three cases below is true, in which case we set β $ ← {0, 1}: has been asked for some i ∈ HS, but encryption-queries QEncrypt(j, x 0 j , x 1 j , ) have not all been asked for all j ∈ HS; 3. for some label and for some function f asked to QDKeyGen, there exists a pair of vectors Informally, this is the usual Left-or-Right indistinguishability [7], but where the adversary should not be able to get ciphertexts or functional decryption keys that trivially help distinguish the encrypted vectors: 1. since the encryption might be deterministic, if we allow Left-or-Right encryption queries even for corrupted encryption keys, these queries should be on identical messages: with the encryption key, the adversary could simply re-encrypt and compare in case of deterministic encryption; 2. intuitively, if some input is missing, no function evaluation can be done by the adversary, so we enforce the adversary to ask QEncrypt-queries for all the non-corrupted keys (since the adversary can generate any ciphertext itself for the corrupted components) as soon as one label is used; 3. for any functional decryption key, all the possible evaluations should not trivially allow the adversary to distinguish the ciphertexts generated through QEncrypt-queries (on honest components).
In all these cases, the guess of the adversary is not considered (a random bit β is output). Otherwise, this is a legitimate attack, and the guess b of the adversary is output. We stress that we bar the adversary from querying several ciphertexts under the same pair ( , i). In real life, it is of course the responsibility of the senders not to encrypt under the same label twice (as explained in the introduction, the labels are typically time-stamps, only used once).
Remark 3. While the third constraint aims at preventing the adversary from trivially winning by guessing the bit b from the evaluation of a functional decryption, the two first might look artificial, but they are required for our proof to go through with our constructions: with a probabilistic encryption scheme, one could hope to remove the first one, but up to now, we only have deterministic constructions, which is quite classical in the private-key setting (such as symmetric encryption); depending on the scheme, an encryption on an "inactive" component (a component that has no impact on the value of a function f , for instance the ith ciphertext in the case of f y : x → x, y when y i = 0) might not be needed for a complete evaluation, as is the case in our schemes (see Section 4). Moreover, our keys are homomorphic: from dk fy and dk f y , one can easily obtain dk f y+y . Rather than defining the inactivity of components of functions in the span of those queried, we simply require that ciphertexts be obtained for every component for a given label (either through an explicit query to QEncrypt or thanks to the encryption key obtained from QCorrupt), which is consistent with the use-case we outlined in Section 1.1. One could also enforce, by construction, all the queries to be asked and otherwise guarantee that no information is leaked about the plaintexts, which is not the case of our schemes.
Weaker Notions. One may define weaker variants of indistinguishability, where some queries can only be sent before the initialization phase: -Selective Security (sel-IND): the encryption queries (QEncrypt) are sent before the initialization; -Static Security (sta-IND): the corruption queries (QCorrupt) are sent before the initialization.

Decentralized Multi-Client Functional Encryption
In MCFE, an authority owns a master secret key msk to generate the functional decryption keys. We would like to avoid such a powerful authority, and make the scheme totally decentralized among the owners of the data (the senders). We thus define DMCFE, for Decentralized Multi-Client Functional Encryption. In this context, there are n senders (S i ) i , for i = 1, . . . , n, who will play the role of both the encrypting players and the functional decryption key generators, for a functional decryptor FD. Of course, the senders do not trust each other and they want to control the functional decryption keys that will be generated. There may be several functional decryptors, but since they could collude and combine all the functional decryption keys, in the description below, and in the security model, we will consider only one functional decryptor FD. As already noticed, we could simply use the definition of MCFE [16,20], where the setup and the functional decryption key algorithms are replaced by MPC protocols among the clients. But this could lead to a quite interactive process. We thus focus on efficient one-round key generation protocols DKeyGen that can be split in a first step DKeyGenShare that generates partial keys and the combining algorithm DKeyComb that combines partial keys into the functional decryption key.

Definition 4 (Decentralized Multi-Client Functional Encryption).
A decentralized multi-client functional encryption on M between a set of n senders (S i ) i , for i = 1, . . . , n, and a functional decrypter FD is defined by the setup protocol and four algorithms: -SetUp(λ): This is a protocol between the senders (S i ) i that eventually generate their own secret keys sk i and encryption keys ek i , as well as the public parameters mpk; -Encrypt(ek i , x i , ): Takes as input a user encryption key ek i , a value x i to encrypt, and a label , and outputs the ciphertext C ,i ; -DKeyGenShare(sk i , f ): Takes as input a user secret key sk i and a label f , and outputs the partial functional decryption key dk f,i for a function f : M n → R that is described in f ; -DKeyComb((dk f,i ) i , f ): Takes as input the partial functional decryption keys and eventually outputs the functional decryption key dk f ; -Decrypt(dk f , , C): Takes as input a functional decryption key dk f , a label , and an n-vector ciphertext C, and outputs f (x), if C is a valid encryption of x = (x i ) i ∈ M n for the label , or ⊥ otherwise; We make the assumption that mpk is included in all the secret and encryption keys, as well as the (partial) functional decryption keys. Similarly, the function f might be included in the (partial) functional decryption keys. The correctness property states that, given (mpk, (sk i ) i , (ek i ) i ) ← SetUp(λ), for any label , any function f : M n → R, and any vector The security model is quite similar to the one defined above for MCFE, except that for the DKeyGen protocol, the adversary has access to transcripts of the communications and can make some senders play maliciously. Corrupt-queries additionally reveal the secret keys sk i . The output β of the game depends on some conditions, where CS is the set of corrupted senders (the set of indexes i input to QCorrupt during the whole game), and HS the set of honest (non-corrupted) senders. We set the output to β ← b , unless one of the three cases below is true, in which case we set β $ ← {0, 1}: 1. some QEncrypt(i, x 0 i , x 1 i , )-query has been asked for an index i ∈ CS with x 0 i = x 1 i ; 2. for some label , an encryption-query QEncrypt(i, x 0 i , x 1 i , ) has been asked for some i ∈ HS, but encryption-queries QEncrypt(j, x 0 j , x 1 j , ) have not all been asked for all j ∈ HS; 3. for some label and for some function f asked to QDKeyGen for all i ∈ CS, there exists a pair of vectors We define sel-IND (selective) and sta-IND (static) security for DMCFE as we did for MCFE.

Groups
Prime Order Group. We use a prime-order group generator GGen, a probabilistic polynomial time (PPT) algorithm that on input the security parameter 1 λ returns a description G = (G, p, P ) of an additive cyclic group G of order p for a 2λ-bit prime p, whose generator is P .
We use implicit representation of group elements as introduced in [14]. For a ∈ Z p , define [a] = aP ∈ G as the implicit representation of a in G. More generally, for a matrix A = (a ij ) ∈ Z n×m p we define [A] as the implicit representation of A in G: We will always use this implicit notation of elements in G, i.e., we let [a] ∈ G be an element in G. Note that from a random [a] ∈ G it is generally hard to compute the value a (discrete logarithm problem in G). Obviously, given Pairing Group. We also use a pairing group generator PGGen, a PPT algorithm that on input 1 λ returns a description PG = (G 1 , G 2 , p, P 1 , P 2 , e) of asymmetric pairing groups where G 1 , G 2 , G T are additive cyclic groups of order p for a 2λ-bit prime p, P 1 and P 2 are generators of G 1 and G 2 , respectively, and e : G 1 × G 2 → G T is an efficiently computable (non-degenerate) bilinear map. Define P T := e(P 1 , P 2 ), which is a generator of G T . We again use implicit representation of group elements. For s ∈ {1, 2, T } and a ∈ Z p , define [a] s = aP s ∈ G s as the implicit representation of a in G s . Given Compatibility. Our construction from Section 4 uses a prime-order group, while the one from Section 5 uses pairing groups. Since the latter use the former as a building block, we must use groups that are compatible with each other. Notice that one can generate a prime-order group either with G := (G, p, P ) $ ← GGen(1 λ ), but also using PG := (G 1 , G 2 , p, P 1 , P 2 , e) $ ← PGGen(1 λ ), and setting G := G 1 . This is possible here because we use asymmetric pairings and rely on the SXDH assumption in the pairing group, which is DDH in G 1 and G 2 . More details on computational assumptions follow.

Computational Assumptions
Definition 6 (Decisional Diffie-Hellman Assumption). The Decisional Diffie-Hellman Assumption states that, in a prime-order group G $ ← GGen(1 λ ), no PPT adversary can distinguish between the two following distributions with non-negligible advantage:

A Fully-Secure MCFE for Inner Product
After the first construction drafted in the introduction, from the Abdalla et al. [1] selectively-secure FE, we propose another construction of MCFE for inner product adapted from the Agrawal et al. [4] scheme. We also provide the full security analysis under the DDH assumption, since the security proof of our DMCFE construction will rely on it.
Overview of the Construction. This construction is an extension of the previous one proposed in the introduction: we first extended the scheme from Abdalla et al. [1] in the multi-client setting with a hash function. Because of the selective security of the underlying scheme, our first proposal was just selectively secure too. We now adapt the Agrawal et al. [4] scheme, in the same manner. This construction and its proof of adaptive security are for the sake of clarity, since the proof of our next DMCFE will be made clearer when reducing to this one.

Description
We use a prime-order group, and the bracket notation, as defined in Section 3.1. Note that, as for [4], the result α must be polynomially bounded to efficiently compute the discrete logarithm in the last decryption step: let x, y ∈ Z n p , we have:

Security Analysis
Theorem 8 (IND-Security). The above MCFE protocol (see Section 4.1) is INDsecure under the DDH assumption, in the random oracle model. More precisely, we have for any adversary A, running within time t, where Q is the number of (direct and indirect -asked by QEncrypt-queries-) queries to H (modeled as a random oracle), and t G is the time for an exponentiation in G.
We stress that this Theorem supports both adaptive encryption queries and adaptive corruptions.
Proof Technique. To obtain adaptive security, we use a technique that consists of first proving perfect security in the selective variant of the involved games, then, using a guessing (a.k.a. complexity leveraging) argument, which incurs an exponential security loss, we obtain the same security guarantees in the adaptive games. Since the security in the selective game is perfect (the advantage of any adversary is exactly zero), the exponential security loss is multiplied by a zero term, and the overall adaptive security is preserved. This technique has been used before in [31] in the context of Attribute-Based Encryption, or more recently, in [2,3] in the context of multi-input IP-FE. We defer to [31,Remark 1] and [3,Remark 5] for more details on this proof technique.
Proof. We proceed using hybrid games, described in Fig. 3. Let A be a PPT adversary. For any game G index , we denote by Adv index : where the probability is taken over the random coins of G index and A. Also, by event G index (A), or just G index when there is no ambiguity, we mean that the Finalize procedure in game G index (defined as in Definition 2) returns β = 1 from the adversary's answer b when interacting with A.  Game G 0 : This is the IND-security game as given in Definition 2. Note that the hash function H is modeled as a random oracle RO onto G 2 . This is essentially used to generate [u ] = H( ). Game G 1 : We simulate the answers to any new RO-query by a truly random pair in G 2 , on the fly. The simulation remains perfect, and so Adv 0 = Adv 1 . Game G 2 : We simulate the answers to any new RO-query by a truly random pair in the span of [a] for a := ( 1 a ) , with a $ ← Z p . This uses the Multi-DDH assumption, which tightly reduces to the DDH assumption using the random-self reducibility (see Lemma 10,in where Q is the number of RO-queries and t G the time for an exponentiation. Game G 3 : We simulate any QEncrypt query as the encryption of x 0 i instead of x b i and go back for the answers to any new RO query by a truly random pair in G 2 .
is computed on the j-th RO-query with j < q: is computed on the q-th RO-query, then:   While it is clear that in this last game the advantage of any adversary is exactly 0 since b does not appear anywhere, the gap between G 2 and G 3 will be proven using a hybrid technique on the RO-queries. We thus index the following games by q, where q = 1, . . . , Q. Note that only distinct RO-queries are counted, since a second similar query is answered as the first one. We detail this proof because the technique is important.

QDKeyGen(y):
We first change the distribution of the output of the q-th ROquery, from uniformly random in the span of [a] to uniformly random over G 2 , using the DDH assumption. Then, we use the basis (( 1 a ) ,( −a 1 ) ) of Z 2 p , to write a uniformly random vector over Z 2 p as u 1 · a + u 2 · a ⊥ , where u 1 , u 2 $ ← Z p . Finally, we switch to u 1 · a + u 2 · a ⊥ where u 1 $ ← Z p , and u 2 $ ← Z * p , which only changes the adversary view by a statistical distance of 1/p: Adv 3.q.1 − Adv 3.q.2 ≤ Adv ddh G (t) + 1/p. The last step with u 2 ∈ Z * p will be important to guarantee that u a ⊥ = 0. G 3.q.2 G 3.q. 3 : We now change the generation of the ciphertext [c i ] : corresponds to the q-th RO-query. We then prove this does not change the adversary's view. Note that if the output of the q-th RO-query is not used by QEncrypt-queries, then the games G 3.q.2 and G 3.q.3 are identical. But we can show this is true too when there are RO-queries that are really involved in QEncryptqueries, and show that Adv 3.q.2 = Adv 3.q.3 in that case too, in two steps. In Step 1, we show that there exists a PPT adversary B such that Adv 3.q.t = (p 2 + 1) n · Adv 3.q.t (B ), for t = 2, 3, where the games G 3.q.2 and G 3.q.3 are selective variants of games G 3.q.2 and G 3.q.3 respectively (see Fig. 4), where QCorrupt queries are asked before the initialization phase. In Step 2, we show that for all PPT adversaries B , we have Adv 3.q.2 (B ) = Adv 3.q.3 (B ). This will conclude the two steps.
Step 1. We build a PPT adversary B playing against G 3.q.t for t = 2, 3, such that Adv 3.q.t = (p 2 + 1) n · Adv 3.q.t (B ). Adversary B first guesses for all i ∈ [n], z i $ ← Z 2 p ∪ {⊥}, which it sends to its selective game G 3.q.t . That is, each guess z i is either a pair of values (x 0 i , x 1 i ) queried to QEncrypt, or ⊥, which means no query to QEncrypt. Then, it simulates A's view using its own oracles. When B guesses successfully (call E that event), it simulates A's view exactly as in G 3.q.t . If the guess was not successful, then B stops the simulation and outputs a random bit β.
Since event E happens with probability (p 2 + 1) −n and is independent of the view of adversary A: Adv 3.q.t (B ) is equal to Step 2. We assume the values (z i ) i∈[n] sent by B are consistent, that is, they don't make the game end and return a random bit, and Finalize on b does not return a random bit independent of b (call E this event). We show that games G 3.q.2 and G 3.q.3 are identically distributed, conditioned on E . To prove it, we use the fact that the two following distributions are identical, for any choice of γ: p , for all i = 1, . . . , n. This is true since the s i are independent of the z i (note that this is true because we are in a selective setting, while this would not necessarily be true with adaptive QEncrypt-queries). Thus, we can re-write s i into s i + a ⊥ · γ(x b i − x 0 i ) without changing the distribution of the game. We now take a look at where the extra terms a ⊥ · γ(x b i − x 0 i ) actually appear in the adversary's view: -They do not appear in the output of QCorrupt, because we assume event E holds, which implies that if z i = ⊥, then i is not queried to QCorrupt or x 1 i = x 0 i . -They might appear in QDKeyGen(y) as But the gray term equals 0 by the constraints for E in Definition 2: for all i ∈ HS, z i = ⊥; if i ∈ CS and z i = ⊥, Since u a ⊥ = 0, we can choose γ = −1/u a ⊥ mod p, and then i ], which is the encryption of x 0 i . We stress that γ is independent of the index i, and so this simultaneously converts all the encryptions of x b i into encryptions of x 0 i . Finally, reverting these statistically perfect changes, we obtain that i ], as in game G 3.q.3 . Thus, when event E happens, the games are identically distributed. When ¬E happens, the games both return β $ ← {0, 1}: Adv 3.q.2 (B ) = Adv 3.q.3 (B ). As a conclusion, we get Adv 3.q.2 = Adv 3.q.3 . G 3.q.3 G 3.q+1.1 : This transition is the reverse of G 3.q.1 G 3.q.2 , namely, we use the DDH assumption to switch back the distribution of [u ] computed on the q-th RO-query from uniformly random over G 2 (conditioned on the fact that u a ⊥ = 0) to uniformly random in the span of [a]: Adv 3.q.3 − Adv 3.q+1.1 ≤ Adv ddh G (t) + 1/p. As a conclusion, since G 3.Q+1.1 = G 3 , we have Adv 2 −Adv 3 ≤ 2Q(Adv ddh G (t)+1/p). In addition, Adv 3 = 0, which concludes the proof.

A Statically-Secure DMCFE for Inner Product
Overview of the Scheme. Our construction of MCFE for inner product uses functional decryption keys dk y = (y, s, y ) = (y, d), where d = s, y = i s i y i = t, 1 , with t i = s i y i , for i = 1, . . . , n, and 1 = (1, . . . , 1). Hence, one can split msk = s into msk i = s i , define T (msk i , y) = t i = s i y i and F (t) = t, 1 . We could thus wish to use the above generic construction from the introduction with our MCFE for inner product, that is self-enabling, to describe a DMCFE for inner product. However, this is not straightforward as our MCFE only allows small results for the function evaluations, since a discrete logarithm has to be computed. While, for real-life applications, it might be reasonable to assume the plaintexts and any evaluations on them are small enough, it is impossible to recover such a large scalar as d = s, y , which comes up when we use our scheme to encrypt encryption keys.
Nevertheless, following this idea we can overcome the concern above with pairings: One can only recover [d], but using a pairing e : G 1 × G 2 → G T , one can use our MCFE in both G 1 and G 2 . This allows us to compute the functional decryption in G T , to get [ x, y ] T , which is decryptable as x, y is small enough.

Construction
Let us describe the new construction, using an asymmetric pairing group, as in Section 3.1.  y): on input y ∈ Z n p that defines the function f y (x) = x, y , and the secret key Correctness: Let x, y ∈ Z n p , we have: Thus:

Security Analysis
Theorem 9 (sta-IND-Security). The above DMCFE protocol (see Section 5.1) is sta-IND secure under the SXDH assumption, in the random oracle model. Namely, for any PTT adversary A, there exist PPT adversaries B 1 and B 2 such that: where Q 1 and Q 2 are the number of (direct and indirect) queries to H 1 and H 2 respectively (modeled as random oracles). The former being asked by QEncryptqueries and the latter being asked by QDKeyGen-queries.
We stress that this Theorem supports adaptive encryption queries, but static corruptions only.
Proof. We proceed using hybrid games, described in Fig. 5, with similar notations as in the previous proof.
Game G 0 : This is the sta-IND-security game as given in Definition 5, but with the set CS of corrupted senders known from the beginning. Note that the hash functions H 1 and H 2 are modeled as random oracles. The former is used to generate [u ] 1 := H 1 ( ) ∈ G 2 1 and the latter [v y ] 2 := H 2 (y) ∈ G 2 2 . Game G 1 : We replace the hash function H 2 by a random oracle RO 2 that generates random pairs from G 2 2 on the fly. In addition, for any QDKeyGenquery on a corrupted index i ∈ CS, one generates the partial functional decryption key by itself, without explicitly querying QDKeyGen. Hence, we can assume that A does not query QCorrupt and QDKeyGen on the same indices i ∈ [n]. The simulation remains perfect, and so Adv 0 = Adv 1 . Game G 2 : Now, the outputs of RO 2 are uniformly random in the span of [b] 2 for b := ( 1 a ) , with a $ ← Z p . As in the previous proof, we have Adv 1 − Adv 2 ≤ Adv ddh G2 (t + 4Q 2 × t G2 ), where Q 2 is the number of RO 2 -queries and t G2 the time for an exponentiation. Game G 3 : We replace all the partial key decryption answers by dk y,i : for each y. We show below that Adv 2 = Adv 3 . Game G 4 : We switch back the distribution of all the vectors [v y ] 2 output by RO 2 , from uniformly random in the span of [b] 2 , to uniformly random over G 2 2 , thus back to H 2 (y). This transition is reverse to the two first transitions of this proof: Adv 3 − Adv 4 ≤ Adv ddh G2 (t + 4Q 2 × t G2 ).
In order to prove the gap between G 2 and G 3 , we do a new hybrid proof: Game G 3.1.1 : This is exactly game G 2 . Thus, Adv 2 = Adv 3.1.1 .
, such that i∈[n] Ti = 0 eki := si, ski := (si, Ti), mpk := (G, p, g).   random functions RF i are computed on the fly, such that their sum is the zero function.
We stress that this last simulation requires to know CS and HS, hence static corruptions only. From this reduction, one gets where Q 1 denotes the number of calls to RO 1 , t G1 denotes the time to compute an exponentiation in G 1 . This concludes the proof.

Conclusion
Multi-Client Functional Encryption and Decentralized Cryptosystems are invaluable tools for many emerging applications such as cloud services or big data. These applications often involve many parties who contribute their data to enable the extraction of knowledge, while protecting their individual privacy with minimal trust in the other parties, including any central authority. We make an important step towards combining the desired functionalities and properties by introducing the notion of Decentralized Multi-Client Functional Encryption. It opens some interesting directions: -For inner-product, in the DDH-based setting with ElGamal-like encryption, we have a strong restriction on the plaintexts, since the inner-product has to be small, in order to allow complete decryption of the scalar evaluation. It is an interesting problem to consider whether the LWE-based and DCR-based schemes can address this issue. -Getting all the desired properties, namely efficiency, new functionalities and the strongest security level, is a challenging problem. One of the main challenges is to construct an efficient, non-interactive DMCFE which is fully secure (adaptive encryptions and adaptive corruptions), for a larger class of functions than that of inner-product functions. The security analyses of our concrete constructions heavily rely on the linear properties of inner-product functions, however, the global methodology of the constructions themselves is not restricted to the inner-product setting. Therefore, new constructions could follow it.

A Multi DDH Assumption
Theorem 10. For any distinguisher A running within time t, the best advantage A can get in distinguishing is bounded by Adv ddh (t + 4m × t G ), where t G is the time for an exponentiation in G.
Proof. One can first note that the best advantage one can get, within time t, between is bounded by Adv ddh (t). This is actually the DDH assumption. One can note that D m and D m can be rewritten as Since, from (X, Y, Z), the m tuples require 4 additional exponentiations per index j, one get the expected bound.
B A Selectively-Secure MCFE

B.1 Description
In this section, we formally present the selectively secure MCFE scheme for inner product we described in Section 1. It is inspired by Abdalla et al.'s scheme [1]: -SetUp(λ): Takes as input the security parameter, and generates a group G of prime order p ≈ 2 λ , g ∈ G a generator, and H a full-domain hash function onto G. It also generates the encryption keys s i $ ← Z p , for i = 1, . . . , n, and sets s = (s i ) i . The public parameters mpk consist of (G, p, g, H), while the master secret key is msk = s and the encryption keys are ek i = s i for i = 1, . . . , n (in addition to mpk, which is omitted); , and eventually solves the discrete logarithm to extract and return α.
As for Abdalla et al.'s scheme [1], the result α should not be too large to allow the final discrete logarithm computation.
Correctness : if the scalar dk in the decryption functional key dk y = (y, dk) is indeed dk = s, y , then

B.2 Selective Security
Like Abdalla et al.'s original scheme [1], our protocol can only be proven secure in the weaker security model, where the adversary has to commit in advance to all of the pairs of messages for the Left-or-Right encryption oracle (QEncrypt-queries). However, it can adaptively ask for functional decryption keys (QDKeyGen-queries) and encryption keys (QCorrupt-queries). Concretely, the challenger is provided (plaintext,label) pairs: (x b j,i , j ) b∈{0,1},i∈[n],j∈ [Q] , where Q is the number of query to QEncrypt(i, ·, ·), each one for a different label j (note that in the security model, we assume each slots are queried the same number of time, on different labels). The challenge ciphertexts C i,j = Encrypt(ek i , x b j,i , j ), for the random bit b, are returned to the adversary.
Note that the adversary committing to challenge ciphertexts also limits its ability to corrupt users during the game: it must corrupt clients for which it didn't ask a ciphertext and cannot corrupt any client from which it asked a ciphertext for x 0 j,i = x 1 j,i .

B.3 Security Analysis
Theorem 11 (sel-IND Security). The MCFE protocol described above (see Appendix B.1) is sel-IND secure under the DDH assumption, in the random oracle model. More precisely, we have for any adversary A, running within time t, where Q is the number of encryption queries per slot.
Proof. We proceed using hybrid games, described in Fig. 6, with the same notations as in the previous proofs.
Game G 0 : This is the sel-IND security game as given in Definition 2 (see the paragraph about weaker models), with all the encryption queries being sent first: they are stored in z j,i = (x 0 j,i , x 1 j,i ), for j ∈ [Q] and i ∈ [n], where j is for the j-th H-query that specifies the label j and i is for the index of the sender. If the query is not asked, we have z j,i = ⊥. Note that the hash function H is modeled as a random oracle RO onto G. This is used to generate [u ] = H( ).