 So thanks for the introduction. Hello, I'm Rasheb. And today I'm going to talk about basically Luke and I are going to give a joint talk on our aforementioned works. All right, let's start by talking about Trader Tracing. So what is Trader Tracing? Consider the following scenario. Suppose we have N users in the system. Each user have their own private secret key. And we have one common public key. You can use the public key to encrypt any information of our choice. The property is that any of these N user keys could be used to decrypt the un-corresponding self-textual on the message. Now suppose an adversary in a system is able to corrupt some of these users, some of these users in the system. And using the corrupted information, these corrupted secret keys, the adversary could potentially create some special decoding device or a decoder box such that this decoder box can also receive a self-text encrypted on the public key and output the corresponding messages. Now a Trader Tracing system allows the following capability. It says that if we can just get a hold of some of these decoding devices, then we can basically trace. We can figure out which parties have been coerced by the adversary. That's the problem of Trader Tracing. Now why is this problem interesting or why is this problem even, I mean, why is this problem hard? The hardness of the problem stems from the fact that the adversary in the system, it could potentially collude. Basically, it could corrupt multiple users and it could use different of these secret keys to create just one decoding device. Additionally, the adversary could be using obfuscation, hardware, or any other technique. And we can't rely that we can basically look inside this decoding device and figure out which keys have been used. Next, let me try to formalize the problem of Trader Tracing. So in Trader Tracing systems, we have four algorithms. The first three algorithms are pretty straightforward. They're just corresponding to the regular public key encryption algorithms. Except, given the setup algorithm, we output these all end user keys at once. The special algorithm in Trader Tracing system is the tracing algorithm. It takes us to input this master secret key, some parameter y, and two messages mj and m1. And additionally, this algorithm gets oracle access to some decoding device t. And it basically outputs a set t. This set t will correspond to the traitors that the tracing algorithm points to. Now, the interesting properties are so basically if you don't have any secret keys, we require NCP security from a Trader Tracing system that you cannot learn the underlying message. And for correctness, we require that any of these N users could decrypt the sci-fi text using their private secret keys. The more interesting security property that we require from a Trader Tracing system is called a secure tracing property. It's formalized by a game between an adversary and a challenger. And the game starts when the adversary sends the number of users to the challenger, it sets up the system, sends the public key over to the adversary, the adversary says, then okay, I want to cut up the following set s of users, give me the corresponding secret keys, I'm then going to output a decoded device t and two messages mj and m1. Finally, the challenger, it runs the tracing algorithm honestly on all these inputs and let t be the output of the tracing algorithm. We say a Trader Tracing system is a secure tracing system if it satisfies the following two properties. The first property sort of like a sound miscondition. It says that irrespective of what users the adversary corrupts, the tracing algorithm should never point to any user who was not corrupted by the adversary. Basically should not falsely accuse anyone of cheating. The other condition is sort of like a completeness condition. It says that if the decoding device that the adversary outputs, it can really distinguish between encryptions of mj and m1 with some non-negotiable probability, then the output of the tracing algorithm should be non-empty. You should find at least someone in the set. Now, before this work appeared, there were three main pathways to build Trader Tracing system which were from public-key encryption, from bi-linear maps and from function encryption and indistinguishability obfuscation. The difference between all these approaches were the efficiency that they led to. So if you just use public-regular public-key encryption, it had a pretty bad efficiency. The size of the septex is to grow linearly with the number of users n. With bi-linear maps, we could improve it slightly, but with function encryption and indistinguishability obfuscation, unsurprisingly, you can get optimal sci-fi tech size. Now, the question that we pose in this work is that, okay, maybe just getting Trader Tracing a full Trader Tracing system is hard, but what if we try to relax the tracing requirements slightly then can we build efficient systems from standard assumptions? To that end, we relax the tracing requirements as follows. So in standard Trader Tracing, we say that, okay, you should not falsely accuse anyone and you should catch someone if you get a decoding device. What we do is that, we define something that we call Riscated Tracing or F-Riscated Tracing. So this function or this parameter F, it's basically multiplied on the right side of this second constraint. What we are trying to say is that, now suppose this function F is one half for simplicity, we are trying to say, if the decoding device is a good decoding device, that the adversary outputs, then the tracing algorithm needs to just find someone with at least one half probability. F could be any function of lambda n and we just relax this completeness requirement slightly. Now, formally in this work, we show that on the simple assumptions of our binary groups, we can build some F-Riscated Tracing schemes with following parameters. So just choose any parameter k of your choice. The F-Risky parameter that we can target is k over n, where n is the number of users and that leads to the scheme, which has secret, in which the psychotech size grows linearly with the parameter k. For example, if the parameter k is just two, that means the probability of finding someone is two over n at least and then the psychotech size is basically constant, it just depends upon the security parameter. Additionally, we also show that, okay, that Riscated Tracing can also lead to some differential privacy negative results, just like standard Traded Tracing. Now, I'm only going to focus on Riscated Tracing in the next part of the talk and I'll hand it over to Luke to tell you more about differential privacy. Now, before moving on to how to actually really build Traded Tracing, how to build Riscated Tracing, let's see what are some standalone applications of Riscated Tracing. Now, recall in a Traded Tracing system, when we deploy it, there could be any users and each have their own secret keys. Suppose that the key manager or the person who gives you a secret keys, it tries to refresh the secret keys after some time. It refreshes, there is a key differential cycle, you get a new secret key each time. So in such settings, what we can do is that, we can only use Riscated Tracing to actually just give very strong guarantees of tracing. We can amplify the probability of catching someone because if we ask the decoding device, should work across different key cycles, different key difference cycles, then we can just switch around this probability, we can just divide this out. Now, other possible applications could be if you want to deploy a Traded Tracing system in a resource constrained setting or if you want to guarantee security against very risk-averse attackers who really don't want to get caught because if you get caught, then there are pretty bad scenarios that could happen. All right, so now in the rest of the talk, what I'll do is that, I'll quickly tell you more about how to build Riscated Tracing schemes. To that end, we propose a new framework that we call Mixed Bitmatching Encryption Systems. A Mixed Bitmatching Encryption Systems consists of five algorithms, which I'm going to describe next. So the setup algorithm, it takes us and put a security parameter and some length parameter L. It outputs a public key and a master secret key. Then we have a public key encryption algorithm. It takes us and put a public key, and some message gives you the ciphertext. Additionally, we have a secret key encryption algorithm. It takes us and put a master secret key, a message, and an attribute string Y, which is basically a length L bit string. And it gets you a ciphertext. We also have a key generation algorithm. It gets us and put a master secret key, again some attribute vector X, and gives you some secret key. And again, we have a decryption algorithm, just takes us and put a secret key and a ciphertext and gives you a message. So what are the correct net requirements from such a system? The first requirement is for a public key encryption and a ciphertext, which says that if you try to decrypt any public key ciphertext using the secret keys generated by the key generation algorithm, then the output should always be the message that was encrypted. That's good. But now for our secret key encryption, we require that if you try to decrypt the secret key ciphertext using secret key, then the output should be the message M if the predicate G is satisfied on these attribute strings X and Y. And the attribute, and the policy that we want on these attribute strings is that, at least that in each bit position of both these bit strings, at least one of them should be one. One of them should allow decryption in a sense. It's just basically an end of all these, on these two attribute strings. All right. So let's see that, or actually, I should also tell you something about what are the security properties that we require from mixed bit matching encryption? The three security properties, and basically these are three different flavors of security properties. The first property is trying to say that you should not be able to distinguish between two modes of encryption. So we have a secret key mode of encryption, we have a public key mode of encryption. If you don't have some distinguishing keys, then you should not be able to tell, okay, whether you get a public key ciphertext or a secret key ciphertext. The second property is sort of a ciphertext hiring property. It says that you should not be able to distinguish between two secret key ciphertext if you don't get any distinguishing keys. Basically, there will exist some distinguishing keys which can decrypt one ciphertext and not the other one. In that case, you should not get those secret keys. The last security property is called the key hiring property. It says that you should not be able to distinguish again between two secret keys for two different attribute vectors, X and zero and X1. Again, if you're not giving some distinguishing ciphertext. I'm not going to formalize exactly what these distinguishing ciphertext and distinguishing keys means, but these can be just some natural motions that you can imagine, all right. So next let's see how we can use a mixed bit matching encryption system to build to realize a risky TT system. What we do is that we have to do a set up algorithm and we have to produce these n secret keys for all these users. Now, let K be the parameter, the risky parameter that was defined in the theorem before. And what we are trying to say is that, we're trying to say if we choose this parameter K, then we can catch at least K of the users. If the adversity uses some of these K users, then we can catch them. If that doesn't make sense, I'll try to elaborate more on it. So what we do is that we run the MBME setup with the length parameter to be K plus one. K is that risky parameter. We get the public and master secret key. Now we have to sample these n secret keys for the Trader Tracing System. So what we do is that, we choose a random window of size K out of all these n users. What we're trying to say here is that, if the adversity corrupts one of these users in this window, then basically we can catch one of these users if they are being used to create a decoding device. If you use something outside it, maybe we can't catch it. This is our target window. What we do is that we select the target window and then we set the attribute vectors as follows. We say if your index lies before the start, the window start location, the target window start location, then your attribute vector will be all zero string. If you're inside the window, then the attribute vector will have one more one than the previous index that you have. So the first attribute vector in the window has one in the last, the next one has two ones, and the last one has ones in all the position, but except the first one. And if you're outside the window on the other side, then it's going to be the all-ones attribute vector. We set the attribute vectors this way. We run the MBME key generation algorithm. We get the corresponding secret keys, and that's how we sample the n-user secret keys in the system. Basically the functionality of just distinguishing is captured in this window that we select. Now how to do encryption and decryption? Now that's pretty straightforward. You just run the MBME, public encryption and the corresponding decryption algorithm just to give you the encryption and decryption. And you can just clearly check if the underlying MBME system gives you correctness in the public key setting, and this gives you correctness in the trader tracing setting. All right? But let's move on to the more interesting case, which is how to build trader tracing, how to build the tracing algorithm with this framework. So the idea is that we have this master secret key and two messages, and we want to trace it. What we'll do is that we will choose a random message M out of these two messages, MJ and M1, let the random message be MB, and we'll compute the following SYF text. We will compute the secret key version of the SYF text for different attribute vectors, where the first attribute vector is all once, the second attribute vector is all once, except the last bit is zero, and so on. Now what we are trying to do is that the first SYF text can be decrypted by all the parties. The second SYF text can be decrypted by all the parties that whose index is larger than the window start location. The second one will be whose index is larger than the window start location plus one, and so on. Basically, all these SYF text, they kill the functionality of one user in the window one by one from the left side. So what we do is that we create such SYF text, we run the decoding device on it, on these SYF text, and then we basically check whether the decoder works correctly on these type of SYF text or not. Finally, we do this check multiple times, basically to come up with some estimate of successful decryption probability. Suppose we get the exact successful decryption probability, then what we are trying to gain here is that whether the decoding device can distinguish if we kill out the functionality of one of the users in that particular window. If the decoding device can distinguish between the functionality for these two SYF texts, then that means, okay, you have that particular secret key. If you don't have the secret key, you should not be able to distinguish between these two steps. So what we just see is that if there are any two adjacent probabilities, PIN, PI plus one, which are sufficiently or noticeably far, then we add the corresponding index to the set of traders. And since I do not have much time, I won't go into security proof, but I'll just briefly say that the proof techniques that we use to prove security of a risky trader-tracing scheme they significantly depart from the techniques used in the trader-tracing literature because we have to include this parameter of K by N in the inequalities and that causes some problems. So it's a pretty nice proof and maybe you want to look at it in the paper. Also, I didn't have enough time to tell you more about how to build mixed mid-matching encryption from binding in maps. I'd like you to look at the paper for that as well. And we also give some genetic risk amplification so how to combine two different risky trader-tracing schemes to amplify the success probability. All right, with that I'll hand it over to Luke and he'll tell you more about differential privacy negative results. Thank you. Close the song, okay. Hope everyone has their iClicker set to AA. That's gonna be important. All right, so I'm gonna switch gears here a little bit and talk about hardest results for answering statistical queries with differential privacy. And so what's the connection to the previous talk? Why are we soft-merged here? In 2009, Dwork et al showed that any trader-tracing scheme immediately implies a differential privacy hardness result where the quality of the result depends on the size of the secret keys and cybertext for the trader-tracing scheme. So kind of the state of the art for trader-tracing schemes with small cybertext and secret keys up until now is Boney and Jandri's trader-tracing scheme which is built using one-way functions and indistinguishability obfuscation. So this gives a good lower bound for differential privacy but we'd like to get our lower bounds to depend on kind of the most conservative assumptions possible. And so the previous work of Rishabh et al showed that it's sufficient to consider a weaker version of trader-tracing, their risky trader-tracing scheme that'll get the same lower bound for differential privacy. And since they're considering a weaker notion of trader-tracing, they're able to build this using just bilinear groups. In our work, we consider a trader-tracing scheme and build one that's even worse than all these other trader-tracing schemes. It's still sufficient to prove the differential privacy lower bound though. And since we consider such a weak version of trader-tracing, we're able to build it just using one-way functions. So we've reduced the assumptions faced to just that. So what exactly is the hardness result that we're going to talk about? Like what does it mean to answer statistical queries with differential privacy? So we're in a setting where we have some database that has n elements and each element is somebody's data and each individual's data comes from this data universe that I'll denote by x. And we want to answer statistical queries on this data set and these are queries of the form what fraction of individuals in this data set satisfies some predicate p and the collection of all these predicates will be called the query set capital Q. And we want to do this task with differential privacy, which means that we do it in a way that such that no one individual's data has significant influence on our answers. So a little bit more formally, we're in this non-interactive differential privacy setting where from some database, I want to be able to create a summary S that can be interacted with by any algorithm to ask to receive answers to queries for all the queries in the query set. And the guarantee for differential privacy says that for any two adjacent data sets, so adjacent means that they differ in exactly one element, so here D star is adjacent because it differs in the second element, so it changed x2 to y2. So for any two adjacent data sets, then if we use the other data set to construct the same summary, then the behavior of the adversary interacting with the summary shouldn't change up to some small statistical difference. So that's the task and so the question is, can we do this? Can we efficiently answer statistical queries with differential privacy? Kind of how hard it is to do this depends on how large of the query set and how large of the data universe you want to be able to support. So Blum et al and Dvorak et al show that if both of these sets are polynomially large in the size of the database, then it is possible to answer specific queries with differential privacy in an efficient manner. And like I said before, the trader-facing scheme of Bonaigendri combined with the Dvorak et al lower bound show that there is a set of queries and data universe that is super polynomially large in the data set size for which this task is impossible efficiently. And in 2016, we showed that it's actually okay for either of the two sets to be super polynomially large to show that this is not possible. And so this is good and it kind of gives us a nearly complete picture of the complexity of this problem, except for the problem that all these lower bounds assume indistinguishability obfuscation and we'd like to get rid of that. And this prompts Salil Vadan in 2016 in his survey on differential privacy to pose as an open problem if any of these hardest results can be replicated under quote, a more standard and widely believed complexity assumption. And so you can kind of view the work of Reshabaral and our paper as a partial answer of yes to this question where we replicate the lower bound of Bonan Jandri's trader tracing scheme without having to assume bilinear maps. So in Reshabaral's paper, they assume just bilinear map machinery and in our paper, we just assume one way functions. And our result actually goes a little bit further past this bottom right box in the key direction to achieve a slightly better super polynomial bound. So I'll talk a little bit about the techniques that we use. Basically both papers use a modified version of the lower bound argument of the original Vork et al paper. And so I'll explain that first. So we're gonna construct a setting that we show is impossible to answer statistical queries with differential privacy. And so consider a database where each of the elements is a secret key in a trader tracing scheme. And we're going to consider answering the statistical queries of the following form which are parameterized by ciphertexts in the trader tracing scheme. So the query for ciphertext C asks what fraction of the database decrypts the ciphertext C to one. And so this gives us a query set of size two to the size of each ciphertext and the data universe of size two to the size of each secret key because we have one query for every ciphertext and one. And so the key observation in this argument to show that this particular situation is impossible is that in this setting any summary S that answers these queries is itself a pirate decoder. And you can see this because every element in the database is a secret key. And so if we have the ciphertext then either all the secret keys in this database decrypt the ciphertext to one. Say the ciphertext is either an encryption of one or zero. So either all the secret keys decrypt it to one or all the secret keys don't decrypt it to one they decrypt it to zero. So the answer to the statistical query is either going to be one or zero which is the decryption of that ciphertext. So any summary of this database is going to be a pirate decoder and therefore by the property of the trader tracing scheme we know that we can run this trace algorithm on it to identify an index of one of the secret keys that was used to create the pirate decoder. There are n secret keys here that are used to create the summary. So just by a pigeonhole principle there's some index that this algorithm is going to output with probability more than one over n. Let's call it, let's say that index is i. So that's fine but the problem comes into when we use the differential privacy guarantee now to change the database. So we know we can switch this database that we use to generate the summary to any adjacent database without changing the behavior of any algorithm interacting with the summary. So if we change the database to not use secret key i anymore and instead substitute it say with secret key two then we know by differential privacy that the trace algorithm won't change its behavior and so it will continue to output index i with this somewhat high probability except now it's going to be an incorrect designation of because we know that secret key i was not used to create the summary. And so this is the contradiction that it violates the tracing property and gives us our lower bound in the original work at all paper. So the paper of Rishabh at all basically say they look at the same lower bound and they notice that it kind of still goes through even if the trace algorithm doesn't succeed with 100% probability. And so instead they're able to substitute their risky trader tracing scheme and get a lower bound that matches the Vonage-Andree result with a query set and data universe of exponential size of the security parameter due to the size of their cyber text and secret keys with only using their risky trader tracing scheme which only needs bilinear maps. In our paper we kind of take the same analysis again and we make some additional observations about it. The first and kind of the main idea is that we notice that the trader tracing scheme in this argument doesn't really even have to be public key. Like there's nothing in the argument that needed the fact that cyber text can be generated in a public key fashion. So that's one weakening that we can get. And the second thing is that we can notice that the summary in this argument is created before without any knowledge of the cyber text. So the differentially private algorithm that's creating the summary here, which is the pirate decoder, it only ever sees secret keys. It doesn't have to know anything about the cyber text. So we can consider a weakened version of trader tracing where the security of the trace algorithm doesn't have to, only has to work on pirate decoders that were created without knowledge of the cyber text. They don't need any kind of like CPA security. So to create this kind of private key, weakened trader tracing, security trader tracing scheme, we show how you can do this from functional encryption for comparison functions. And we use a modified construction of the Gorbinov et al. Public key functional encryption scheme for bounded collusion. Basically we make it turn it into a private key variant that lets us do some modifications on it to get the weak trader tracing scheme that we need. And we can do this just using one way functions. So that's kind of all I have time for. Just to recap, what we're doing here in both of these papers is replicating a lower bound for answering statistical queries differential privacy and removing the dependence on indistinguishability obfuscation and replacing it just with bilinear maps in the Rashad al paper and one way functions for our paper. And there's a lot of future work to be done here. Like obviously we'd like to kind of expand this and remove all the red dependence on indistinguishability obfuscation. And also there's a work on maybe reducing the complexity of the queries that are allowed because the complexities in this case are kind of complex cryptographic decryption operations. And it would be nice to have lower bounds that are dependent on the kind of more simple queries showing that simpler queries are impossible to answer. All right, that's it. Thank you.