 Today, I will be talking about some new results for trader tracing. Trader tracing solves the following problem. We have a content distributor who is encrypting a broadcast to a bunch of recipients. Each recipient has their own secret key. What we are concerned about is that one of the recipients may take their secret key and distribute it. Maybe they distribute their secret key in the clear, or maybe they embed it in some sort of decoder device. What the content distributor would like to do is if they ever come across such a decoder device, they want to be able to identify the trader. We want to make sure that they can identify the trader, even if arbitrarily many users collude in order to build the decoder. Also, even if the decoder doesn't always work, even if it fails most of the time to decrypt an encrypted broadcast, we still want to be able to trace the decoder to one of the traders. I want to spend a little bit of time talking about what the main objective in trader tracing is. It turns out it's easy to build a trader tracing scheme. What is difficult is to build a trader tracing scheme with small parameters. If you had asked me a few years ago, I would have said the goal of trader tracing is to build a collusion-resistant trader tracing scheme where the ciphertext overhead is minimized in terms of the number of users. This sentiment is common to much of the literature on trader tracing. However, this is not the entire picture because in 2002, Bonnet and Naur showed how to use general public encryption to get the trader tracing scheme where the ciphertext overhead is actually very small. It's just two ciphertexts, in particular, constantly independent of the number of users. What have we been doing for the last 18 years if we've already solved the problem of small ciphertext size? Well, there's a couple of different views on why the Bonnet and Naur scheme doesn't count. One view that you'll find in much of the literature is that the Bonnet and Naur scheme doesn't meet the usual definition we want in the sense that it is only a threshold scheme. What a threshold tracing scheme means is that you can only trace the decoder if they decrypt most of the time. Remember, we said we want to trace decoders that decrypt very, very, even very, very rarely. Now, this constant 0.9 is somewhat arbitrary, but we can imagine and we can imagine shrinking it. But the idea is that once you have fixed the percentage of the time that you want the decoder to decrypt, you can actually easily fool tracing by decrypting slightly less often. If you're decrypted with probability 0.8 in this case, you can actually avoid tracing. The other problem with the Bonnet and Naur trader tracing scheme is that the secret keys are extremely large. They're namely quadratic in the number of users, and being quadratic in the number of users is considered too large to be useful. Based on these problems identified with the Bonnet and Naur scheme, I want to take a more general view of what the goal of trader tracing is. If you ask me today, I would say the main goal of trader tracing is to build a collusion resistant trader tracing scheme that offers the best parameter side tradeoffs in terms of the number of users and ideally we would do this also without the threshold limitation. This is going to be the overarching goal of this talk. Let me just introduce some notation. There's three parameters of interest in trader tracing. There's the public key size, the secret key size, and the side protect size. I will use the notation, this triple of functions of n to denote the public key, secret key, and side protect size respectively. On the right here we have some schemes that are built from generic tools like public key encryption or identity based encryption. So up on the upper right is sort of a very easy way to build trader tracing that we'll talk a little bit more about later. At the bottom on the right is the Bonnet and Naur scheme with its quadratic, secret keys, and constant size, and side protect. Here on the bottom left we have some algebraic schemes that improve on these parameters. We have a scheme from pairings from Bonnet, Sahay, and Waters that gets n to the one half public keys and cipher text with constant size, secret keys, and then some improvements using the sophisticated tool of indistinguishability obfuscation, which simultaneously gets all parameters to be constant size, and then more recently, Goyal, Coppola, and Waters were able to achieve similar parameter sizes but from LWE. So based on the current state of the art, we can identify a few interesting open questions. So the first one is from generic, even if you're going to ignore the threshold limitation and allow for threshold tracing schemes, is there a way to achieve sub-quadratic secret keys and sub-linear cipher text from any of the following tools, public key encryption, identity-based encryption, groups without a pairing operation, or any factoring-like assumptions? Another open question is, again, even if we don't care about the threshold tracing limitation, is can you get sub-quadratic secret keys and sub-root and cipher text from pairings? And then lastly, let's insist on threshold tracing, but now ignore public key and secret key size. Is there any way to get sub-root and cipher text from anything other than LWE and indistinguishability obfuscation? So one observation is that all of the best collusion-resistant schemes from the literature follow something called a private linear broadcast encryption or PLBE, which I'll describe on the next slide. And by best, I mean that, well, you could take it to mean multiple things. You could take it either to mean no threshold limitation, or you could take it to mean where all of the parameter sizes are sub-linear. So basically all of the best schemes more or less follow the same approach, which is this private linear broadcast encryption. So what is this? Private linear broadcast encryption is a type of broadcast encryption where every user is given a number from 1 to n. And when you encrypt, you can specify index j. The encrypted broadcast can then be decrypted by any user whose identity is less than or equal to the index j. On the other hand, if your identity is greater than the index j, then you cannot learn the message. The additional requirement is that essentially the index j is hidden. Now, of course, a user i learns whether they decrypt or not, and therefore learns whether i is less than or equal to j. But the user should learn nothing else about the index j. Now, what we know, as proven by Bonaise, Sahay, and Waters, is that if you have a private linear broadcast encryption, this actually implies a trader tracing scheme with the same exact parameters. So building private linear broadcast encryption is actually very easy if you're to ignore the parameter sizes. Basically, you just give every user a distinct independent secret key for a public key encryption scheme. And when you want to encrypt to all users less than or equal to j, you simply encrypt the message separately to all of those users. And for all the remaining users, you just put some dummy message, say a special symbol bot. So all users above j won't be able to decrypt, and all users below j will be able to decrypt, and only a user knows whether or not they were able to decrypt. So the trivial private linear broadcast encryption system achieves linear size ciphertext, and basically what all of the best trader tracing schemes do is they give improved algebraic constructions of private linear broadcast encryption, which then they rely on the theorem of benign signwaters to derive a new trader tracing scheme from that. Now for pairings, going through private linear broadcast encryption seems to present a barrier. What are pairings? Pairings essentially allow our groups that allow for decreed two functions in the exponent. The reason this leads to an end to the one half size ciphertext scheme is that you can roughly imagine arranging the end ciphertext components of the trivial private broadcast scheme into a grid of end to the one half by end to the one half. Now you will leverage the fact that you can compute degree two functions to write this matrix as the tensor product of two vectors, each of length end to the one half. So what you actually give out in the ciphertext then are these vectors of length end to the one half. And then when you decrypt, you can reconstruct the end total ciphertext components using the fact that you have a pairing. And as far as we know, the best known private linear broadcast encryption scheme from pairings achieves this end to the one half value. And we don't know anything better. So in this work, what we do is we offer a handful of new techniques for trader tracing outside of the private linear broadcast encryption paradigm. And this will allow us to circumvent the end to the one half barrier and more generally just get new parameter trade-offs from pairings as well as a few other results from other primitives. So let me just briefly summarize our results. So from pairings, all our trader tracing results will generally have the form where the secret key times the ciphertext size will be equal to n. Or if I look at the exponents of n for the public key, secret key and ciphertext size, the exponents will sum to one. For example, if we take the trivial construction of private linear broadcast and instantiate it using identity-based encryption, which allows you to shrink the public key size, this gives us the scheme in the lower right-hand corner with constant size public and secret keys, as well as linear size ciphertext. On the other hand, the Bonaisei water scheme sort of lies in the middle on this right edge here with this end to the one half size public keys, constant size secret keys and end to the one half sized ciphertext. So our results are everything in green. So one is we sort of interpolate between the trivial trader tracing scheme and the Bonaisei water scheme. And we also give this triangle at the bottom here. The interesting parts that I want to draw attention to are the lower left-hand corner where we achieve constant size public keys and ciphertext while having linear sized secret keys, thus significantly improving on the Bonaisei water scheme. And in the middle here, we actually get a scheme where all parameters are actually order end to the one third. Thus, if your goal is to sort of minimize all parameters simultaneously, this scheme will achieve the best known from pairings. And I want to emphasize that all of these schemes do not have the threshold limitation. Some other results from pairings is we look at the setting of broadcast and trace, which augments the trader tracing system with a broadcast functionality. The best previous known from pairings alone was by Bonaisei waters in 2006. We showed how to get all parameters simultaneously equal to end to the one half. We improve on this slightly by still getting into the one half for the public keys and ciphertext, but getting constant sized secret keys. We also offer some more trade-offs between the public and ciphertext size. On the other hand, we actually also show how to shrink the ciphertext below square root, all the way down even to constant, though at the cost of linear sized public and secret keys. And this is actually, this improved significantly on the prior work of Goyaltol, who show how to get very small ciphertext, but not constant sized, from both, from the combination of pairings and LWE. So we've removed the need for LWE and we actually get truly constant sized ciphertext. We also improve the secret keys as well. Finally, our last set of results are generic and we show first, essentially how to remove the threshold limitation from the Bonaisei Naur scheme, thus getting a scheme from general public encryption with constant sized ciphertext and no threshold limitation. And then using identity-based encryption, we can shrink the public key size. One interesting thing is that we can actually trade off between the secret key and ciphertext size and achieve both being sized into the two thirds. And this gives us the first fully sublinear scheme from general IBE, which can then be instantiated from pairing-free groups or factoring-like assumptions. So in order to achieve these results, we develop a handful of new techniques. First, we show actually how to generically remove thresholds from any threshold trader tracing system without asymptotically changing the parameter sizes. We show another theorem that trades off the public and secret key sizes with the ciphertext size, allows you to shrink public and secret keys at the cost of expanded ciphertext size. We look at something called risky tracing and show how to remove the risk from risky tracing schemes at the cost of larger secret keys. We look at something that we call threshold broadcasts. Here, the notion of threshold is not to be confused with threshold tracing. I'll elaborate on this a little more later. And we show that threshold broadcast encryption can be used to build a trader tracing system. And then finally, we give some new algebraic instantiations from parents. So now I'll just very briefly talk about our new techniques. So first, for trading off ciphertext size for public and secret key sizes, essentially what we do is we just generalize a trivial private linear broadcast construction. So what we do is for some parameter T, we will set up T independent instances of some underlying trader tracing scheme, but we will instantiate the underlying trader tracing scheme with fewer users, namely N over T users. So now the total number of users across all T instances of the scheme is actually N, but we've instantiated each scheme with fewer users and hopefully reduced the parameter sizes. However, to encrypt, to make sure that everyone encrypts, we have to encrypt to every instance separately, thus blowing up the ciphertext size. And in particular, we get the following parameters. So if our original scheme had public secret key and ciphertext size P, K and C, we we now evaluate those those parameter sizes on on N over T instead of N. But then we have to blow up the public key by a factor of T because we need a public key for every instance. And we also blow up the ciphertext by a factor of T. The good news is that we can often actually avoid blowing up the public key size using IBE techniques. And the result is we really shrink the public key and secret key size at the cost of larger ciphertext. One thing to note here is that the tracing algorithm incurs a factor of T loss, and this means that we can't use threshold tracing. So we can't apply this, say, to the Binet-Naur scheme. However, our next result shows how to remove the threshold limitation. And our idea is actually pretty simple. Basically, to suppose we have some trader tracing scheme that has this threshold limitation, so we can only trace decoders that decrypt most of the time. What we will do is we will take a message that we want to encrypt, and we will split it into a bunch of shares, say, using a T out of T secret sharing scheme, and then we'll encrypt each share separately. The idea here is we're essentially performing some sort of hardness amplification that will allow us to transfer a decoder with very, very small success probability into one with much larger success probability. The key feature of this transformation is that the number of shares that we need to split into is independent to the number of users n and can be taken just to be the security parameter. And therefore, we don't change the asymptotics of any of the parameters in our scheme as a function of them. Now, combining this generic removal of thresholds with our parameter-sized thresholds and our parameter-sized trade-off from the previous slide, this is already enough to get us our public encryption identity encryption results. Next, I'll talk about mitigating risk. So what is a risky tracing scheme? Where it's one where you're guaranteed never to accuse an honest user, but you may fail to accuse anyone. There's actually, with a risky trader tracing scheme, there's a high likelihood that you'll actually fail to accuse any user. But the guarantee is that there's at least some small probability that you will accuse a malicious user. Goyal et al defined this notion and moreover showed how to construct a risky scheme with constant-sized parameters, except the amount of risk is very high. So you're only guaranteed to trace to a malicious user with probability one over n number of users. So we show is actually that it's possible to remove the risk from a risky tracing scheme without blowing up the parameters too much. The idea is going to be kind of like before, we're going to run T independent instances of the underlying risky tracing scheme, except here we're going to have each instance still have n users. So now there are n times T different secret keys across all the instances. The secret key for user I will sort of be a slice selecting one secret key from every one of the T schemes. And when it comes time to encrypt, what we're going to do is we're going to encrypt to we're gonna choose a random instance every time we encrypt, and we're just going to encrypt to that single instance. So there's only ever one cyber-texting performance. The rough idea is that if you have a tracing algorithm that can let's say always decrypt, if it can always decrypt, that means it can decrypt no matter what instance was chosen during encryption. And this means that the decoder is actually able to decrypt for all possible instances. So what you can do is you can take this decoder and actually derive from it a decoder for each one of the possible instances. Now the tracing guarantee says I have some probability of tracing each one of these decoders. And we show essentially that the probabilities sort of act as you would expect so that if you run T independent instances, the probability that they all fail is one minus the riskiness of one instance raised to the T. So what you can do is then set T to be something like one over alpha or a little more than one over alpha and you'll actually trace with overwhelming probability. Now in order to get things to work, we actually require that the original decoder succeeds with high probability, say 0.9. So we only immediately get a threshold scheme, but fortunately we have our threshold elimination compiler which we can then apply on top of this to get a full scheme that completely removes the risk. And the parameters that we ultimately get are we preserve the cyber text size of the scheme, but we blow up the public key and secret key size by a factor of alpha inverse. The good news is though that like before, often using identity-based encryption techniques, we can actually save from blowing up the public key size and the result is we only increase the secret key size. And this is enough to get our scheme from pairings with constant size public keys and cyber text by combining our risk mitigation with our previous parameters. Finally, I wanna talk about threshold broadcast. I won't formally define this, but instead I'll define a simpler notion of broadcast encryption, which is kind of like private linear broadcast encryption except one, when I encrypt, I can actually choose an arbitrary set of users rather than just a linear set like in private linear broadcast encryption. And the other difference is that in broadcast encryption, the set S is public. So our idea is to try to take a broadcast encryption, even though the set S is public, we're going to try to use it to be able to encrypt it to secret sets. And by encrypting to secret sets, we will allow for tracing somewhat analogous to the private linear broadcast set. So what we do is we assign users essentially random identity so that only the user knows their identity and no one else knows it. And this basically, because no one else knows that user's identity, it'll essentially allows us to encrypt to a set of users without actually revealing who the users are. This doesn't quite work. And this is why we need to generalize some threshold functionality, which I won't really define. So when we put everything together, what we're going to do is we're going to first take an existing threshold broadcast encryption scheme. We're going to optimize it for the trader tracing app. We're going to combine it algebraically with techniques for developing risky trader tracing. We'll apply our compilers and at the end we'll get our trader tracing results. So in summary, the high level takeaways from this work are that one, private linear broadcast is not inherent to achieving good trader tracing results. Another takeaway is that threshold tracing is no longer a limitation. We can generically remove thresholds without affecting the parameter sizes. The final lesson is that risky and threshold tracing are actually useful stepping stones to building full trader tracing schemes. These objects were originally defined as sort of ends on their own or for other applications. And what we have shown is that you can actually start from a risky or threshold trader tracing scheme and achieve a full trader tracing scheme, potentially at some cost parameters. And with that, I conclude my talk. Thank you.