 Hi, everyone. I'm Akshay Raan and I'm going to talk about traceable secret sharing and applications. This is based on joint work with Vipul Goyal and EFAN song. Let's consider the following scenario. Alice has some secret data and she wishes to store this data on the cloud. To enhance privacy, Alice chooses n cloud service providers, secret shares the data using a t out of n secret sharing scheme and stores the shares on the servers. However, there is an adversary who is interested in learning about Alice's secret data and in fact, the adversary is willing to pay the servers in order to learn this information. So the adversary approaches one of the servers and promises to pay a certain amount if the server sends the share it received from Alice to this adversary. Even though this offer is pretty enticing, the server is wary of the following possibility. If Alice somehow finds out that the server cheated by sending the share it received to an external party, then Alice could show the server in the court of law. Specifically, the share that Alice sent to each of these servers could have some identifying information embedded inside and this information could help Alice win the case against the server. And if Alice wins the case, then it could not only result in a big loss of reputation for the server, but it would also result in bankruptcy due to the service agreement it had with Alice. So learning about the server's hesitancy, the adversary comes up with a pretty clever cryptographic scheme. So this scheme has the following components. It has n functions f1 up to fn, which are called as the collector functions, as well as a reconstruction box rex star. And all that the servers now have to do is to apply these collector functions on the shares and give it to the adversary. And the adversary now pays the servers with monetary reward that it promised. So these functions could be cleverly designed so that they could remove all the identifying information inside the shares, leaving only the essence of the share intact. And the adversary in fact promises the following. So even if Alice gets hold of these collector functions f1 up to fn, as well as these shares that the server sent, fi of share, or call this collected shares, as well as the reconstruction box, then Alice will not be able to prove in the court of law that one of the servers indeed cheated. In other words, there is no way that Alice could trace a cheating server. On examining this scheme closely, the server is indeed convinced that there is no way for Alice to implicate it for cheating behavior. And in fact, any rational server would send fi of share i and collect the monetary reward. And if the adversary is able to convince at least t of these servers to send the shares, then it can learn information about the secrets. So to prevent such a scenario, Alice seeks the help of the cryptographic community. So the specific question we are interested in is the following. So can we construct a secret sharing scheme that allows Alice to trace a cheating server? So we are interested in not only tracing, but also extracting an evidence against this cheating server, which could be examined in a court of law. And in order to help Alice with this task, we introduce a new primitive called a traceable secret sharing scheme or TSS in short. So let me first describe the syntax of a traceable secret sharing. So just like any other secret sharing scheme, a traceable secret sharing consists of a sharing phase where you take a secret from the dealer or Alice in this case and split it into n shares, SH1 to SHn, which are sent to the servers. There is also a reconstruction phase, which takes an at least t shares that was given to the servers and reconstructs the secret. For privacy, we require that any of these t-1 shares reveal no information about the underlying secret. So in addition to the sharing and the reconstruction phase of a secret sharing scheme, there are two additional components of a traceable secret sharing. Namely, there is a special algorithm called as the trace algorithm and there is another algorithm called as the judge algorithm. So this trace algorithm takes in these collector functions f1 up to fn, the set of collected shares, fi on share i for some subset c, which is at least t, the reconstruction box x star and outputs an identity of a cheating server and an evidence pi i. And this evidence is examined by the judge algorithm, which pronounces whether the i-th server is guilty or not guilty. So we need a traceable secret sharing scheme to satisfy the following two properties. The first property is the traceability requirement, which states the following. For any two secrets s0 and s1, if the reconstruction box x star on input the collected shares can distinguish between the sharing of s0 and s1 with some non-negligible advantage, then trace is required to output the identity of a traitor along with the valid evidence that is accepted by the judge algorithm with non-negligible probability. So here we require a very big property on the reconstruction box. All that it requires is to distinguish between shares of two secrets with some non-negligible advantage. And even in this case, the trace should be able to output the identity of a traitor along with some valid evidence. The second property is the non-intuitability property, which roughly protects an honest server from a malicious dealer or else. So this requires that any malicious dealer cannot provide a valid evidence against a honest server. And this should hold even if the dealer colludes with every other server. Okay, so these are the two properties that we require a traceable secret sharing to satisfy. So in this work, we formally define a traceable secret sharing scheme. So unlike the related notion of traitor tracing in a broadcast encryption scheme, traceable secret sharing is not revealed to construct even if we ignore the efficiency aspects. We call that the traitor tracing scheme can be trivially constructed from any public key encryption if we allow the public keys and the ciphertext to grow with the number of users. However, this is not the case for traceable secret sharing scheme. And our main contribution is a construction of a traceable secret sharing, assuming the existence of a secure multi-party computation protocol. And we also consider a couple of extensions to this notion. So the first extension we consider is tracing more than one trader. And recall that it's not possible to trace more than T-traders because a reconstruction box could just ignore the other shares and concentrate on some subset of T-shares. So here we can do almost optimally and can trace up to T-minus one traders. We also consider a scenario where servers could collude with each other before sending the collector shares to the to the adversary. And here if we allow more than T server collusions, then there is no hope of tracing because the the servers could reconstruct the secret and send it to the adversary. So here we do the best possible thing where we allow up to T-minus one server collusions. We also consider an application of traceable secret sharing to traceable delegation of computation. So here we give a protocol that works in the offline online setting. So the offline setting grows with the circuit size of the function that we want to delegate. And the online setting, online cost is pretty efficient wherein the cost grows only with the the input and the output limit. In the rest of the talk I'll mainly focus on a construction of traceable secret sharing. In the minimal setting where there are no server collusions and we are required to trace only a single trader. So before we move on to our construction, let me explain the key challenges involved in constructing a traceable secret sharing scheme. So let's start with the basic question on whether Shami secret sharing is already a traceable secret sharing. Unfortunately, Shami secret sharing does not satisfy the non-imputability property. So this is because the dealer knows all the shares that are sent to each of the servers and hence it's easy for the dealer to accuse an honest server of cheating. So to mitigate this, we consider the following natural attempt wherein we run a multi-party computation protocol between the servers and the dealer. So this functionality which is computed by via the MPC protocol takes in the secret S from the dealer, generates the share and sends the shares to the servers. So this can be shown to satisfy non-imputability via the security of the MPC protocol. But unfortunately, there is no way that we could trace a cheating server because the dealer does not have any information available with it. So the key idea behind that construction is the following. In order to achieve traceability, we must ensure that the dealer has some secret information which is unknown to all the servers. And in order to achieve non-imputability, we must ensure that each server has some secret information that is unknown to the dealer. So the key challenge that we face here is that how to balance this information available to the dealer and available to the servers so that we can satisfy both traceability and non-imputability. So this brings us to our construction. So our construction also follows the template that we discussed before wherein we run an MPC protocol between the dealer and the servers to generate the secret shares. However, the key idea behind the construction is carefully designing the function that is computed by the MPC protocol so that we can achieve both traceability and non-imputability. So let's consider the function that is being computed by the MPC protocol. So as a first step, the MPC functionality takes in the secret S from the dealer and generates the Shamil sharing SS1 up to SSN. So this is just a T out of N, Shamil secret sharing of the secret. Let's assume that each of these shares are lambda bits long. The next step done by this function is the following. For each J in the set 1 to lambda, it chooses a uniform random string RJ which is lambda bits long. Now the next step is the following. For each party I, you choose a uniform string LIJ from the set of lambda bit strings such that the inner product of LIJ with this RJ is the jth bit of the Shamil share of this party. So specifically for the first party, we choose a random string LIJ L1J such that the inner product of L1J with RJ is the jth bit of the first Shamil share. Similarly for the second party, we choose another random string L2J such that the inner product of L2J with RJ is the jth bit of the second Shamil share and so on. So once we choose all these LIJs, the next step that is done by the functionality is to take this RJ for each J and secret share it using Shamil secret sharing to generate N shares. And the share of a party I is the set of all LIJs and RJs for each J in 1 to lambda. So the share of the first party is the set of all L1Js and R1Js. And similarly the share of the end party is the set of all LNJs and RNJs. Okay, so now what is the secret that is available to the dealer which is output by the NPC functionality? The dealer secrets consist of the following. So it consists of the set of all LIJs but not in the clear but as an image of a one-way function applied on these LIJs. It also consists of the Shamil shares SS1 up to SSN and it also consists of the set RIJ for each I in 1 to N and for each J in 1 to lambda. So these are the dealer secrets. And what is the judge algorithm? The judge algorithm takes in some proof by eye and an identity of her cheating server and it checks the following. It checks whether there exists some J in the set 1 to lambda such that the one-way function applied on Pi I is equal to the one-way function on LIJ which is available as part of the dealer secret. So essentially the dealer has to invert this one-way function in order to prove that a server has cheated. And what is the secret that is available with the servers? It is these LIJs which are the secrets available with the server. Okay, so given this construction, let's see why it satisfies the non-imputability and the traceability properties and let's start with the non-imputability property. So recall that in order to prove that a server had cheated, the dealer has to produce a pre-image of this one-way function. And from the security of the multi-party computation, we can ensure that the only information that the dealer gets about the server secrets are these one-way function applied on the server secrets which are these LIJs. So in order to implicate an honest server, the dealer has to invert this one-way function and the non-imputability just follows from the one-wayness of OWF. So the more interesting property is the traceability. And recall that for tracing, we have access to a reconstruction box, RICS-STAR, and the guarantee that is satisfied by the RICS-STAR is that given the collected shares of some secret S0 and the collected shares of some secret S1, this reconstruction box can distinguish between these two secrets with some non-negligible advantage. Now we need to use this reconstruction box and extract some evidence against the cheating server. So in order to do this, we actually define a sequence of n minus 1 hybrids between the collected shares of S0 and the collected shares of S1. So specifically, the i-th hybrid in the sequence is defined as follows. We fix the i-th share and f i on share i, which is the collected share. And we sample the other shares in a way that SH1 to SHi are the first i-shares of a secret sharing of the secret S1. And we sample SHi plus 1 to SHn in such a way that these form the last n minus 1 shares of a secret sharing of S0. So once we sample all these shares, we apply the collector functions on these shares and run the reconstruction box on these collected shares. So note that high 0 according to this definition is identically distributed to a collected shares of the secret S0. Similarly, high n in the sequence is distributed identically to the collected shares of the secret S1. So via a standard hybrid argument, there exist two intermediate hybrids in the sequence such that the reconstruction box can distinguish between these two hybrids with some non-negligible advantage. So once we find such a hybrid pair, then we can immediately conclude that server high is the prater. Why? Because if server high added submitted at share, then these two hybrids are identically distributed. However, since the reconstruction box can distinguish between these two hybrids with some non-negligible advantage, it now follows that server high is the prater. So for those who are familiar with the prater tracing literature, this is actually pretty similar to the concept of private linear broadcast encryption that is used as a building box towards constructing prater tracing schemes. However, for a traceable secret sharing, it's not only sufficient to identify a cheating server, we must also extract an evidence that is accepted by the judge of God. So for this purpose, we do the following. So we consider these two hybrids high by minus 1 and high by, which can be distinguished by the reconstruction box with some non-negligible advantage. And we consider a sequence of lambda minus 1 intermediate hybrids between these two distributions. Specifically, in each of these intermediate hybrids, we change the IH share from a share of the secret S0 to a share of secret S1. So we do this one bit at a time. Again, via a standard hybrid argument, we conclude that there exist two hybrids, intermediate hybrids in the sequence high i minus 1, j minus 1 and high i minus 1, j that can be distinguished by this reconstruction box with some non-negligible advantage. So once we find these two hybrids, we do the following. So we take this reconstruction box that can distinguish between these two hybrids with non-negligible advantage and use this box to actually predict the inner product of LIJ and some RJ with probability that is greater than half plus some non-negligible property. So once we construct such a predictor of inner product of LIJ with a uniformly chosen RJ, we can use the Goldrich-Levin decoder to extract the evidence LIJ. Now this evidence LIJ can be given to the judge algorithm and this will be accepted. So this is the main idea behind extracting the evidence using the reconstruction box. Of course, I have swept a lot of details under the rug and I encourage you to look into the paper for all the details. So to conclude, we defined a notion called as traceable secret sharing and provided a construction using any secure multi-party computation protocol. We also considered extensions to tracing multiple traders and also considered collusion between the servers and I would encourage you to look into the paper for these extensions. So we also provided an application to constructing a traceable delegation of computation in the offline online setting. Again, you can refer the paper for the details and there are many interesting open questions from our work. So the main open question is extension to stronger adversarial models. So here we considered a setting where the adversary provides some collective functions and the servers have to apply these functions on the shares and send it to the adversary. But it's possible to consider stronger adversarial settings where the servers and the adversary could get involved in a multi-party protocol and which provides information to the adversary. So our construction does not extend to these settings and it's interesting to see if there are construction that can be shown to be traceable even against such stronger adversarial models. There's also this very interesting question of extending a traceable delegation to constructing traceable multi-party computation protocols. And finally, are there other applications of traceable secret sharing schemes and how does it connect to other primitives in cryptography? And that's it. Thank you for your attention and you can find the full version of our paper on here.