 Hi everyone, I'm Henrik Waldner and this talk is about multi-client function encryption for separable functions which is joined work with Michele Ciampi and Luisa Siniskalci. Let's start with some motivation. Let's consider the example where we have two encrypted documents and now we want to allow two different parties Dave and Aaron to do some analysis over these documents. Dave wants to know how many times the word peak is here occurs in both of these files together and Aaron wants to learn how many times the word crypto appears in both of these files together. Additionally, we want to allow two other parties, Alice and Bob, to be responsible for providing the different documents. So Alice would be in charge of providing the first file and Bob responsible for providing the second file. We additionally require that the evaluation of Aaron and Dave happens in a privacy-preserving way. That means that they should only learn how many times their requested word appears in both of these documents together and nothing beyond that. In the next steps we are going to see what cryptographic primitives we can use to achieve this goal. One primitive that might be useful in this scenario is public key encryption. In public key encryption a setup algorithm outputs a public key and a secret key. The public key can then be used by Alice to encrypt a message X and Bob can use the secret key to decrypt the cipher text and obtain the message X. The problem of this notion with respect to our use case is that it is not possible to allow for any fine-grained access control over X. Bob either learns X completely or nothing. A notion that allows for this fine-grained access control is the notion of functional encryption which was introduced by Bonesa High and Waters in 2011. In a functional encryption scheme the setup algorithm outputs a master public key and a master secret key. The master public key can then be used in the same way as before by Alice to encrypt a message. The master secret key though is not directly used to decrypt cipher text but to generate so-called functional keys. Every functional key is associated with a function F and if Bob uses such a functional key to decrypt a cipher text he learns the function evaluation of the function associated with the key applied on the underlying message. Security in such a scheme ensures that Bob learns nothing beyond the specific function evaluation. This notion can also be considered in the secret key setting where the setup algorithm only outputs a master secret key that is then used for the encryption and functional key generation. Functional encryption provides us with the fine-grained access control that we need for our use case. It remains a problem that only single input functions can be evaluated. A more generalized notion that allows for the evaluation of multi-input functions is the notion of multi-input function encryption introduced by Goldwasser et al. in 2014. Here a functional key can be generated for example for a two-input function and Bob can use this key together with two different cipher texts containing the messages X1 and X2 to obtain F of X1, X2. These two cipher texts are generated using different encryption keys output by the setup procedure to Alice and Carol. A problem with this notion is that if Alice and Carol create more cipher texts of for example the message X1 prime and X2 prime, Bob can not only compute F of X1 prime X2 prime but also F of X1 prime X2 and F of X1 X2 prime. A notion that prevents this leakage is the notion of multi-client function encryption. In multi-client function encryption Alice and Carol use encryption labels for every cipher text that they generate. This allows Bob to only obtain a valid encryption for two cipher texts that have been generated under the same label. Otherwise he learns nothing. We can see that this notion prevents the previously mentioned computation since Bob is not able to compute F of X1 prime X2 or F of X1 X2 prime if the corresponding cipher texts have been generated using different encryption labels. In this talk we mainly focus on the specific function class of separable functions. Separable functions are functions that can be written as the sum of any individual single input functions applied on all the different inputs. So in this case Bob receives a function a key corresponding to the separable function such that he can learn F1 of X1 plus F2 of X2. This function class is a good match for our word count example and allows a function evaluator to learn the desired information. In this work we show how to realize multi-client function encryption for separable functions from secret key single input function encryption. In the setting of multi-client function encryption a drawback still remains. The requirement of a trusted party that is responsible for the setup of the parameters and the generation of the functional keys. A notion that operates without a trusted party is the notion of decentralized multi-client function encryption introduced by Chauta et al. In a decentralized multi-client function encryption scheme Alice and Carol are interacting with each other to generate their own encryption and secret keys. They can then use their secret keys to generate functional key shares that can then be combined to obtain the full functional key. This functional key can then be used by Bob in the usual manner. In this setting the computations of the trusted party are completely transferred to Alice and Carol and therefore the trusted party is not needed anymore. In this talk we are also going to show how the multi-client function encryption scheme that we present can be decentralized. Now we recap previous works focusing on transformations of single input function encryption schemes to multi-input and multi-client schemes. The first work in this area is the work of Parkersky et al. from 2016 in which the authors show how to turn a secret key single input function encryption scheme for general function class into a multi-input function encryption scheme with a constant number of inputs. This result was extended one year later by Komogotsky and Zeghev allowing for a polyrhythmic number of inputs. In another line of work by Abdallah et al. the authors show how to lift a secret key single input function encryption scheme for the inner product functionality into a multi-input scheme. Additionally it has been shown in another work by Abdallah et al. how this scheme can be decentralized. In a follow-up work by Abdallah, Ben Hamouda and Gay the authors extend the previous construction and allow for handling labels. Instead of a secret key single input function encryption scheme the authors here need to rely on a public key scheme. Their scheme can also be decentralized. As previously mentioned in this work we show how to transform a secret key single input function encryption scheme for general function class into a multi-client function encryption scheme for separable functions. We also show how our construction can be decentralized. Additionally we introduce a new notion of multi-client function encryption that allows for a distributed execution of the decryption procedure. Now we present our construction for the specific case of four parties. The trivial solution that someone can think of to obtain multi-client function encryption for separable functions is by simply running four different instances of a single input scheme and whenever a key for the separable function is requested a key for the individual function under each of the single input instances is generated. The final functional key then consists of all the keys of the single input schemes. The decryption procedure for the multi-client scheme then executes the decryption procedure for all the single input schemes using the different keys and sums up all the resulting values. The problem with this solution is that we have an instance-wise leakage of the function evaluation. That means that the decryptor not only learns the evaluation of the separable function but also the evaluation of each of the individual single input functions. So for the case of the word count example the decryptor will not only learn how many times the requested word appears in all of the documents but also how many times it appears in every single document. Therefore we need to adapt the construction to prevent the individual leakage by hiding the evaluations of the different single input functions. To achieve this we can rely on a secret sharing scheme of zero. In more detail instead of letting each functional key simply output the evaluation of the single input function the key generator generates a secret sharing of zero and hardcodes one of the shares RIF into each of the individual keys. When the individual keys are then evaluated they output the evaluation of the single input function plus the share RIF. Summing up all of the outputs of the individual keys then gives the desired separable function evaluation and as long as the decryptor does not have any knowledge about the different shares nothing about the single input function evaluation is leaked. A related problem occurs for the generation of the ciphertext. In the current construction the encryption labels are not affecting the decryption in any way which means that it is still possible to decrypt ciphertext generated under different encryption labels. One might think that we can also solve this problem using a secret sharing of zero but the issue is that the different clients need to agree on the secret sharing whenever they want to encrypt the ciphertext under a new encryption label and there is no single party that can sample the secret sharing. Therefore we need a non-interactive solution such that the parties can agree on a new secret sharing of zero for every label on the fly. To do this we borrow a technique from Abdallah ben Hamouda and Kay. This technique works in the following way. We start by considering a more complicated way to generate a secret sharing of zero where the clients have different shared values with each other. In more detail the client C1 shares RL12 with client C2, RL13 with client C3 and so on. We can then display the shared values between the clients in this anti-symmetric matrix. To generate the secret shares of zero one simply needs to sum up the shared values in the columns of the matrix. So client C1 for example computes minus RL12 minus RL13 minus RL14 to obtain its shared T1L. We can see that this is indeed a valid secret sharing of zero since every value occurs only one time positive and one time negative inside this matrix. We can also see that summing up only a subset of the columns of the matrix does not yield zero. To allow for the non-interactive generation of several secret sharings we need to allow the parties to agree on such a matrix for every label L on the fly. Abdallah et al. achieved this by letting the parties share pairwise PRF keys with each other which can then be used to generate the different R values by executing the PRF with the corresponding shared key applied on the label L. This solution results in a quadratic blow-up of the keys which means that for any clients we require n times n minus 1 divided by two keys overall. Using this technique we can now generate the ciphertext containing the message xi and the value TIL generated using the PRF evaluations of L under the different keys. To make the scheme work we additionally need to modify the functional key for each of the single input instances to not just output the single input function evaluation and the hard-coded secret share RIF but also the value TIL. Furthermore we also need to add the shared PRF keys to the secret keys of all the different parties to enable them to generate the T values for their encryptions. This completes our construction of the multi-client scheme for separable functions. The security of our construction can be shown by relying on the security of the different primitives. We give a high-level overview how the security of the scheme can be proven. We start by relying on the security of the PRF to argue that the non-interactive secret shares TIL are computationally indistinguishable from randomly generated shares. In the next step we program the ciphertext and functional keys in such a way that they only contain the sum of the individual function evaluation, the random share RIF of the function and the non-interactive share of the label TIL. These program values can then be seen as a one-time pet encryption of the individual function evaluation using the sum of the random share RIF and the non-interactive share TIL as the key. Since the values RIF are different for every function F and the values TIL are different from every label, we obtain a fresh one-time pet key for every function and label combination which is sufficient to argue the indistinguishability of different ciphertexts. To decentralize our scheme we need to define functional key shares that can be combined to obtain the complete functional key and we need to separate the master secret key into different secret keys that can be used to generate these different functional key shares. The separation of the master secret key in our scheme is very natural and the clients can execute a key exchange protocol to agree on the different PRF keys. To separate the functional key into different functional key shares we need to remove the local sampling of the secret sharing of zero for every functional key. To achieve this we can rely again on the PRF technique of Abdullah et al and let the clients generate the secret sharing for the functional key shares by evaluating the PRF using different keys on the requested function. This concludes the decentralization of our construction. In our work we also introduced the notion of outsourceable multi-client function encryption. An outsourceable multi-client function encryption scheme allows to distribute the decryption procedure to end different servers that all output different decryption shares. These decryption shares can then be combined by the function evaluator to obtain the final functional output. Security in this setting ensures that no one learns anything about the final function evaluation who is not in possession of all the decryption shares. This notion is particularly useful in use cases where the decryption procedure is quite computation expensive. More formally in an outsourceable multi-client function encryption scheme the key generation procedure outputs different functional key shares for the function F. These shares can then be used by the parties Bob and Charlie to execute the partial decryption procedure and to obtain different decryption shares. It is noted here that Bob who is in possession of the first part of the functional key only needs to execute the partial decryption on the first ciphertext. The same holds for Charlie with respect to the second ciphertext. The resulting decryption shares can then be combined together to obtain the final output. Security here ensures that if not all the shares are known nothing about the function evaluation is leaked. Our presented multi-client function encryption scheme also allows for outsourceability by separating the functional key into different functional key shares that allow for the generation of decryption shares. In more detail we output the different keys for the different single input function encryption instances to the different servers and define the partial decryption procedure as a decryption procedure of the single input scheme. The output decryption share is then blinded using the secret share of the functional key and the secret share of the ciphertext label. For the reconstruction of the final function output the different decryption shares can then be summed up by the function evaluator. It is also possible to combine the notion of decentralization and outsourceability to get a decentralized outsourceable scheme. We can decentralize our outsourceable scheme in the same way as we decentralized our multi-client scheme using the PRF generated non-interactive secret shares. In summary, we first showed how to obtain a multi-client function encryption scheme for separable functions from a secret key single input function encryption scheme using a non-interactive secret sharing scheme. Additionally, we showed how our construction can be decentralized by removing the trusted party for the setup and key generation. And we also introduced the notion of outsourceable multi-client function encryption that allows for a distributed execution of the decryption procedure and showed how our construction can be modified to achieve outsourceability.