 nothing more. So, for instance, think of M as a function that computes descriptive statistics on the encrypted data or SQL queries or some such things. So, the goal is to reconcile privacy and useful data mining. And so, other user, Carol, should get access to a different function G applied on the data M and and nothing more. So, this has been generalized to the multi-input setting where different user encrypts different messages independently for different input slots. And the user can extract from this ciphertext some partial information on the joint messages M1 and M2. So, now there are binary functions, but you can generalize that for polynomially many slots. And the way this is implemented is as follow. There is a trusted setup that is going to generate a public key that is used to encrypt for each messages for each slot. And master secret key that is used by a key generation algorithm to generate keys for particular functions. So, each key is going to be different for every function. So, like the key generation algorithm takes the master secret key as input and the description of a function F and produces a secret key for F. And if a user gets a secret key for F, then it can extract from this ciphertext the function F of M1 and M2 and nothing more, as I said. And a different function, different key for a different function will leak this information. So, as I said, the important part for privacy is to leak only a partial information on the encrypted messages. So, here is this would be F of M1 and M2. So, the multi-input setting is useful when the data is distributed among different users. Or, for example, if one user encrypts some data, but at different point in time. So, this is a useful generalization of a single input FE. And the important property is for privacy that we want to leak only this partial information on M1 and M2. But, in fact, in the public key setting, a secret key for F leaks much more information than just F of M1 and M2. Because Bob, for example, could encrypt any messages he wants for slot one and any messages he wants also for slot two. So, for example, it could get from this ciphertext, it could extract much more than just F of M1 and M2, but also F of M2 and F of M1 and M prime. For any messages M, M prime of his choice. So, this is a lot of leakage. And this is by definition, this is inherent. And same thing holds for Carl or any other secret key. So, in fact, this means that the security for public key functional encryption in the multi-input setting is a bit weak. So, for this reason, because the leakage is inherently so huge, we will consider the private key setting. So, now there are no public key. And the master secret key is necessary to encrypt messages for each slot. So, this way, we don't have that much leakage. Bob cannot simply encrypt messages of his choice for any slots. But still, there is some issue with this definition. In particular, if there is many ciphertexts per slot, so here we have only two ciphertexts and two slots. And Bob, from his secret key for F, can decide to decrypt these messages with this one and get by definition, by correctness, he will get F of M1 and M2. But he can also decide to decrypt these messages with this ciphertext and this one and get different F of M1 and M2 prime and so on and so forth for every possible combination. And the same is true for any other secret key. So, in general, if you have N slots and Q ciphertext for slots, the number of values that is leaked per key is exponentially N. It's Q to the N. So, this is also a very huge leakage of information from the secret key for F and J. So, the security definition ensures that there is a resistance to a collision of user. So, if a set of user joins a secret key together, they should not learn anything more than what they individually know, that what each individual key reveals. Okay, so this is the definition. So, as I said, this could be problematic to have such a huge leakage in general, but in our case, we'll have this exponential number in N will be in fact linear in N. For the rest of the class of function we are considering, this is actually Q times N. So, this is how we avoid this issue. So, now let me present some known results about multi-input Fee. So, this is possible to build multi-input Fee for any general circuit. There are many constructions and they support polynomially many slots or even unbounded for some constructions, but they are all based on non-standard assumptions. For example, they are based on IU for general circuit or so IU for multi-input maps or IU from general circuit or even stronger notion of obfuscation. All of this object we don't know how to build from standard assumption. Other series of works have built multi-input Fee from single input Fee for general circuit and again we don't know how to build this from standard assumption. So, the question we asked is, can we build a multi-input Fee for based on standard assumption even if it's for only restricted cluster functions? If it's still an interesting cluster function. So, we built multi-input Fee for inner product which consists of this setting where each slots encrypts a vector of dimension M over some vector space and the secret key is associated with a vector Y of dimension N times M and the decryption of all this ciphertext with the secret key leaks the function inner product. So, the inner product of this huge vector X, the concatenation of all of the Xi with inner product Y. So, this is a functionality we built and it's based on two linear maps so standard assumption SXDH and it supports polynomially many slots. So, this is the first construction that is based on a standard assumption and with a polynomial security loss. Okay. And this is a generalization of Abdelay et al and Agrawad et al prior works which built inner product encryption for single slots. So, we managed to get from one slot to polynomially many slots with only one increase the degree of the multi-linear maps we need is only one. So, namely from DDH to pairing. Okay. So, this is in contrast with the work from Lili who built a same inner product functionality from a similar assumption standard assumption from pairing but only for two slots. So, we managed to get directly to many slots. So, it's remarkable that we can go from one to polynomially with only one degree more essentially. It's also interesting to notice that even if it's only one degree more this is still a qualitative gap. We need a stronger assumption to go from a single slot to many slots and this is not the case for example for large classes of function. So, in these works it has been shown that you can go from single input to multi-input with no extra assumption only with the you only have to pay a price in the security loss. This is more a quantitative gap. So, for us we need something stronger but not too much essentially. So, now let me present the construction. The paradigm is simple we simply built a multi-input FE from a single input FE. I'll show first a natural but a bit naive approach which works for any FE single input FE but I'll show that actually it doesn't doesn't work very well and I'll show how to modify this to get actually something that works but using a particular single input FE namely the one from Agrawal di Bersteli and we'll use some structural properties of this scheme to get many multi-input FE. But the first step is still instructive to see okay why this works. So, the first naive attempt would be simply to go from single input to multi-input we can do for n slots we can simply do n parallel copies of the single input. So, the setup is going to generate independently n times the master secret key for the single input FE and each secret key is used to do the encryption for each slots and the key generation for vector y that you can write as a concatenation of many vectors yi is going to be the concatenation of all the secret keys generated using the single input FE for all the yi okay. So, it's really just a simple n repetition. Thanks to this key Bob can extract from all of this ciphertext the value xi times yi for every i and thanks to this you can simply sum all of them and get the the function you supposed to get which is the sum of all i of xi yi. The problem with this is that Bob gets more information than simply the sum of all the xi yi it also gets all the partial inner product. So, this term here and in fact this is not something that should be leaked at least in the private key setting this should be hidden. Bob should only get this information. In fact in the public key settings this is supposed to leak this is inherent and this would actually work if you use a single input public key FE this would be a valid multi-input public key FE but as I said at the beginning the private key case is more interesting because there is less leakage and in particular the technical challenge is to hide all of this partial inner product while still allowing Bob to get the the full sum for all i of the xi yi okay. So, this is why the naive attempt doesn't work. Our idea was to modify the encryption scheme we are not going to use simply the single input FE encryption and not the single input FE key gen we are going to modify them in a way that Bob doesn't get the inner product xi yi but an encryption of the xi yi and there's some secret key for i okay. So, essentially since this is encrypted Bob gets no information at all about this partial product xi yi and but still we need correctness so it's we will use a linearly homomorphic encryption so that Bob can combine all of this encryption for the partial product xi yi to obtain it can sum sum them up to obtain an encryption of the the sum of all i of xi yi which is what it's supposed to get but under another key which is the sum of the keys sski okay. So, this exists for in our case we are we are actually going to use the L gamma encryption which satisfies this property and then if we include in the secret keys for why this sum of the secret key tilde i then Bob can actually decrypt and recover the function is supposed to get and because we only give the sum of all the skt of the i essentially Bob only can extract from all of this ciphertext he only can extract the sum essentially that's the idea now how do we implement this idea well so as I said we'll use a particular single FE which is the one from Agrawal-les-Berstele and we'll use it but so this will be the encryption the single input FE encryption of Agrawal-les-Berstele but not of xi but of the vector xi where we add one dimension and we add this value here sk tilde i okay we don't encrypt simply xi we augment the dimension by one okay and we also augment the dimension of all the vector the vector yi by one so the key gen is going to pick a random scalar r which is fresh fresh for any key generation and the secret key is going to be for this vector extended vector okay and the so the as I said will this encryption we should get is a L gamma encryption so we'll they will this will be simply L gamma secret keys okay so in the Agrawal-les-Berstele encryption scheme these are vectors of group elements in in some group of prime order p and what you get when you decrypt this vector with this secret key is exactly this term here so for all i bob can decrypt this thing so this will be the useful part xi times yi but it's this is actually an L gamma encryption of the partial product xi times yi this is the secret key of the gamma encryption and this is the randomness so the reason we put since we want to use the the security of L gamma we we need to argue that this secret key i is hidden so the room we essentially we can use the security of the single input fe because this secret key should be hidden it should it should only leak here okay so the safe attacks hide the the attribute here the vector here in particular it hides the secret key and we pick a random different r for every key to avoid a collision between key so mixed and match attacks so since these are independent for each key we we have collision resistance okay now the problem is that as i showed you at the beginning uh functional encryption ensures that the the vector uh and the underlying vector of the cipher text is hidden essentially but uh the secret key doesn't have to hide its underlying vector and in fact it reveals completely uh it actually in the case of agrawal libis libers telly it contains in the clear the underlying vector so all of the yi times uh concatenated with r are leaked in in dp so this is a problem if we want to use ddh here because you cannot reveal r in the clear so this is where we have to modify uh slightly the the scheme and uh what we do is we we are going to use a pairing and we are going to so the billionaire maps e that goes from source group g1 times g2 to a target group this will be this will be untouched but now the secret key essentially we are going to put it in the exponent so instead of having uh zp elements we are we have group elements in g2 and now this is fine because the secret key only reveals g2 to the r and uh to to decrypt essentially now we need a pairing uh to compute uh this uh times this part and uh what we get is uh the same as before but in the target group and now we can use essentially we use ddh here to hide the partial inner product so this is security and correctness you can still combine all of this stuff because this is an algorithmic encryption uh to get this and because uh the sum of all the secret key till the i are included in the secret key uh for vector y then bob can decrypt and get the inner product essentially so that is uh roughly the id um so so this uh this was an overview of the proof for our construction so as i said we built a inner product encryption from billionaire maps which support uh polynomially many slots but it still requires a stronger assumption than for the one slot so a natural question that we can ask is can we remove the pairing could we do this but without any pairing from ddh i would be surprised but it'd be a really nice interesting result and more generally uh what kind of um classes of function can we do from standard assumption and the minimal assumption okay so this concludes my talk thank you so we have plenty of time for questions uh do you think it is possible to uh extend to the unbound slot case um it's an interesting question so um we didn't really think about the unbounded case uh it seems it doesn't seem really straightforward directly from our scheme to extend it but it would be interesting okay thanks