 So I'll be talking about collision resistant, a trace and revoke for arbitrary identities from standard assumptions. So this is joint work with Davey Wu. I'll be talking about trace and revoke schemes in this talk. So let me start by defining and motivating the concept. So let's begin with a simple share key decryption system and motivate trace and revoke from here. So in a setting, we have a group of users in the system, let's say a set of employees in a company, and we want a way to be able to encrypt messages to everyone in the group. Well, we can do this very simply by generating a public key for the group and then providing everyone with a corresponding decryption key for the public key. And so whenever someone wants to broadcast out a message to the group, it can encrypt the message under this single public key and broadcast it out to do the network. Then since everyone in the group holds the share decryption key, everyone can decrypt the cyber text and recover the message. So this simple scenario is all nice and fine and the system is secure under the assumption that the share key is managed properly by everyone in the system. But now let's consider the scenario where this assumption does not hold and the key is actually not managed correctly. So let's suppose that there is actually a malicious member in the group that leaks the share key to the open internet. So if this happens, then since the share key is out in the public, we cannot have any type of security in the system. So if this happens, then from the perspective of the company, it will want to be able to identify who the employee was that leaked the shared key. So it will want to be able to, you know, trace and trace the trader so that he can punish the trader and prevent this from happening again in the future. But in the simple shared key system, since everyone holds the same single share key, there's no way to tell, you know, who was the one who actually leaked the key. So this is actually where trader tracing comes in. So this is an old concept that was introduced by a choreotile in 1994. So in a trader tracing scheme, everyone in the group holds a key of its own. And the scheme still guarantees broadcast functionality as before, in that if we encrypt under a single public key, then everyone in the system can use its own decryption key to decrypt the side effects and recover the message. But when a malicious member leaks a key to the outside, then there is a tracing mechanism that when given access to what was leaked can correctly point to the trader that leaked its key. So this is basically the idea of trader tracing. So what makes constructing a trader tracing scheme a highly non-trivial is the way that we model this leakage of key. So we usually model the malicious member leaking the key as creating some sort of a decoder box. So intuitively we can think of a decoder box as some decryption software that has like the malicious member's decryption key embedded inside it. And the software can be in any form and it can be like highly obfuscated. So we need to design a tracing algorithm that can interact with this decoder box in a black box way and identify the trader. So this is kind of what makes trader tracing a difficult problem in general. Finally, a trace and revoke scheme is a concept that was introduced by Naur and Pickers as a further extension of trader tracing. So let's say the company was able to identify that Bob was the one who betrayed the group and created the decoder box, then is there a way for the company to revoke Bob's access to future cyber attacks without going through a complicated key rotation procedure? Well, a trace and revoke scheme allows us to do this. So in a trace and revoke scheme, the encryption algorithm additionally takes in a blacklist of users or what is called a revocation list. And so let's say that the resulting cyber attacks is broadcasted out to everyone in the system, then everyone who is not in the revocation list can decrypt the cyber attacks. Everyone who is included in the revocation list cannot decrypt the cyber attacks. So this is the concept of a trace and revoke scheme. So there are a number of idea properties that we may want from a trace and revoke scheme. So the first is collusion resistance. So suppose that we have multiple parties in the group that are malicious and are polluting with each other. So let's say Bob and Charlie come together, uses both of their two keys and create a decoder box. Then we still want our tracing algorithm to take this decoder box and be able to identify at least one of the malicious members of the group. So the second property is unbounded revocation. So in some existing revocation schemes, the set of algorithm must specify a bound on the sides of the revocation list. So in these schemes that we have to specify that we're going to revoke M-modes like 10 users in the system or 30 users in the system, and we have to specify this at setup. So ideally, in a revocation scheme, we would like to be able to support an unbounded size of our revocation list. And the next is blockbox tracing. So like I mentioned before, the decoder that a malicious member generates may be in any form and can be obfuscated. So we want our tracing algorithm to be able to work only given the input and output behavior of the decoder box. And finally, another property that we may want from a trace and revoke scheme is the ability to support unbounded number of users. So in many existing schemes, to generate the keys for each user, we have to run a single setup algorithm that takes in a bound on the total number of users in the system. So after this setup, no user can additionally join the system. So it would be nice if the scheme is identity-based in that any new user can go to a key generating authority and receive a decryption key for responding to their identity. This way, an unbounded number of users can join the system. All right, so our goal in this work was to achieve a trace and revoke scheme that achieved all of these idea properties while relying only on standard assumptions. So if we look at the existing trace and revoke literature, there has been a lot of beautiful papers with very elegant ideas, some of these which I am listing here. But none of these constructions actually address all of the properties that I listed in the previous slide. So there are constructions that only support security against like bound conclusions, which means that security is guaranteed only when a pre-specified number of users come together to generate a decoder. Some of the constructions are not identity-based. So it can only support a point number of users. There are also constructions that achieve, I guess all of the properties that we want from the previous slide, but relies on strong assumptions like Windows encryption or indistinguishability obfuscation. So in this work, we construct a new trace and revoke scheme. So our construction satisfies all of the properties that I listed out previously. So it is fully collision resistant, it is identity-based, it can revoke an amount of number of users, and we only rely on the hardness of LWB for our security. And so for trace and revoke schemes, the Cyprotech size is an important metric that we generally have to consider. So for a scheme, the size of the Cyprotech does depend linearly in the size of the revoke set, but the size grows logarithmically with the number of bits needed to represent each identity of users. So I can discuss more about Cyprotech size later on in this talk. All right, so for the remainder of the time that I have, let me give a high-level overview of our construction. So most of the existing constructions on Trader Tracing and Trace and Revoke schemes in the literature follow a general paradigm of constructing or using what is called a private linear broadcast encryption or PRB for short. So this is a concept that was first introduced by Bonet et al. in 2006, and it serves as a natural stepping stone to constructing a tracing scheme. So we also just follow this paradigm and since most of the intuition for constructing a Trader Tracing scheme or Trace and Revoke is embedded inside this concept. Let me give this concept, let me describe this concept in a little more detail. So the syntax might look a little bit odd if you have never seen this before. If you're familiar with attribute-based encryption, then the syntax will be a little bit more familiar. So a PRB scheme is first of all an encryption scheme. So there is going to be a set of algorithm, an encryption algorithm and a decryption algorithm. So the set of algorithm is going to generate a set of public keys or public parameter, a tracing key and a set of decryption keys. So intuitively, we can imagine like a set of algorithm being run once and the public parameters are public, the tracing key is provided to some tracing authority and each decryption key is to be distributed to everyone in the system. All right, then the encryption algorithm, which I will denote by PP encrypt for this talk, takes in the public parameters and message and it spits out a cybertext which I will denote by CT zero for reasons that will be clear in a minute. And then the decryption algorithm is a natural one that takes in a decryption key, a cybertext and produces a message in the end. Okay, so now what is special about a PLB scheme is that there is another way of generating a cybertext. So this is what I am going to call the TK encrypt which takes in a tracing key, an index I and a message M and produces a cybertext CT sub I. So the PP encrypt is basically a public encryption algorithm that only requires the public parameters to generate the cybertext. So the TK encrypt is basically a private key encryption algorithm that requires the tracing key to actually generate the cybertext. So the correctness condition for a PLB scheme guarantees that a decryption key SK sub I can decrypt any cybertext CT sub J for J less than or equal to I. So any decryption key SKI can decrypt any cybertext that were generated via either the public encryption algorithm or the private key encryption algorithm for indices that is less than or equal to my. So for security, we require that a PLB scheme satisfies three security properties. So the security properties might be a little bit weird at first but when I discuss how we construct a tracing scheme from PLB in the next slide it will become a little bit more clear. All right, so the first property that a PLB scheme should satisfy is what is called a normal hiding. So this property says that a cybertext that is generated via the public key for the public encryption algorithm is computational indistinguishable from a cybertext that is generated via the private key encryption algorithm under the index R1. So remember that our correctness condition guarantees that SK sub I can decrypt all cybertext that is encrypted under the index J that is less than or equal to I. So and the decryption keys that are generated from the set of algorithm ranges from one to N. So these two cybertexts that were generated via the two encryption algorithms are basically can be decrypted by anyone in the system. And we're requiring that these two cybertexts are computationally indistinguishable. Next, a PLB scheme should satisfy our index hiding which says that without a decryption key, SK sub J it is computationally invisible to distinguish a cybertext that is encrypted under the index J and a cybertext that is encrypted under the index J plus one. So the correctness condition guarantees that if a user only has access to a decryption key that is under an index that is not equal to J then you can either decrypt both of these cybertext or not be able to decrypt both cybertext. So the index hiding requirement guarantees that without a decryption key for index J one cannot distinguish between these two cybertext. And finally, a PLB scheme should satisfy message hiding which is analogous requirement for standard semantic security. This says that without a decryption key for an index I that is greater than or equal to index J the cybertext that are generated under index J is a semantically secure. All right, so let me describe how we go about constructing a trader tracing scheme from a secure PLB scheme. So, well the set of algorithm is going to be run in the beginning as I described before. So the tracing key is going to be provided to some tracing authority and the description keys are going to be distributed to each user in the system. Then for general encryption we would just use the public encryption algorithm. So by the correctness condition of the PLB scheme everyone in the system can decrypt the cybertext and recover the message, right? Now suppose that a user in the system creates a decoder box. So in this example, say Charlie creates a decoder box and he has index three. He's associated with index three. So let's say the decoder box has a Charlie's key as case of three inside it and the box can decrypt any cybertext that is encrypted under the public encryption algorithm. So how would the tracing authority trace Charlie, trace the trader? Well the tracing authority is going to first use the private encryption algorithm to generate a cybertext under the index one. So let's say, so let's call this cybertext CT1 the authority will basically just test whether the decoder box can decrypt the cybertext CT1 or not. So by the normal hiding security property the decoder should not be able to distinguish between a publicly encrypted cybertext and a privately encrypted cybertext. So the decoder box should still be able to decrypt the cybertext under index one given that it can decrypt any cybertext that is encrypted under the public encryption algorithm. All right, next the tracing authority would then try index two. So it will run the private encryption algorithm with index two to generate CT2. Then it will test whether the decoder box can still correctly decrypt CT2. So by the index hiding property the decoder box should not be able to distinguish between CT1 and CT2. Remember the index hiding property guarantees that to distinguish between CT1 and CT2 one needs a decryption key SK1 which means that only Alice can distinguish between these two cybertexts. So the decoder box that was created by Charlie cannot distinguish between CT1 and CT2. So it should correctly decrypt CT2. All right, and the tracing authority continues this process. So it generates a cybertext CT3 and tests whether the decoder works on this cybertext or not. Then you will also generate CT4 and test whether the decoder works or not on this cybertext. Now by the message hiding security the decoder box that only has the decryption key SK3 inside it should not be able to decrypt cybertext CT4. And this is because the index associated with SK3 is less than the index associated with CT4. Remember that message hiding security guarantees that a key SK sub i can only decrypt cybertext SK sub j for which j is less than or equal to i. So this decoder box will be able to correctly decrypt CT3 but not CT4. So after testing out all of these cybertexts on the decoder box the tracing algorithm can deduce that Charlie was actually the one who created the decoder box. Of course, this is a huge simplification but this is really like the main intuition behind Trader Tracing from PLB. All right, so we know that a PLB scheme gives rise to a Trader Tracing scheme. So what do we currently know about PLB constructions in literature? Well, there are a couple of constructions and from LWB there is a beautiful construction that is due to Goyal Atel from 2018. So we can use Goyal Atel construction to achieve a regular Trader Tracing scheme that can support a polynomial number of identities. So our goal in this work was to construct an identity-based Tracing Revolve scheme. So we had to basically solve two problems. So the first was on constructing a Trader Tracing scheme that allows us to trace traders from an exponential pool of users in order to make it identity-based. And the second was on adding a replication functionality on top of this resulting Trader Tracing scheme. The first problem was relatively straightforward to overcome. So the starting point is, what's the work of Goyal Atel from 2018? So which gives a PLB scheme from LWB that supports a polynomial number of users. But if you look at their construction, then algebraic speaking, we can actually embed an exponential number of user information in the cybertext. So in order to upgrade the GKW construction from a polynomial identity-based Trader Tracing scheme to an exponential identity-based scheme, we just needed a tracing mechanism that allows us to trace identities in an exponential identity space. So if you recall the tracing algorithm that I described on the previous slide, the tracing algorithm tests the core box on CT1, CT2, CT3, and so on. So this tracing algorithm works only when we're working with like polynomial identity spaces and it will not run efficiently for exponential identity spaces. So the question is, how do we go about tracing users from an exponential identity space? And for this, there is actually a very nice work due to Anishimaki Atel from 2018 that gives a very nice tracing algorithm for like exponential identity spaces. So it is basically a recursive version of the tracing algorithm that I described on the previous slide. So the tracing algorithm from the previous slide is like analogous to like a linear search. The LWB tracing algorithm is analogous to like a binary search. Okay, so to construct a trader tracing scheme for exponential identity spaces, it seems like we can just combine the techniques from GKW and NWZ. And that is actually exactly what we do. But we do have to be to do this in like a careful way. And in particular, the PLB syntax does not actually support the NWZ tracing algorithm. So we basically have to generalize the GKW-18 construction from a PLB scheme to what is called a general predicate encryption scheme with some additional properties. So I will go over a predicate encryption in the next slide. And the second problem of adding the revocation functionality to the resulting trader tracing scheme requires a bit more work. The main technique that we use is what is called a subset cover set system, which is a specific combinatorial way of encoding user identities so that we can revoke users efficiently. I will talk more about this after I discuss the predicate encryption. All right, so let me go over the syntax for our predicate encryption scheme. So I guess much of this space is about the right set of definitions. So the notion of tracing is actually very subtle and is important to have like the right set of primitives to work with in this space. So the version of predicate encryption that we use in this work may look a little bit different from the traditional notion of predicate encryption. We're going to have the traditional predicate encryption algorithms. So the setup, key gen, encrypt and equipped. The version that we use in this work is a cybertext policy predicate encryption. So the policy function is associated with the cybertext and attribute search associated with the keys. In this work, we use predicate encryption with an additional broadcast functionality. So it has a broadcast algorithm that takes in the public parameters and a message and produces a cybertext to CT. The correctness condition is basically as follows. For cybertext that was generated by the standard encryption algorithm, a key S case of X can equip the cybertext to CT sub F. If and only if F of X equals to one. And for cybertext that were generated by the broadcast algorithm, any decryption key can decrypt the cybertext. So this is basically almost a direct generalization of a PRB scheme. So the broadcast algorithm corresponds to the public encryption algorithm of a PRB scheme. The encryption algorithm here corresponds to the private key encryption algorithm in PRB. What is a little bit different here from then a PRB scheme is that a set of algorithm generates a master secret key. Then the key generation algorithm takes in a master secret key and produces specific decryption keys for our different attributes. So this can support an exponential number of identities. So it is important here to note that the broadcast functionality that we use here is different from the strong broadcast functionality in the context of broadcast encryption. So here by broadcast we just mean a way to encrypt so that like any key can decrypt the cybertext, right? So, and a security requirement, I won't go over it, but it is basically a very straightforward generalization of the security requirements for a PRB scheme. So if we had a predicate encryption scheme with these correctness and security requirements, then we can combine it with the tracing algorithm of the Shimaki Airtel to construct a trader tracing scheme that can support an exponential number of identities. The question then is how we go about constructing a predicate encryption scheme with these properties. And I won't be able to give the precise details in this talk. So I will refer to the paper for the details, but the construction is very similar to the construction of GKW, of the GKW PRB scheme. We basically just combine attributes encryption with what is called misfunctional encryption as was done in GKW. All right, so in the remaining time that I have, let me just quickly talk about how we achieve vocation. So the main tool that we use to add a public revocation property to our predicate encryption is what is called a subset cover system, which was first defined by an Airtel. So I can define what subset cover system is formally, but I think an example will make things a lot more clear. So let me just go straight to an example. So I think about this as a reverse merkle tree. So imagine we have like a merkle tree structure. So the root is associated with an empty string and the leaf nodes are associated with a string that is determined by its path from the root. So if L is the height of the tree, then each leaf node is going to be associated with a string of length L. So we can construct a simple revocation scheme just using this combinatorial structure. So right now let's not care about tracing and let's just think about constructing a simple revocation scheme. So in a revocation scheme, each user is going to be associated with a leaf in the tree. So in this example, we have like a merkle tree of height three and so we're going to have eight number of users. Then we're going to associate a public key to each node in the tree. So we're going to have a public key for the root and a public key for the node zero, for the node one and so on. So we're going to associate a public key for each node in the tree. Then we're going to distribute the decryption keys to the users so that each user will have a decryption key associated with the leaf node and the nodes of its path to the root. So for instance, user zero will hold a decryption key associated with the node zero, zero, zero, zero and the root. And the user one, one, zero, zero will hold a decryption key for one, zero, zero, one, zero, one and the root. So that is how we will distribute the keys. Now let's say we want to encrypt the message to everyone in the system. Then what we can do is just encrypt the message under the root public key. Since everyone has a decryption key for the root public key, everyone can decrypt such a cybertext. Now consider we want to like revoke a user. So say we want to revoke a user zero, one, zero. So we want to encrypt the message to everyone in the system except for the user zero, one, zero. Well, then using the Merkle Tree property, we can identify a linear number of subtrees that covers all the leaf nodes except for the user zero, one, zero. So we can then encrypt the message under all the public keys associated with the root of each of these subtrees. This property guarantees that even if we have multiple users that we want to revoke, say N number of users that we want to revoke, there will always be a most O, N number of subtrees that we can identify and encrypt to. So we use this structure to construct a revocable predicate encryption scheme. So instead of a public key for a regular encryption scheme, we use the public parameters for a predicate encryption scheme and also see each of these with each nodes in the tree. So this is basically the main idea that we use. I guess one problem with this though is that if there are an exponential number of users in the system, then we need an exponential number of public parameter components in the system because there are exponential number of leaf of nodes in the entire tree. So we get around this problem by modifying our predicate encryption construction so that it has reusable compact public parameters. So we use the property that the public parameters and the master secret keys in existing mixed FE constructions can be generated separately independently. So this allows our encryption algorithm in the predicate encryption construction to generate the mixed FE parameters on the fly. So I will refer to the paper for the exact details on how we do this, how exactly we do this. And that's basically it. This is basically the high level idea. We combine like A, B with a mixed FE to construct a predicate encryption scheme and then we use the subset cover system to do the revocation. The subset cover system that we actually use in the paper is a bit more complicated than the system that I described in the previous slide. We do this for better efficiency. So for a smaller separate size. All right, so let me just quickly describe some open problems. So in our construction, we need a tracing key to trace decoders and this tracing key has to be kept private from the users in the system. So a nice open problem in this area is to actually get public tracing where the tracing key can be just out in the public and anybody can trace decoders. And next is to achieve succinct cybertext. So the size of the cybertext in our system grows linearly with the number of users in the revocation set. It would be nice to get this down to sublinear. And finally, for security, we rely on the subexponential hardness of LWE. It would be nice to get the same results that relies only on the polynomial hardness of LWE. All right, that's it. Thank you.