 Welcome to your first last session today. So I'm happy to see so many of us together for separations. We have two talks on proving what we cannot prove in cryptography, and the first talk is on powers of hierarchical identity-based encryption, and it's a joint work with Mohammed Mahmoudi and Amir Mohammed, and Amir is going to give the talk. Okay. Thank you for your other introduction. My name is Amir Mohammed, and I'll be talking about limits on the power of hierarchical identity-based encryption. This is a joint work with my advisor, Mohammed Mahmoudi. So an important goal in cryptography that we'd like to study is what are the limitations of P that is what primitive P can or cannot give us, and what is the complexity of P? What are the assumptions that we need to assume or the primitives that suffice to give us primitive P? And in our work, we prove one such limitation for HIV-E, which is hierarchical identity-based encryption. Specifically, we show that HIV-E does not give us collision resistant hash functions in a black box way. And to our knowledge, this is the first limitation result regarding the black box use of HIV-E. And at first glance, this may seem like quite a... It's not immediately clear why we started such a question. And it might not be such a natural way to get collision resistant hash function. But the color is that we get from this assumption, from this result, are quite impactful. So HIV gives us implies primitives such as CCA2, public key encryption, and collision resistant hash function is also implied by other primitives, such as fully homomorph encryption and private information retrieval. And our result shows that anything on the left side does not imply anything on the right side in a black box way. And so the previous results that are related to ours is... First, we have Simon 98, which shows that one way permutations doesn't give us collision resistant hash functions. And then we have the work of Heitner, Hodge, Reingold and Segev, that show that trapdoor permutations doesn't give us collision resistant hash functions. And the final work, the recent one is by Ashraf and Segev, which show that IO plus one refunction doesn't give us collision resistant hash functions. We will rely on and extend the techniques of the first two results. And as for the last result, it is quite significant to us, because the result combined with Waters result, which shows that we can get functional encryption from IO, provides an alternative proof to a corollary of our main theorem, namely that identity-based encryption does not give us collision resistant hash function in a black box way, but it doesn't say anything about hierarchical identity-based encryption, which our work covers. And so the plan of this talk is I'm going to first define what is hierarchical identity-based encryption, and then I'll just say what are black box constructions, what are black box separations, and then I'll just talk about our main result and talk about the main ideas and how to prove this. So identity-based encryption was introduced by Shamir in 1984, and it's not until 17 years later that we had the first candidate construction from bilinear maps by Bonet and Franklin. And I'll describe how identity-based encryption works using this scenario. So let's say we have a company with a manager, and the manager has a massive secret key and a corresponding master public key. He would distribute and publish the massive public key to everyone. And suppose we have an external user, Alice, who wants to communicate with one of the company employees, Bob, and so she would use an identity-based encryption scheme to encrypt the message with respect to Bob's public identity, in this case it would be his name. And when Bob wants to decrypt this ciphertext, he would request a secret key from a manager, and the manager would give him a secret key specifically for this employee, for Bob, and so this allows Bob to decrypt the ciphertext and obtain the message. Note that there is different than normal public key encryption, and that Bob does not publish some kind of public key that allows Alice to encrypt. Alice only needs to know Bob's public identity, his name, his email address, whatever is public, and she would encrypt it with respect to that identity. And a natural extension of that would be hierarchical identity-based encryption, where we have a higher entity, a higher player. Say we have a CEO that now generates secret keys from managers, and that allows the managers to use these secret keys and generate secret keys for the employees that are under them, and they can only do that for the employees that are under them. And then Alice and Bob can communicate as before. So in defining the security of identity-based encryption, we have to consider the following scenarios. Suppose we have two employees who decide to collude with each other and combine their keys in an attempt to recover the message from a ciphertext that was intended to their colleagues, Dave. And when we define security, we should be able to say that even with such collusion, we should not be able to recover the message that was intended for another recipient. And more firmly, the security is defined using a security game between an adversary and a challenger for giving the master public key. The adversary can request secret keys for identities of his choice. This models collusion. And then once he does that, he can adaptively choose the idea that it wants to be challenged on. Then the challenger would send an encryption of a message, either zero or one, using the identity that was selected by the adversary and the adversary to win the game is supposed to guess which bit was challenged, which bit was encrypted. So now I'll talk about black box instructions and separations. So when trying to study the limitations of a primitive, we have to define the framework under which we explore this limitation. And the most widely used model is the fully black box construction model, because this captures most of the efficient and desirable crypto-primitives. And so here's how we'll define it. This was introduced by Imbagliaz-Rudich and later formalized by Rheingold, Trevisan and Vatan. So fully black box construction of primitive Q from primitive P consists of two oracle-efficient algorithms, Q and R. Q is an efficient implementation of primitive Q using primitive P as a black box. And for any adversary A that breaks primitive Q, we can create an efficient adversary R that uses A in a black box way to break the underlying primitive P. And it is easy to ascertain that such construction is relativized. This means that for any oracle, if P exists relative to this oracle, then Q would exist as well relative to this oracle. So one way of ruling out such a black box construction is to show an oracle relative to which P exists, but Q does not. And that is one way of how to show what we call a black box separation. So again, the black box separations, in the way we define black box separations usually and in our work, we're going to show two oracles, the P provider oracle, which facilitates the secure instantiation of primitive P and the Q breaker oracle, which allows us to break Q. And together we call this the separation oracle. And since this is a relativized oracle, a relativized world, we allow P and Q to call the separation oracle. We're going to use B, the Q breaker to break Q, and the P provider to instantiate a secure P. And we should make sure that when we add this Q breaker oracle, we wouldn't break P in the process. That's one of the things you have to make sure of. And so in our work, our P provider is a randomized HIV oracle, which I'll define later on. And we want to show that HIV exists relative to this oracle, but collision-resistant hash functions do not. And the collision-resistant hash function we will be using is what we call a SAM oracle, which I will talk about later. It's the same oracle that was defined by Simon to break the collision-resistant hash functions. So our task is two-fold. First, we're going to show that collision-resistant hash function can be broken relative to this oracle. And second, we have to show that HIV exists relative to this oracle even after we add the SAM oracle that breaks the collision-resistant hash functions. Okay, so here we go. So first, let's rule out collision-resistant hash function. We have an oracle called SAM, and our goal is to show a polyquery attacker that can break hash functions. So what does an adversary do? Adversary simply asks a query to SAM with the circuit of the hash function as input. And what does SAM do? SAM is an oracle that takes an output-compressing circuit and outputs a pair of colliding inputs where each input is uniformly distributed. This immediately gives us a way to break the hash function, and that simply breaks the hash function. So that's an easy way. That's the easy part. So the hard part is to show that whether the security of HIV is now compromised because we added such a very powerful oracle to our separation result. So normally, when we want to prove that something that primitive exists, we usually use techniques such as lazy evaluation, such as in the work of Implugliaz Rudich, but it will not work here because we need SAM to be dependent on this RHIB oracle. And here, since it does depend on it, we cannot use lazy evaluation. And so we need to use something else called the compression technique, which I will explain. And so next step is we have to show that... So now we ruled out collision-resistant hash function. Next step is to show that HIV exists, and we're going to do that using what we call a compression technique. And for simplicity of this talk, I'm only going to do it for IBE, our proof extends to hierarchical, but the main ideas will show up here as well. So in building an IBE from RHIB, the randomized IBE oracle, this is similar to the way that we get public encryption from random trap-to-permutation. Instead of having two permutations in the trap-to-permutation oracle, now we have three permutations. So we added this new permutation that allows us to generate keys for any given identity. So this provides an index into gen, and gen provides an index into encryption. So this allows us, for example, to implement the setup algorithm of the IBE by simply running setup on the master secret key and allows us to generate the keys using the key gen, using the middle layer, and allows us to encrypt and decrypt using the last layer. And this is how we build an IBE using this ideal oracle. Now what concerns us more is the security of IBE. And how can we improve the security of such a scheme? In particular, an adversary that has a master public key chooses an identity and then receives an encryption of a challenge that is supposed to invert the challenge and find x star. And it can do so by calling, using calls to our IBE, the randomized IBE oracle. And we proved that using compression technique. This compression technique was introduced by Janar and Travesan in the context of proving crypto-permitives. And at a high level, what this does is suppose we have a permutation that is represented this way, using some number of bits. And suppose you have an adversary that can break this permutation somehow. It could invert this permutation, like, for example, suppose that it could invert some number of points in the permutation. Now the compression technique says there are two algorithms. There is an encoder that depends on the adversary and outputs a compressed version of pi and a decoder that also depends on the adversary but reconstructs the original permutation. If we can show that such encoder and decoder exist, then we can show that only a few number of permutations are good for the adversary. And by good means, if an adversary could compress this permutation there are only a few number which it can invert, which it can break. And since there are only a few number of such permutations, we can say that random permutations are hard. Because when we draw them at random, there are only a few that are good for the adversary. And so if you want to demonstrate this using an abstract example for the case of random permutations, suppose you have a random permutation here where each point, each black point is a point in the permutation. And suppose we have an adversary that inverts these permutations, then we only need to explicitly represent these points because we could use A to recover to invert the other points. So look at how much we compressed this permutation. We now need only to represent a small number of points and we could use the adversary to invert the rest. So we compressed the permutation by a lot. And this shows that we can represent the permutation using a small number of bits. Therefore, only a small number of permutations are good for the adversary. And we can do the same thing for random chapter permutations. We could say that if an adversary that accepts a public key and a challenge, fpk of x star, and is supposed to invert the challenge and get x star, it can do so using one of two ways. It can either recover the secret key and using the secret key, it could then invert, it could do f inverse and find x star. That's one way to do it. But if it does that, it means that we could compress g. And this g is a random permutation that reduces to the case of inverting random permutations. The other case, it finds x star without finding sk, the secret key. That means without finding the secret key, it's just going to look at fpk x star and it covers x star somehow. But that means we can compress this permutation, the fpk permutation. And since fpk is a random permutation on its own, we can reduce this also to the case of inverting one way permutation. And now we have to make sure, recall that, we have to make sure that by adding Sam, we don't break anything. So the good thing is here that even if we give a, the Sam oracle, the powerful oracle, the work of Heidner et al. show that they can turn this adversary into another adversary, b, that makes slightly more queries, but the Sam oracle won't interfere with our compression technique. This means the Sam oracle won't be helpful in providing us with a way to break hiebe. We can still do the compression lemma and it will still work. So we can, that's what they show. And so we come to our original question, which is how can we show a compression technique for our oracle, this RIBE oracle? We want something that, we want something that is the same manner as what we did for random permutations and random trapdoor permutations. Specifically, we want to show that if an adversary can break this RIBE, then there are only a small number of oracles that it can do so. And if you would recall, the problem with IBE adaptive security or the issue here is that the adversary could issue inversion queries to the challenger. It could ask the challenger to supply him with secret keys of identities of his choice. And the second issue is that the adversary chooses the challenger identity. These two issues weren't present in the random permutation or trapdoor permutation games. And so this is the new issue that we handle here and we provide the new compression lemma that handles these two cases. So for the first issue, the adversary can ask inversion queries. So we can also think about this issue in the context of random permutations. That is, the adversary could also ask inverse queries to the permutation. So this new thing here is pi inverse. This is the new oracle that A has access to. So let's say that these are the points, the red points, that A could ask the inverse of. So we can't say anymore that these points are being inverted by A because A is asking the permutation to invert it forward. So we can't say that these are points on which A can invert. So we have to pull them out of the set of points that A could invert and explicitly represent them. So now we're going to pull out these red points from the set of points that A claims to be good at and we remove them and put them here so that we explicitly represent them because A is not good at them anymore. But we still show that even after doing that we can still do a good enough compression to show that A can only do well on a small number of oracles. And this is for random permutation. We could do the same thing for our case, for the RIB oracle, except here the adversary can ask inversion queries from the middle layer gen. And so we could say that if the adversary could ask inversion queries from this layer, then we could still be able to compress this and by compressing it there are only a small number of RIB oracles that the adversary could break. And for the second issue, the adversary is choosing the ID star. So this means that since it's choosing the ID star, we can't or we do not know of any way to compress this oracle if we allow gen, the middle layer, to be a permutation. However, we show a way to do though, we show a way to compress the oracle if gen is made to be an injective function instead with a very large output. If we allow it to do that, then we can show how to compress this oracle by a constant number of bits. However, a constant number of bits is not enough to show a good compression. I mean, even if we show a constant number of bits, a compression, the adversary will still be able to break the oracle with a constant number. The probability is not enough, so we have to show something better. So we use the fact that it can invert, that A could invert this function for an exponential number of master public keys, and therefore we have an exponential number of bits that we can compress. So the main idea here is that we change from using permutations to using trapdoor injective functions and that A could invert for an exponential number of master public keys. So putting things together, now we have an oracle SAM that breaks collision-resistant hash function. We have an oracle, our IBE, that gives us H-I-B-E, and we ruled out collision-resistant hash functions using SAM, and we proved that H-I-B-E exists using our enhanced compression limo, or enhanced means that we deal with adaptive adversaries as opposed to the normal random permutation game, and even if we include SAM, we can use the same techniques by Heitner et al to show that even with SAM, H-I-B-E is still secure, and the same techniques apply here. So the open question here is that we have... we're still looking for more applications of the compression amplification techniques that we developed here for adaptive adversaries, and, for example, here we're handling non-uniform proofs of security, and we'd like to discover alternative ways of getting this separation. For example, we have... we want something similar to what Asharov and Segev did by showing that... we want to show that IO doesn't give us adaptive H-I-B-E. Note that the recent result of Berkersky and Segev show that FE does not give... gives us semi-adaptive H-I-B-E. So if we get... if we have a result that shows that FE gives us fully adaptive H-I-B-E, then it extends our result. And finally, we want to see if there are any extensions to non-blackbox reductions similar to what Pass et al did for proving the... when we're permutating something, it does not give us collisions just hash functions in a blackbox way. Oh, yeah. Thank you. Some time for questions. I have a question. So the AS paper, that rules out non-blackbox reductions. Is that correct? Which one? The AS 15 paper that you mentioned at the end. Rules out non-blackbox? Non-blackbox constructions of collision resistant hash functions from... I don't believe so. Does it? But is it at the case that if you're using obfuscation, you have to assume that the... you have access to the code of the construction? Yes, but they do so with respect to I... I mean, the oracle that they use is I1, one-way function altogether in one box. Okay. So I don't think they... the oracle that they use, the separation oracle, allows it to use one-way functions in non-blackbox way, but it is in itself blackbox. So both impossibilities are also fully backwards? Okay. So let's thank Amir again.