 Oh, welcome everyone to TCS plus. And today's speaker is Sanjum Garg. So before we introduce the speaker, I would like to go around the table or dead. Do you want to go on the table and introduce the groups? Okay, I can try. I wasn't ready for that. Actually, I can do it. I'll do it. I'll do it. So we have, we have Bruce Capron from University of Victoria. Then we have Padima from EPFL. We can't see you. Then we have Clermont from joining us from Stanford. We have Irfan joining us from Indiana University, Bloomington. Then we have Fangi joining us from University of Michigan. Hello. Then we have the group from Caltech. Hello. Then we have Kay Gopala-Questionan joining us from East Carolina. We have Marius, Joseph joining us from City University of New York. And then we have Oksana joining us from BU. And we have Illya as well there. Then we have Said Mahmood joining us from Shahid Bahasti University. We have a group from Toronto. Hello. Okay. So today's speaker is, okay, I got a bunch of comments. Okay, no. Okay. So today's, and so as always, but helping us with the hang, helping me with the hangout is Oded Raghav, who's the moderator for the talk. And Thomas Vadek, G. Kamat, Clermont Kanon, and Illya Veselstein. And today's speaker is Sanjam Garg from Berkeley. Sanjam did his PhD from UCLA and has done fantastic amount of work in cryptography for which he won the ACM Doctoral Dissertation Award among many other honours. And today he's going to tell us about identity-based encryption from the Diffie-Hellman assumption. So Sanjam. Hi, everyone. Can you hear me? Well, I know it's online, but please feel free to interrupt me and ask questions. I would like it to be as interactive. I'm going to try to be high level initially at least so that it's broadly accessible. But please, if you have any questions, something is unclear, please do stop me. Okay. So today I'm talking about identity-based encryption from the Diffie-Hellman assumption, and this is based on a joint work with Nico Dauflin. So perhaps one of the most basic concepts in cryptography is encryption. And the most primitive form of encryption is, you probably all know it, but it's private key encryption. Let me just remind you guys and sort of fix the notation here as well. So what private key encryption allows you to do is it allows two parties, Alice and Bob, to be able to communicate securely in a setting where they both share a shared secret key key. So Alice and Bob somehow have this secret string key that both have access to. And Alice would like to send a message M privately to Bob. In this setting, what Alice can do is that she can encrypt her message using the shared key key and obtain a ciphertext, which she then pushes off to Bob. Bob could use the same shared key key to decrypt this provided ciphertext and obtain the message M back. And the security guarantees that an eavesdropper who just gets access to the ciphertext C that's being communicated does not learn anything about the underlying message M. So this is sort of a very powerful notion, but sort of the key challenge in this notion is that we need to have this shared key between the two parties Alice and Bob be done a priority to any of the communication. This changed with this notion of public key encryption sort of first studied in the late 70s. And the idea here is that Alice would like to be able to send a message privately to Bob, but she does not have access to a shared key with Bob. So in order to enable this, Alice needs to first obtain Bob's public key. So note that this is public. So anybody can obtain it. It can be sent over to the communication an insecure communication channel from by Bob to Alice. And Alice can then encrypt the message using this public key, generating the ciphertext, which is then delivered to Bob, who can use the secret key corresponding to his public key, which he alone has to decrypt this generated ciphertext and recover the message and back. So this is this revolutionized cryptography and had tremendous influence. Soon after the realization of public key encryption, I suggested this notion of identity based encryption, where the idea is that Alice, we want to do away with the need for Alice to obtain Bob's public key. In other words, we would like Alice to be able to encrypt a message and to Bob knowing just his identity. So for example, his email address, www.gmail.com. So the encryption process would no longer include obtaining Bob's public key and then doing the encryption, but doing it directly and giving the ciphertext to Bob. Of course, Bob needs to have access to some secret key to be able to decrypt, and this is done via a certification authority or what's called a private key generator, where Bob can submit his email address to the private key generator and get a secret key corresponding to his email address, which he can then use to decrypt the ciphertext generated by Alice. In addition to the identity of the recipe and this encryption procedure also depends on public parameters, which are sort of function or dependent on the certification authority or the private key generator. So one shortcoming of identity based encryption is in this case, the certification authority of the private key generator is sort of trusted. It's trusted to keep the secrets of the system hidden. So this is a disadvantage, but it does make key management much simpler, and this has been used in various settings in this one of the technologies behind voltage security, the company that sells some of the products that implement identity based encryption. So this is the model for identity based encryption. To formalize it a little bit more, identity based encryption is defined by a sequence of four algorithms. The first is sort of the setup algorithm S that takes the security parameters input and outputs a public parameters and a master secret key. So the public parameters are fixed for the system and master secret key is what the private key generator or the certification authority is going to keep locally and hidden from the rest of the world. Next, there is the key general algorithm K that takes the master secret key. So this algorithm K is going to be executed by the certification authority or the private key generator. It takes as input the master secret key and the identity of the person for which the secret key is being issued. Specifically, for example, it was Bob at gmail.com in the previous slide and it generates the secret key for that identity SK ID. That's what I didn't notice. And then the third algorithm is the encryption algorithm, which takes the public parameters, the identity, as was Bob at gmail.com in the previous slide and the message M that you want to encrypt and generates a cipher text C. And then finally, there's the decryption algorithm that takes the secret key for an identity ID and a cipher text also corresponding to the identity ID and recovers the message M. Note that here the decryption algorithm is taking a secret key and cipher text both corresponding to the ID ID. And the correctness of the scheme requires that if you were to follow these algorithms honestly and for an honestly generated cipher text, a secret key corresponding to the same identity should be able to decrypt and recover the original message M. So in this setting, the security property very informally says that an attacker who has access to secret keys of arbitrary polynomially many secret keys of his choice for identities of his choice should not be able to decrypt messages for identities for which it does not know the secret key. So this is an informal definition. Let me formalize it. But if there are any questions on the model or anything like that, I'm happy to answer now. Okay. So let me move on to the security definition. So just as in most security definitions in cryptography, the security for identity-based encryption is defined by a challenger adversary game. And the game proceeds as follows. The challenger first executes the setup algorithm, generates the public parameters and a master secret key. It provides the public parameters to the adversary. At this point, the adversary can ask for secret keys for identities of its choice. So for example, the adversary could provide an identity ID at which the challenger generates the secret key for the identity ID using the master secret key that it does have and gives back the secret key corresponding to ID ID back to the adversary. And the adversary could ask many such secret key queries. At this point, once the adversary has asked for some polynomial number of queries of his choice, it submits a special identity ID star with the requirement that ID star should not be equal to any of the identities that it has previously for which it has already received the secret key previously. At this point, the challenger flips a random bit P and provides an encryption of this random bit for the identity ID star back to the adversary. So now this is what I call the challenge ciphertext. Once the challenge ciphertext has been provided to the adversary, the adversary is again given the liberty to ask secret keys for more identities of its choice. Note that in this case, these new identities could be a function of the challenge ciphertext. And the adversary can ask arbitrary polynomial, additional polynomial many secret key queries for identities of his choice, again, respecting the constraint that ID should not be equal to ID prime. Finally, the adversary outputs a random bit, outputs a bit deep prime again in 01. And we say that the identity based encryption scheme is secure. If the probability that B is equal to B prime is negligibly larger than one half. In other words, the adversary has negligible probability of guessing what the encrypted message B was beyond the probability one half, which he can trivially do. If you have any questions on the security definition, please interrupt. Yes, so Clement asked the question, is there a bound on the number of IDs in terms of lambda? Yes, the number of IDs you can ask for, it should be at most some polynomial function. It could be an arbitrary polynomial, but it should be a polynomial function. And as you can see, that polynomial is going to be bounded by the running time of the adversary. Great question. Thanks for asking. Okay, so this is sort of the security definition. And as I said before, the security is, for example, in the setting that I talked before, if Bob at gmail.com was the identity that you were trying to attack, you could have obtained secret keys, or you being the adversary, an adversary could have obtained secret keys for arbitrary identities of its choice besides Bob at gmail.com. And it still would not be able to distinguish between encryption of zero and encryption of one when they're encrypted to Bob. So that's sort of the security definition for IBE. And even though this notion was sort of proposed a long time back by Shamir, the fundamental question of whether we can realize identity-based encryption had remained open for a long time. And this was answered positively in a breakthrough work by Boney and Franklin, where they showed that, yes, we can realize identity-based encryption. However, in realizing this, they needed stronger computational assumptions as we'll see in a bit. But before I move to what they did, I do want to quickly mention that subsequent to their work, there's been an immense blow up in the kind of encryption schemes that have been developed. One example that will be a little interested in the stock is for hierarchical identity-based encryption. And the idea here is that if you have a secret key for an identity ID, then you can use that secret key to obtain secret keys for any identity ID concatenated with ID prime for ID prime of your choice. So in other words, if let's say you have a secret, if Bob has a secret key for SK at bob.gmail.com, then Bob can use the secret key to obtain a secret key for bob.gmail.com concatenated with September 22, 2017, for example, a date that allows anybody who has access to this new secret key for the extended identity, bob.gmail.com with September 22 extended can decrypt emails that were sent on that particular date. Okay, so there have been many, many, many extensions for identity-based encryption. Really, there have been a huge blow up, but this is just I'm mentioning this one because we'll have some results to mention with respect. Okay, so subsequent to the breakthrough result by Bonnie and Franklin, so far we have many constructions for identity-based encryption and also hierarchical identity-based encryption, but sort of all these constructions sort of fall in three families of assumptions. The first being bilinear pairing-based assumptions, and this is where the first construction of Bonnie and Franklin fits in. The second family of constructions is from the lattice-based assumptions, in particular from learning with errors assumption, and then the third family of assumptions, which is actually much more restricted than the first two families, is in the quadratic residuality, from the quadratic residuality assumption, and here the constructions for ID are only known in the random oracle model. So if you don't know what the random oracle model is, just don't worry about in these contexts, then don't worry about it, just some limitation in which these schemes are known, and the known constructions without the random oracle model or no constructions for hype that were known prior to work from the quadratic residuality assumption. So this represents a big gap in terms of the assumptions that are known to be sufficient for realizing public key encryption, and the assumptions that are known to be sufficient for realizing identity-based encryption scheme. And sort of the big question has been, can we realize IDE from weaker assumptions or assumptions other than what you see on this slide? And the sort of two prime candidates to target would be parameter permutations. This is something that we would know, we know how to construct a public key encryption form, or even CCA secure public key encryption from, or the decisional defi-helman assumption, which sort of gives one of the first candidates for public key encryption from the El Gamal scheme or using the ideas of defi-helman. So the evidence for this direction towards facing IDE on these weaker assumptions has largely been negative. In particular, Bonnet at all showed that a trapdoor permutations, if used in a black box way, are actually insufficient for realizing identity-based encryption. Additionally, a subsequent work by Papak Estentinos shows that even if you were to use the decisional defi-helman assumption, as long as you're restricted to using the group elements in a black box way, still realizing identity-based encryption turns out to be impossible. So very roughly, you know, our understanding of crypto sort of reflects that as we go to realizing sort of more powerful encryption primitives, stronger computational assumptions are inherently needed. So for example, our sort of understanding is that if you want to realize public key crypto, that requires stronger assumptions than private key crypto. So in particular, we know that one-way functions suffice for realizing private key crypto primitives. But for realizing public key crypto, we need trapdoor functions. So these are one-way functions which have additional trapdoor ability that allow you to invert if you have the trap. Analogously, there's sort of a perception or a very strong, there was a perception or a very strongly held belief that identity-based encryption requires stronger assumptions than what are sufficient for public key crypto. Or in other words, we need one-way functions which have not just one trapdoor, but sort of exponentially many trappers. So sort of these trapper functions where you can generate identity-specific trappers. So since you're going to have a very large number of identities, you would like to have a separate trapdoor sort of a thing for each identity. And sort of the perception was that we need this such additional structure for realizing identity-based encryption. What our result does is it shows we can reduce this gap. So in particular, our main result is that we can realize identity-based encryption from the computational Diffie-Helman assumption. So this assumption is weaker than the Diffie-Helman assumption that I previously said impossibility results are known from. And we're able to circumvent those impossibility results using non-blackbox techniques as those results were for the blackbox setting. Okay. Additionally, this also yields results directly based on the factoring assumption. So in particular, this gives identity-based encryption from all or sort of both the prime candidates on which a public key encryption was first paid. Subsequent to this work, we've also obtained construction for identity-based encryption. Others and us have obtained constructions based on learning with parity assumption and so on. So the gap is further reducing here. Additionally, I want to note that these techniques also give a selectively secure hype scheme. And selective security is a weaker notion of the security notion that I previously defined. I'm not going to talk about the security notion, so I'm not defining it. One point I want to mention here is that this result is actually generic. So what it does is if you give me any identity-based encryption scheme, it gives a generic construction of a selectively secure hierarchical identity-based encryption scheme using that IDE scheme. Note that this construction is generic, but non-blackbox. So it can still circumvent the previously known blackbox separation results. Okay. So as I mentioned before, these results avoid the impossibility using non-blackbox techniques. If there are any questions on the results or the related works that I've mentioned, I'll be happy to answer it. Yeah, I've got a small question. When you say you can get a HIV from any IDE scheme, you get selectively secure HIV from any fully secure? Or what is the security thing in the relationship? So you get from any starting with any selectively secure IDE scheme, you get any selectively secure HYBE scheme. So it's from selective security for IDE yielding selective security for HYBE. There's also a generic result now using the same technique that actually shows that selective and fully secure IDE are equivalent. Again, that's a non-blackbox construction. So that's a separate result. So there's no difference now between selectively secure IDE and fully secure IDE as far as feasibility results are concerned. Great question. Thanks. Okay. So if there are any more questions, please interrupt. I'll move on to the next slide in the meantime. Okay. So let me now move on to the technical part of the talk where I sort of want to convey two key aspects. So one is what is the challenge in what has been the challenge in realizing identity-based encryption? Why did we think it was impossible or hard to realize from assumptions like the decision of the fjallman assumption? And what is the key new technique that allows us to break that barrier? Okay. So in order to convey the main idea, I want to sort of start with a toy example, which captures the key challenge that comes up when we're trying to realize identity-based encryption. And sort of as very cleanly explained with a very simple setting, so where we have two parties, Alice and Bob, they have their public keys PK0 and PK1, PK0 being the public key of Alice and PK1 being the public key of Bob. And let me just restate again that this is a toy example that I'm considering in order to highlight the technical difficulty that arises in realizing identity-based encryption. And in this setting, I'm only talking about two participants, Alice and Bob. And in the general setting of identity-based encryption, you could have potentially exponentially many different players, but here I'm looking at just two players. And what I want to do is that I want to somehow so compress the two public keys into some small public parameters. So let's say each of the public keys was let's say lambda bits that I want to and the two public keys are going to be two lambda bits. I want to somehow compress these two public keys into public parameters that are just lambda bits. So Pp, I want them P to be lambda bits. And I want Kara to be able to encrypt the message to either Alice or Bob knowing just these public parameters. So Kara would like to be able to encrypt, doesn't know the the the public key of Alice or the public key of Bob, but knows just a succinct version of the two public keys, which is Pp, and would like to be able to encrypt the message M, knowing just the Pp, and you know, when I say it would like to encrypt, it doesn't know whether it wants to encrypt to Alice or it wants to encrypt to Bob. And once the psychotext C is generated, I know that I'm going to use this the end subscript two procedure to describe this sort of compressing encryption for two public keys here. The psychotext can be generated with this. And what I want is that if let's say B was zero, then I want Alice to be able to decrypt the message that's encrypted in this way, using the two public keys PK zero and PK one, and the secret key corresponding PK zero, that is SK zero. So in other words, the encryptor, so think of the encryptor as as as as wanting as having two of the two friends, Alice and Bob, Kara has two friends, and they and they have public keys PK zero and PK one. Kara wants to go on a vacation, and she wants to somehow compress the two public keys of its two friends into short parameters Pp, such that on a vacation, while on vacation, Kara can send encrypted messages to either one of them that all either only one of them can can read. While they can decrypt using the knowledge of the two public keys and the secret key. So note that here, I'm allowing the size of the psychotext to be large or in the if Alice wants to decrypt, it's okay for Alice to know Bob's public key as well. So this is the toy setting I'm going to consider any questions on this. So one subtle point here is that I'm trying to compress arbitrary public key so PK zero, PK one do not need to be correlated in any way. So what this means that the public parameters are going to information theoretically lose information about PK zero or PK one or both, right so information theoretically Pp Pp cannot contain information about both PK zero and PK one. So this might sound counterintuitive how is it possible how I'm going to be able to compress to completely independently chosen public keys into small public parameters, such that I can encrypt to either one of them. And this is sort of the key challenge or that has existed in realizing ID scheme. And this very problem was part of the intuition why it was thought of as impossible and this sort of intuition also sort of the impossibility results also built on this very intuition. Just as a side note how did known schemes they did use stronger assumptions but how did they circumvent this issue? Well they circumvented this issue by generating PK zero and PK one in a correlated fashion. So since PK zero and PK one were correlated, you could somehow compress them without losing any information about PK zero or PK one. So that way this sort of challenge did not arise when we were working with more structured assumptions but the this sort of correlated public keys could have only been generated by when we were using these more structured assumptions. And as I mentioned before impossibility results with sort of more unstructured assumptions followed the same intuition that well you will not be able to information theoretically you will not be able to compress two public keys into small public parameters because that's going to inherently lose information and making it hard for then subsequently encrypting. But as our goal is going to be to compress completely uncorrelated keys even though it might sound hard this is the sort of is the key challenge that we need to overcome in realizing identity-based encryption from the any question so far. Okay so then let me move on. So in order to explain our construction our construction sort of relies on two key ingredients or tools. One of them is new which is hashed with encryption and the second one is old which is Gauss-Garble circuit. So a mixture of old and new. Let me describe these two tools and then we'll see how we can implement that simple toy example using using these two tools and that will give you an idea of how we can overcome this barrier. So hashed with encryption is a sort of a very simple tool but the algorithms require a little care so you know if you if something is unclear as I go over this slide then please stop me it's just the definition is one slide and is just three algorithms it's very simple but it can be confusing so please stop me if something is unclear. So hashed with encryption is basically a hash function that comes associated with some additional encryption decryption functionality so I call that's why I call it hashed with encryption. It comes with three algorithms a hash function an encryption algorithm and a decryption algorithm. It's a keyed hash function but I'm going to suppress the key from the slide to keep things simple. What the hash algorithm does it takes a value x which is let's say two bit two lambda bits long and compresses it into lambda bits or for hash which is h. Security requires that it's hard to compute x and x prime such that hash effect is equal to hash of x prime so this is the typical requirement for a collision resistant hash function. Now comes the trivial part which is encryption and decryption functionality so the encryption functionality takes a message m that you want to encrypt as input so here's a message m and it takes three parameters h i b okay so what are these three let me just define the domain of these three parameters and what role they play will become sort of clear when I describe the decryption functionality so h is a value in the range of the hash function so think of computing h of x and h so h is one such value i is an index from one to two lambda which is recall that two lambda was the length of the free images and it's an index in from from one to two lambda and b is just a bit zero one um note that when I'm generating the ciphertext here the the ciphertext only tries to hide the the message m there no security properties for it's not trying to hide h i b so you can think of ciphertext c as containing h i b in the clear okay the ciphertext c takes as x as input and x is going to serve as the decryption secret key and it recovers the original encrypted message m if these two constraints are satisfied the two constraints might be tricky so pay careful attention to them decryption succeeds if you have h of x is equal to h if the the value x that you can provide a decryption time is such that it hashesh to the value h that was used at encryption time and the the the the the pre-image x that you're providing is such that the ith bit for the pre-image is b okay so in other words decryption succeeds if you can provide a pre-image for h such that the ith bit of the pre-image you can provide is b okay so this might sound like a sort of unnatural a encryption decryption functionality but as we'll see when paired with garble circuit this is this is immensely powerful so what are the the what is the security property that's desired here the security property is the very the sort of the most natural that you can imagine if if i give you x a pre-image and you encrypt with respect to the hash of x for an index i with one minus x i then the encryption of zero and one are computationally indistinguishable okay in other words in this case you have a pre-image x for for h which is x but the ith bit of x is is is the opposite of of the value b that has been used at encryption time so therefore you can't decrypt these two side a side protects this that's generated in this way and and we want semantic security in this case any questions on this security notion so this is sort of a the sort of one of the key tools in realizations if you have any questions please do ask now okay so it seems that so if you're familiar with the notions of witness encryption and laconic OT this this is reminiscent of those motions as in in the sense that h id if you're not familiar then don't worry i'm just providing context for those who might be familiar with the the concept of witness encryption the idea here is that h id sort of defines the language the the instance in the language that you're encrypting to and x serves as a witness and and and a valid witness is sort of is one where it is a pre-image but has the additional property of the ith bit of the pre-image that you're providing is is bit p okay okay so the construction for hash with encryption also turns out to be actually extremely simple it just fits on one slide just like the definition so let me describe it the the hash parameters the sort of the the public parameters for the hash function are going to be two n random group elements so think of a cyclic group g with primordial p and i'm going to sample two n random group elements the hash of a value x which is a end bit long but think of n is it's two lambda from the previous slide is just the product of ai xi so if if the first bit of x is zero you you you pick a one zero if the second bit of x is one you pick a to one and so on and you multiply all those terms and that gives you the hash which is going to be one group element okay now let me describe the encryption and decryption procedures the ones that i've written here um the correctness is okay but in terms of of of security there is a bug so i'm going to describe how how these two algorithms work and try to see if you can catch the bug and and and that will give you an intuition of how these two how how how the the scheme will will work so for the encryption functionality i take h as input i b as input and the message m and and i just generate the size to take c as take off i pick a random uh element s in in z p star uh recall p was the the order of the the group that we're looking at uh and and and i exponentiate all the public parameters for the hash function by this parameter s i also have h to the s ix or h to the s with the message m that i'm trying to encrypt and decryption will proceed by just computing h to the s as the product of uh uh you know just by computing the hash function but instead of using the public parameters i'm using the public parameters exponentiated with s so note that this will yield h to the s precisely because it is uh each public parameter has been exponentiated individually with s here and i'm multiplying them okay uh and once you have h to the s you could sort of seek to recover m from the second part of the the ciphertext okay can you see the bug here in terms of security so hint note that in this case in encryption i didn't use i and b so in other words if i'm not using i and b then uh regardless of what pre-image is available i can always decrypt okay how am i going to fix it the idea is very simple um i'm just going to for the index i i'm going to get rid of one of the um two values here okay so in other words if your pre-image is such uh that it requires you to to compute h to the s you need to use uh the the the the the specific term a i one minus b s then it will not be available okay so this would allow you to decrypt as long as the pre-image you have has the ith bit matching this b but if it does not match then you cannot compute it uh and then you will not be able to decrypt so even though you know it might i've just given the intuition of how the scheme works you can actually base the security of this very very simple scheme that i just described on the decisional diffy helman assumption that you can give us proof of security for this this very scheme as such okay and and using hardcore bits if you're familiar with it you can also base it on the computational diffy helman assumption okay so this uh uh uh this finishes the description of the this new tool hashed with encryption are there any questions about this okay so the next tool that i'm going to use is yaw's garble circuit um and and and just describing very uh abstractly um what garble circuits allow you to do is that if you they come with two algorithms garble and eval garble takes a circuit c as input and outputs a garble circuit c tilde along with a pair of input labels so a pair of input labels per input wire of the circuit c uh and and and so if the circuit c takes n bits as input then you'll get two n labels one pair uh per input wire and and what the eval operation does is it takes the garble circuit as input and one uh uh uh uh label in every pair for each input wire and and yield c of x so in particular if you give me label i label i zero for each i then i can compute the circuit c on the input zero string okay so this is uh what garble circuits are and correctness is that if i give you a garble circuit along with correctly generated labels it yields the output c of x um uh uh correctly computed c of x and the security requirement says that given c tilde and one input label among every pair for uh each of the input wires um this this does not yield any more information than the output of the the circuit on the center okay and and this is formalized by saying that there exists a simulator that generates the same distribution as in c tilde and one label per each input wire given just the output cx okay so in other words this garble circuit does not leak anything about the circuit uh that that that's being garbled okay so this is the second tool that we're going to use um now coming back to the toy problem we wanted to compress two public keys pk0 pk1 into short parameters pp um and and how we're going to do that we're going to use our hash with encryption tool recall that it provides a hash function we're simply going to use a hash function the the hash function that hash with encryption provides to compress the two public keys pk0 pk1 the concatenation of the two public keys um into pp and note that the hash function that we constructed was from two lambda bits to lambda bits so this is the this conforms with the the requirements that we had set okay how do we encrypt and and and and this was the the key question um in in in sort of we wanted to encrypt knowing just these public parameters before i describe the how i'm going to use so this this process of encryption is going to be done via um uh the encryption functionality this hash function provides and garbled circuit okay so i'm going to use so as i mentioned before there are two tools here hash with encryption and garbled circuits that i'm trying to use i haven't so far used the encryption functionality this hash function provides and garbled circuit those are the two tools that i'm going to use to generate these um uh cipher text using encryption too but before i do that i want to give some intuition of how it's going to work and the intuition sort of comes um a why i sort of an authorization perspective and the idea is if i give you the the the cipher text uh could be seen it would suffice to provide an authorization of this specific program let's see what this program is so a program has a public parameters pp so kara could uh generate the cipher text as the obfuscation of this program where the program has the public parameters pp the bit b that represents whether it's alice or bob to to whom he's encrypting and the message n that he's encrypting this program takes x as input it aborts if public parameters is not equal to it hash of x okay so the first thing this program does it checks if the public parameter matches the hash of x the input is quite it if it does match then if v is equal to zero then it sets pk to be the first lambda bits of x that is the note that x has to be pk zero concatenate with pk one and and and if v zero pk will be set to pk zero and if b is equal to one then pk will be set to pk one and then this program outputs pk encryption of m using the public pk so if i was to somehow give you an obfuscation of this program then it would suffice because you could it the if you're alice and and i had encrypted to you you could basically run this program on the input pk zero concatenated with pk one and you will get an encryption under pk zero of the message m which could then decrypt using your security so just giving you an obfuscation of this program suffices and that sort of gives you some intuition on how we're going to perhaps achieve this stuff okay but we don't want to do it via obfuscation obfuscation requires much stronger computational assumptions and and and sort of the key idea is to sort of implement um sort of an obfuscation of this program using the encryption functionality that the hash function provides that we previously constructed and garbled circuits okay so let's see how that is done in particular what i'm going to do is the encryption pp b comma m is going to construct a circuit c of m so circuit c has the message m hardwired in it and it takes pk as input and outputs encryption of pk comma m so when we think of encryption we think of the public key as as fixed but the message as as something that's changing here i'm defining the circuit c as one where the message is hardwired inside the circuit and the public key is uh is is what's given as input to the circuit okay and it outputs encryption of pk comma m next i'm going to garble the circuit i garble the circuit c of m getting settled along with uh one pair of input labels for each input wire and and note here that the circuit c of m takes a public key's input pk which is lambda bits so i get two uh lambda uh labels or lambda pairs of labels for the lambda input wires that the circuit c takes as input okay next what i'm going to do is for every uh index i um in in b lambda plus one to b lambda plus lambda so this is just uh an alternate way of saying that if b is zero then for i equal to one to lambda so if if i if b is zero i'm looking at the first lambda bits of i'm interested in the first lambda of the pre image of pp if b is uh is one then i'm interested in the the last lambda bits of the pre image of pp i encrypt the the labels uh uh uh for each gamma in zero comma one i encrypt ci gamma using the encryption method that came encryption scheme that came with the hash with encryption scheme so recall that hash with encryption scheme took as input the hash which is public parameters in this case index i and a bit b or gamma in this case and encrypts the label i gamma um under these parameters to generate ci gamma for each i and gamma and the bit b that's whether you're encrypting to alice or or or bob uh affects whether the index i here goes from um a uh uh one to lambda or lambda plus one to two lambda okay and and ciphertext is going to be c tilde with ci gamma okay so this uh sort of this encryption um e encrypt to encryption method gives a garble circuit along with encryption of the input labels and it's the the goal of this in to why this garble circuit encryption of the labels is to mimic the obfuscation sort of that i presented in the the previous on the previous slide um and and and and that's how decryption will proceed so decryption would proceed by um decrypting the input labels uh uh is so depending on whether alice um is is the one who i'm encrypting to or bob i would be able to decrypt for each input wire the labels corresponding to uh the pk zero or pk one so in particular if the encryption was done to alice then uh uh the the label one zero would be encrypted to to a gamma here would be uh this is going to be zero and the encryption would be done to the first bit of the pre-image uh of public parameters in other words i can decrypt c one p gamma one is the first bit of uh uh the the party to which it's encrypted so if it's alice it's the first bit of pk zero okay so i would be able to decrypt one of the two ciphertext in particular c one pk gamma one yielding label uh one pk gamma one in other words i'll be able to get the the labels for the the garble circuit corresponding to the public key of the of alice if the encryption is being done to alice and the labels for bob if the encryption is being done for bob and the garble circuit then just spits out an encryption under that public key which you could then decrypt um using the secret key okay doesn't make sense if there are any questions um please us so remember this intuition here that we're trying to give an obfuscation which we're trying to give an obfuscation which takes the public key as input and and outputs an encryption of the message under that public so since the public parameters do not contain information theoretically the information about the public key therefore we're going to give an obfuscation where the input itself will contain the information and and and we'll do the check that you give it the right public key and then the obfuscation spits out an encryption of the message under the right public okay and this is is done using garble circuit and the hash with encryption and the property for hash with encryption that you can decrypt one of the two input labels for a pre-image that you have allows us to to make it happen okay okay so this explains how you know we can use garble circuits and um hash with encryption to implement this functionality the question the next question is can we extend these techniques to um to compress exponentially many keys uh you know identity based encryption doesn't require the ability to compress sort of two public keys or given the ability to give secret keys for two identities requires the ability to give secret keys for exponentially many identity or potentially exponentially many identities and the idea for doing that is to just use merkle free um of course you know we cannot generate an exponential size uh uh uh uh uh merkle tree but we need to somehow uh represent a an exponential size merkle free succinctly so that we can generate any root to leave part in it quickly without having to um a without having to to sort of first generate the tree and um and and then sort of give out the public parameters um this is done via it's changing the um hash encryption algorithm that I I previously stated a little bit um I won't have a have time to I want to talk about the the related work as well so I don't have time to discuss about this extension but I'll refer you to the paper for um for this so quickly jumping on to the open problems and other related work um and that that has happened beyond that so one interesting question that there are techniques raised is that well we couldn't do identity based encryption from um the computational the fielman assumption or the factoring assumption and also learning uh from the lpn assumption now um this raises the question what can we do it generically from any public key encryption so this is uh this is this is a very interesting question and and and since identity based encryption generically implies cc secure uh encryption um solving this question would also give a positive answer to another very interesting uh an important open problem of doing public cc secure public encryption from uh a cps secure public encryption which is also open on the flip side um our work sort of uses non-blackbox techniques to realize um uh identity based encryption from the the the the decision of the fielman assumption and it's interesting to ask if similar uh if if if similar techniques have inherent barrier in in answering this question so is it act it is it impossible to realize identity based encryption from public encryption even then use of non-blackbox techniques is a lot so sort of the question on both side this is interesting and open and and we have sort of no uh progress on that another very uh interesting and important question is can we realize attribute based encryption for more general families based on weaker assumptions so uh uh going beyond IV or hierarchical IV um basically just two assumptions specifically based on bilinear maps or uh lattices that give you um a more powerful uh attribute based encryption scheme and if you want to look at attribute based encryption scheme for all circuits the only construction is from lattices so there's this sort of very interesting question of diversifying the assumptions and and and um if if these techniques um or other new non-blackbox techniques can help in realizing uh these schemes based on on on weaker assumptions finally i want to mention that the the uh these techniques um uh sort of looking at um a a a sort of standard or well-studied cryptographic primitive from a from a from the lens of office station um and sort of trying to to realize office station via you know sort of tailored special purpose office station scheme to to to achieve um results and improve assumptions in in settings uh which might have previously been considered hard there have been many applications of this technique um specifically for example in the context of uh laconic OT been used in the context of adaptive garbled circuits um also been used in the context of realizing to run secure multi-party computation so all these results have a have a similarity that they use just like hash encryption were were was paired with garbled circuits um you might have hash encryption or a different office station like or written encryption like primitive that you pair with garbled circuit to get some wheat form of office station that that that uh strength that weakens the assumptions that are needed for these applications um and an interesting question is can we find more applications which can benefit from this uh office station lens approach to sort of fundamental tasks in cryptography um so that's all i have in the questions yes so the question uh asked is is it fair to say that while this construction is theoretical interest the resulting IV is not practically practical for actual use yes uh this is absolutely correct um the construction is is going to be uh significantly uh uh you know it's it's very it's going to be far more inefficient um uh than than the other schemes based on bilinear maps and if you if you're trying to use it uh it's better to use those those constructions uh uh yes so there are any more questions i'm happy to answer uh one question sundrum so going back to the previous slide um can you explain what you meant in the first bullet how exactly would such a uh construction look like given that there's already backbook separation so what exactly you're okay so um the black box separation results only rule out um a a a black box uses of pk e so you could have a garble circuit um uh that that actually has the pk e algorithm embedded in it uh and somehow you know uses that uh that uh uh you know the pk e algorithm you could have a garble circuit with pk e encryption gates hardwired in it right so that you could have gates encryption gates inside the garble circuit and and the garble circuit could output a cypher text and depending on what cypher text you decrypt you could have another garble circuit that you could could could could uh encrypt and um this is not a completely hypothetical strategy in particular if you look at the construction of uh indistinguishability obfuscation from um from functional encryption those are much more powerful full objects but we know a general construction of indistinguishability obfuscation from functional encryption due to um a a a a a a an an an an an an an an an an an an an an an uh betanski and betanski that sort of uses a similar strategy where you have an encrypt functional encryption scheme where the the secret key is it has uh has functions which have encryption gates in them so you could think of garble circuits with similar structures to it does that answer your question thanks but let me actually add here that starting the same problem from a negative perspective is interesting for ibe but we do not know impossibilities even for pk e so um this is something that in a recent work we've to some extent partially answered that even if you use a one-way functions and garble circuits can you get pk e from it uh in a non-black proxy impogliate as a rudic does not answer that question and um we have made some progress in answering that um and saying that if you have garble circuits with one-way function gates in them that would that's still insufficient for realizing uh public key encryption but whether these techniques and the impossibility results extend to to ibe and public key encryption or uh uh or you can realize ibe from from public key encryption remains an open problem um i have a question to jump yes uh so we read your paper in our reading group and it's a great paper but can you go back to where you're compressing the two keys and show how's that attached to the identity so basically um i don't know you know mpk one right i only know your identity so they're like a v which is the identity yeah so i i think i understand your questions yeah so the identity is the uh the root to leaf part so if your identity is let's say in the two case is is uh uh there are only two players one with identity zero the other one with identity one then the left child is the one with the identity zero and the right child is the one with identity one to look at larger identity strings you you'll have a merkle three of large size and the root to leaf part in that tree will be the identity right sorry um so yeah so but we were running out maybe i'll send you an email offline we were running a hard time finding where that is so basically this hash this pk zero and pk one in your merkle three will have a prefix okay so okay so what happens in so if if you look at the the mechanism if you think from the obfuscation sort of mechanism the first in the merkle three you're going to use that many times that mechanism going to be used repeatedly and the first the encryptor has access to only the hash now what that does is depending on whether the first bit of the identity is zero or one i'm going to generate think of the the the root of the the tree uh the subtree rooted at the left child the root helps read you know you can use the same if i can somehow go from the root to the left child i can use the same mechanism to go down uh so going from the root to the left or the right child is a function of just the first bit of the identity and and i can do that uh and and subsequent i will use the subsequent bits of the identity in going further down so if you look at the scheme uh in the scheme the encryption procedure uses these garble circuits uh and and and um if you look at this um the garble circuit that that get executed takes only lambda bits as input it's either the left child or the right child and whether it's the left child or the right child is a function of the identity does make sense yeah okay uh if okay we were stuck during the reading group we were stuck on the specific point but if i i'll go back to it now with your explanation and i'll send you an email yeah happy to answer yeah yeah we reverted the open problem and being is really the construction of the chameleon encryption yeah where you're where you're using that the fielman right yes yeah so as long as you have chameleon encryption from any pke say then you would have yes right right so in fact uh we know now that if you work with hash encryption as so even though in the paper ibe paper that the crypto paper um uses things from chameleon encryption it does give a simpler scheme the the scheme is is simpler uh but there's an alternative construction if you just gave hash encryption that also we now know is sufficient for realizing identity based encryption so in other words you don't need the chameleon property in the hash encryption the hash encryption that i just defined is sufficient okay um and the the caveat is that hash encryption does imply hash function so uh you know public key encryption does not and so it seems a rather a hard problem to do it at the same time uh i i should mention that the the if you start with identity based encryption uh you don't an alternative to sort of bootstrapping on these techniques is to not start with with hash encryption but start with a selectively secure identity based encryption so this is the way how we go from any ibe to a hide scheme or any selectively secure ibe to a fully secure ibe um and that does not imply hash functions so that you know the the the hash encryption and you know does imply ibe but it's sort of um weaker ibe sort of weaker than hash encryption in an alternate sense so it's possible that you know it may not really be a hash function it might be something else that might help realize something similar that might go to okay thanks yeah my pleasure do we have any more questions well if not then uh let me take the hangout offline and you're welcome to stay here and ask more questions so we uh before i conclude uh before we conclude uh one thing is that we don't have a talk as of now scheduled for next venus for venus day two venus day two now but stay tuned we'll we are working on it so hopefully uh something will be arranged but otherwise uh thank you sanjum let's i'll just take this offline now