 Hi all. My name is Sathya. Today I'm going to discuss about our work on very fabulous registration based encryption. This is a joint work with Rishabh Gohar. Let's start with public encryption. Here Alice wants to encrypt a message to Bob. For this we typically use public infrastructure where there is an authority that gives Bob's public key to Alice. The problem with this is Alice needs to contact the authority every time she needs to talk to someone. Moreover, this authority could be corrupt and could be giving wrong keys to Alice. There's a more recent solution called identity based encryption. With this kind of encryption, Alice doesn't have to talk to the authority every time. Here the authority generates a master public key and a master secret key. And using this master secret key, the authority can generate secret key for every user. Here Alice could encrypt a message to Bob just using master public key and identity of Bob. The problem is if the authority is corrupt, then he can generate secret key for Bob and he can decrypt the ciphertext that is meant for Bob. The master secret key that is stored at the authority simply has so much power to it. This problem is famously called ksql problem. It would be great if we can have an IBA type of solution, but where the authority doesn't have so much power. There have been many works that work towards solving ksql problem, but each of them has their own drawbacks. Under recently, Gagandha Dhals came up with a beautiful primitive called registration-based encryption to solve ksql problem. The system has an IBA flavor to it. Here Alice encrypts a message using Bob's identity, but the authority doesn't have a master secret key. The rule of the authority is specifically designed not to have too much power. Bob generates his public key secret key pair himself and sends his identity public key pair to the authority, likewise all the parties send their public keys to the authority. The authority's job is just to accumulate all this gathered information and publish it as a public parameters. We call this a registration process. When Alice receives his public parameters, Alice could encrypt a message just using Bob's name. Just to add some flexibility, the authority can give some supplement information to Bob just to add him in the encryption process. If the authority registers more and more users, the authority can also update this information. Just as a catch, the authority doesn't store any secret information when doing this job. Even the supplement information down there, it can be made public without affecting the security. And now you can ask why can't we just build this public from public encryption? We can just set this public parameters to be the set of all identity public key pairs and that's a valid registration-based encryption. To make RBM more interesting and not reveal, we would like to have all these parameters to be succinct and all the algorithms to be efficient. By that I mean all the parameters should have at most polylogarithmic size in terms of overall number of users and all the algorithms have to run in polylogarithmic time as well. To be more specific, we would like to have short public parameters. We would also like to have short supplement information and when more and more users are registered in the system, the supplement information should be updated at most logarithmic in terms of number of users. And finally, the registration algorithm also for registering Bob also has to be efficient. Coming to what's known before, the original data paper that introduced this notion give a construction from IO that satisfies all the assumptions, all the requirements. And this construction is from non-standard assumptions. The same paper also gave a construction from standard assumptions as well. But in this construction, the authority takes a long time to register Bob's public key. Later on in the follow-up work, they give a construction from standard assumptions that satisfies all the requirements. So it seems like the problem is pretty much solved, right? Well, let's see if it's entirely solved. The original motivation for this parameter is to solve the key SQL problem. Basically, even if the authority is corrupted, we want the authority not to be able to launch any attack. Is this problem solved here? Well, yes, but not exactly. Let's look at back this picture. How can the authority launch an attack? If the authority is being honest, he certainly can't do much because he's only getting Bob's public key. The authority doesn't have any secrets, so the authority certainly can't learn much. But if the authority is not being honest, what can he do? He can generate public parameters in an arbitrary way. For example, the authority can register Bob twice, the first time with Bob's actual key and the second time with some other key. He can also register for other users that didn't sign in for this, the users that didn't send any registration request. That sounds like a serious issue. How does the previous paper solve this problem? They solve it by having an additional audit process. They use the fact that the registration process is deterministic. The authority doesn't need to sample any randomness here. So an auditor can just obtain all the identity public parameters from the authority and the auditor can just read the entire registration process and verify whether auditor published the right public parameters. If end users were registered in the system, the auditor takes at least order and time to verify. All the previous constructions are auditable because all of them have deterministic registration process. What if Bob just wants to ensure that he is registered honestly? Bob doesn't care about any other user. He only cares about himself. Currently, Bob has to run the entire audit process and has to spend audit time even if he wants to check for himself. Can we make it simpler and more efficient for Bob? For that, we introduce this concept called individual verifiability. At a high level, the individual verifiability says that Bob can get a short proof from the authority that Bob is registered honestly. The authority could have cheated when registering other users, but this proof doesn't speak of that. This proof only speaks of Bob. We extend this notion even further. Consider this old man who did not register his public key. It's possible that Alice might still be encrypting her messages to the old man with the authority's public parameters. The authority might be corrupt and probably has registered the old man illegally with some of the public key and might be decrypting Alice Cyphotix. The old man wants to ensure that the authority is not cheating this way. He can give a short proof that the authority did not register him. So there are two kinds of users, registered users and unregistered users. We need proofs for both of them. Certainly, the proofs have to be short and all the proofs and all the verifying algorithms have to be efficient. The security guarantee is that if the authority can give a proof, then he can't cheat. In this paper, we introduce this notion of verifiable RBE. This is just regular registration based encryption with this additional feature called individual registration. We then construct it from standard assumptions. Let's first define the syntax of regular registration based encryption. Here Bob Sam first samples his public key security pair just using regular public encryption. He then sends his identity public key pair to the authority for registration. The authority maintains all the information of all such registered users in some data structure called auxiliary information. The authority registers Bob by updating the auxiliary information along with the public parameters. And it now publishes the new public parameters to everyone. And Alice can encrypt a message just using these public parameters and identity of Bob. Just to add some more flexibility, the authority can give some supplement information to Bob and Bob can use this additional information along with his own secret key to decrypt the subtext. The security property says that if an adversary doesn't have Bob's secret key, then he can't decrypt Bob's secret key. Let's add variability property to this. Here we have two types of users. Bob is a registered user whereas this old man is a not-registered user. The authority can send this old man a proof that he's not registered. The authority generates a proof using pre-proof algorithm and the old man verifies using pre-verified algorithm. The authority can send a proof to Bob that he's uniquely registered. The authority can generate a proof using post-proof and Bob can verify this proof using post-verified algorithm. We use this phrase pre-here because the user is not registered yet and we use this phrase post-here because the user is already registered. And the condition here is the proofs have to be short and all the algorithms have to be efficient. By short and efficient I mean all these parameters should be at most polylogic in terms of number of users. Let's see how to put this into a formal security definition for unregistered users. What do we ideally want? If the user is not registered and the authority is able to give a proof that he's not registered, then a ciphertext meant for the user can't be decrypted even if the authority generated public parameters in an arbitrary way. Here the authority is the adversary and represents a challenging who is not registered user. Coming to the security game, the authority decides what identity the challenger should use and then he publishes some fake public parameters that are generated some arbitrary way and then he also gives a fake proof saying that this identity is not registered as part of this public parameters. And suppose this proof verifies and if it is valid and then the rest of the game follows the regular public encryption. Basically the adversary sends two messages M0 and M1, the challenger encrypts one of them and the adversary needs to distinguish both the cases. Adversary wins if it generates a valid proof and can still break encryption security. You know in many security games it's always a challenger that samples public parameters because we always assume that the public parameters are correctly sampled. But this security is to ensure that the public parameters are not malicious sample. So here the adversary samples the public parameters and that's the major difference between a traditional definition and this one. The security for registered users is also quite similar. For that property we assume a user is registered and the authority doesn't have the user's security and suppose the authority is able to give a valid proof then even though the authority himself generate the public parameters it should not be able to decrypt the user's psychotext. I'm not going into more details of it. Let's have a look at the big picture of what we know. Like I said before we know that all the previous constructions can be verified by an auditor and our construction is based on standard assumptions and it has all efficient parameters. It can also be verified by an auditor and additionally it also satisfies this individual verifiability property. Another advantage of a construction is it's simpler than previous constructions and it also has shorter psychotext size. And what about the previous constructions? Do they satisfy this verifiability property even though they didn't define the notion in the papers? Although we don't formally prove in our paper, we observe that one could just use ideas behind our proof or prove and verify algorithms to even come up with these algorithms for the previous constructions. Alright, so that's it about the motivation and syntax part. Let's finally move on to constructing verifiability from standard assumptions. Let me first start by describing the ideas in the old gugadal constructions. We know that the authority stores the list of identity and public appears and it publishes a short public parameters. Probably the first thought we could have is let's set this public parameters to be hash of all identity public appears and probably the most famous way to hash a list of elements in cryptography is by using the hash and that's exactly what these constructions do. The authority stores a list of identity public appears in the form of a mercury. The actual key pairs are stored in the leaves of the tree each intermediate node is going to contain hash of the left child and hash of the right child. The hash value of the root is going to be the public parameters. Let me give an example. Here the leaf nodes contain the actual identity public values. For simplicity I'm assuming identity as index is here. The intermediate nodes contains the hash of left child and hash of right child. Additionally these constructions also use a solid tree which means that the leaves are sorted as per the identities. To enable searching for an identity each intermediate node also contains the highest identity of the left subtree. So here 17 is the highest identity of the left subtree. The fall of work actually suggested the use of barren trees which means the height of the tree is always going to be at most order login where n is the number of users. For example you can use a red battery for instance. The public parameters would be the hash of the root value and the supplement information for Bob is going to be the path of the root value node to the leaf containing Bob's identity. Now let's see how to encrypt a message. Here Alice wants to encrypt a message to Bob but she doesn't have Bob's public key. All she has is the public parameters that are sent by the authority. Bob can decrypt a suff text only when it is encrypted with his own public key not with anything else. So this seems to be a gap here. How to solve the problem? So Alice creates a program that does the following The program takes a public as input and it verifies whether it is a valid public key of Bob. If it is valid Bob's public key then the program just encrypts the message with respect to the public key and not puts it. But how does the program verify whether it's a Bob's public key? Well the program takes a proof as input. The path from root node of the tree to the leaf containing Bob's public key is actually act as a proof that Bob's public key is correct. And you know Bob has this path as part of his supplement information. So when Bob receives the suff text Bob runs the program with this supplement information as a proof input. He obtains the encryption of the message with respect to his own public key and then decrypt it with his own secret key. Here the message is actually hard-coded in the program so Alice can't give this program as it is. That would be insecure. Alice can obfuscate the program but as I said the construction is from standard assumptions. So obfuscation is out of question. To that end Gurg and others proposed how to replace this obfuscation with the use of garbage circuit using the techniques to prove security based on standard assumptions. I'm not going to do the details of that construction here. And now let's see how to register new users. Suppose the authority wanted to register user 27. What does he have to do? We need to look at the best place to insert this leaf since the leaves are sorted the task is simple. You need to insert the leaf between 24 and 31. And this is what you're going to get after insertion. Since we are dealing with balanced binary trees you may need to rebalance the trees as well. And so when you insert the leaf you need to upgrade the hash values all the way from the leaf to the root value. So the root value gets updated every time you register a user. And now what about the supplement information for user 15? It's going to be path from the root node to the leaf containing 15. Since the root value gets updated the supplement information for user 15 also gets updated. In fact the supplement information for all the old users get updated when you register a new user. And that sounds like a bad news. We are updating this entire tree just for the sake of adding one new user. In the prior constructions they solved this problem by coming up with a two level data structure by mapping identities to timestamps and timestamps to our publicies. In this work we avoid all that complex stuff together and came up with a much simpler solution. Our starting point is an observation that all these old users can still use the old tree, old public parameters and just be happy with it. They can still decrypt the cipher text just using the old tree. So why travel all these old users just for the sake of adding a new user? Why not create a separate tree just for this new user? So let's have the old tree as it is and now let's add another tree to the oxidized information with the user 27 added to it. And now the public would consist of root values of both the nodes, both the trees. We call this old tree as the old snapshot and we call this new tree as a new snapshot. Alice encrypts MSs with respect to each of the trees so now the cipher text has many components. All the old users still use the old tree for the decryption whereas the user 27 uses the new tree for the decryption. So after the user 27 is added the oxidized information for the old users need not be updated. They can still use their old path in the old tree for the decryption. But there's a problem here as well. For every user you are adding a new tree. So that means after n users are added there are going to be n trees in the oxidized information. The public parameters are going to be long and the cipher text is also going to be long. So we saw two extreme solutions here. When n users are assigned to the system the first solution has order and updates to the supplement information whereas the second solution has ordering tree stored in the public parameters. Can we have something in between? Is it possible to store only order log n snapshots in the oxidized information and only give order log n updates to the supplement information for every user? We give a process solution for this and here's a solution. Suppose 26 users are registered until now we are not going to store all the 26 snapshots of the tree that are created until now. We are only going to store three of them. To understand which snapshots to store let's look back at the binary representation of 26. It's 11010. Suppose you return the first one and replace the rest of the bits with zeros. You're going to get 2116. So we are going to store the first snapshot of the tree which was created after the first 16 users were registered and then if you return the first two ones and replace the rest values with zero you're going to get 24. So you're going to store the snapshot of the tree which was created after the first 24 users were registered. This tree includes the previous 16 users around with new additional 8 users. Similarly if you return the first three ones and replace rest of the bits with zero you're going to get 26. So you're going to store the snapshot of the tree which was created after all the 26 users are registered. This tree includes the old 24 users and it also includes two additional new users. And now suppose another tree is added. Now there are 27 users. Do the same binary representation trick. You can observe that we only add one more snapshot to this auxiliary information. We don't have to update supplement information for all the old users. Similarly when there are n users added to the system this binary representation trick can be at most login log in trees. So you only have to store login snapshots of the tree at any time. We can also prove that the number of updates to supplement information for any user is also at most login. Lastly I would like to say that even though the previous constructions were using two level data structures as the main technique, this snapshot trick has been implicitly used even in other works. And now let's finally see how an authority can generate verifiable tp's. Consider this user with user added 22. Here's the current tree that is present with authority. As you can see user 22 is not registered in any leaf. And now the authority wants to give a proof that this user is not registered. Since the tree is sorted, the authority can just give a path to the leaf containing just before 22 and a path to a leaf of the user just about 22. So the proof contains two paths. This guy can verify that the two paths are adjacent to each other and that this user's identity is between the two paths and that's going to be his verifiable data. In reality, the oxygen information contains many trees. So the proof also contains the path for each and every tree. And now you can ask, what if the authority didn't form this tree correctly? And what if the authority and what if the leaves are not sorted? And suppose the authority actually inserted user 22 in some other position say in this last leaf instead of 36 we have 22. In that case, the authority can still generate a valid proof. This exact same proof works for example. And now, suppose Alice encrypted a message to the old man. Can the other to regroup the ciphertext? The answer is no. Remember, the ciphertext is a program that takes a path as input and verifies it. If you have 22 instead of 36, use the path to leave 22. Is it a valid path? It's not a valid path because 22 cannot be the right child of 31. If the authority tries to run the ciphertext program with this strong path, the program just outputs nothing. We prove this argument more formally in our paper that the authority cannot decrypt the ciphertext if form the public parameters mericiously. And now let's see how the authority gives tools for registered users. Bob has user ID 23 and here's a current tree with the authority. As you can see, user 23 is registered and now the authority wants to give a proof that Bob is uniquely registered, which means Bob is not registered twice. Since the tree started, the authority can just give a path to the leaf with user 23, a path just before this and a path just above user 23. And now the proof contains three paths. And this guy can verify that the three paths represent each other and his public key and identity is in the middle path. As again, the authority information contains many trees so Bob may present only in some trees and not in the other trees. For the trees in which Bob is present, the authority is going to give a proof that Bob is uniquely registered and for the trees in which Bob is not present, the authority is going to give a proof that Bob is not registered. And summing up, in this paper we introduce this new feature called individual verifiability for registration based encryption. This feature is required if you really want to ensure that the authority in the system is not current. In this paper, we also give a stronger notion of verifiability by adding some extractability properties to it. We also constructed this primitive from standard assumptions. We used the snapshot and trick and made our construction slightly simpler than previous constructions. It would be great if you can come up with some more practical constructions of this primitive, maybe by using some artwork techniques and it would also be good to see if we can apply the snapshot trick as well. Thank you for listening to the talk until the end and here's the ePin version of the paper.