 Hi, everyone. My name is Amir. I'll be talking about lower bounds and obfuscation from all or nothing encryption And I'll define what it means to have all nothing encryption later during the talk This is joint work with Sanjom Garg and Mohamed Mahmoudi So let's define again what an distinguishability obfuscation is or IO It was first proposed by Barack Attala in 2001 And basically says that it's an algorithm that takes as input a circuit And outputs a functionally equivalent circuit And for security we say that for any two functionally equivalent circuits of the same size An adversary shouldn't be able to distinguish between the obfuscation of one or the other And following the first candidate construction of Garg Attala in 2013 IO has shown to be a quite powerful force allowing many applications to be built upon it Including functional encryption, two-round multi-party computation And even proving the hardness of complexity results And there are many more applications following that So given the usefulness of IO, one natural question to ask is what assumptions could give us IO And to answer this question, so we have two main ways to get IO at the moment that we know of The first being from multilinear maps And this was initiated by Garg Attala in 2013 And a series of works have followed this approach Showing either an improved constructions or weakened assumptions And the alternative way to get to IO is through some form of functional encryption From which all constructions of this kind of functional encryption also are built All known constructions also are built using the multilinear maps as well And as you've seen from the previous talk by Rachel The state of the art of constructing IO from functional encryption Happens to be based on trial linear maps and PRGs with some spatial properties And their construction is not black box However, due to certain attacks against the instantiated multilinear maps We are having now less confidence in the security of the known constructions of IO And so this motivates us to ask whether there can be any other alternative Preferably standard assumptions that could give us IO instead of using the more exotic multilinear maps assumptions And to answer this question, a series of works have shown that none of these primitives give us IO in a black box way This includes collision resistant hash functions, trapdoor permutations And even the generic group model, anything that is hard and generic group model cannot give us IO in a black box way But this still leaves the possibility of whether there are more sophisticated primitives or perhaps stronger assumptions that could give us IO And in this work we extend this line of research by showing that under mild assumptions Where mild assumptions that we make is basically that when we function exist and that the hierarchy does not collapse That there is no black box construction of IO from any of these primitives And the kind of non-black box techniques that we rule out are especially relevant in this context when we deal with these kind of primitives And this is where the title of the talk becomes relevant is that all of these primitives are of all or nothing nature Meaning that if you have the decryption key then you could decrypt the ciphertext and get back the entire plaintext Otherwise if you don't have the decryption key you learn nothing And so the plan for the rest of the talk is that first I will describe the black box model and our proposed monolithic model Which captures the non-black box techniques that may be used to construct IO from the primitives that we will separate it from And the second part of the talk is I will describe the high level ideas behind our separation results And leverage the all or nothing property of the primitives that I mentioned before So let's go over the first part here So in the classical black box framework of Impluglizer-Rüdisch and the Reingold-Trebisand-Vatan Black box construction of IO from P basically means that IO uses P in a black box way It only uses the input-output behavior of P And this is natural when P happens to be the one-way function of the trapdoor permutation However this is not the case when we deal with more sophisticated primitives or non-black box techniques For example one common non-black box technique involves doing some form of computation or work that could have circuits with one-way function gates inside them This behavior is observed for example in the case where we could have zero-knowledge proof over circuits with one-way function calls In order to realize identification schemes Another example which is relevant to this session is IO over circuits with one-way function calls could result in many applications Some of which are represented in the Sahay and Waters paper So there are also previous works that tried to prove limits of this kind of technique This technique where a construction queue is based on a construction P that accepts circuits with one-way function gates And here are just some of the works that prove limitations of this kind of technique starting with the work of Berkersky, Katz, Segev and Yurikimovich Where they show that key agreement protocols cannot be based in a black box way from witness indistinguishable proofs for statement with one-way function gates Also to show the limits of IO, Segev shows that you cannot get collision resistant hash functions or one-way permutations from IO for circuits with one-way function gates And as you will see in the next talk, the work by Berkersky et al. they will show that IO for oracle-aided circuits that could have one-way function gates inside them Do not imply structured hard problems in say NP-intersect code But what about the FE to IO construction due to Anantrgyn and Bitansky-Vaykuntinov? Does this construction fall under the model where the IO uses the underlying FE by providing it with circuits that could have one-way function gates inside them? Well, no, that's not the case If you look back to the construction, the IO actually feeds the key generation function of FE, a circuit that contains encryption gates of the FE So in some way, you can think of FE as being used in a self-eating way FE subroutines are being fed back to FE And this is different from the functional FE for circuits with one-way function gates This does not fit the previous models And this is not an uncommon behavior There are other examples that do not fall under the circuit with one-way function gates model For example, one famous example is the FE bootstrapping by Gentry Where we have to feed the decryption algorithm back to the evaluation algorithm And this is also another behavior of what we call self-eating Also, you have the IO bootstrapping due to Gargatal in 2013 Where to show that in order to get IO for poly-sized circuits, you need to feed the evaluation and decryption of FE back to some IO for a smaller class of circuits So these two also do not fall under the circuits with one-way function gates model So inspired by this previous model that showed how to prove the limitations for circuits with one-way function gates model We extend this framework and propose our own model called the monolithic model Where we say we have a monolithic construction of IO from some primitive P If this primitive P can accept circuits with any arbitrary P gates That is including P1 or P gates And it is not constrained to only a specific type of gates such as a one-way function gate And this for example captures the FE to IO construction It captures the bootstrapping theorems And this is where we are going to use this monolithic model to prove our separation results So if I were to restate our result, instead of saying there is no black box construction I will accurately say that there is no monolithic construction of IO from any of these primitives Great, so let's go over the second part which is I'll talk about the high level ideas behind the separation results And all of our results are based on proving an impossibility of IO from some form of witness encryption And so I'll be focusing on witness encryption for the rest of the talk So let's say we want to prove that this kind of construction is impossible Let's say we want to prove that a monolithic construction of IO from P is impossible This is actually an equivalent way of looking at it You can actually look at it as a fully black box construction of IO from what we call an extended P Where extended P is simply the primitive P where the P is allowed to accept circuits with any types of gates inside it And this is different than proving an impossibility result And it suffices to prove that fully black box construction of IO from extended P is impossible To show that monolithic constructions of IO from P is impossible And this is different from showing an impossibility result of fully black box construction of IO from a normal P The extended P is actually a stronger primitive And we have to make sure that we carefully define what it means to have this kind of extension for this kind of primitive And so in order to prove our impossibility result we're going to rule out a fully black box construction of IO from this extended P Great, so let's go over the general plan behind proving what it means to rule out a construction of IO from P in a black box way And this is the plan of the general plan of how one does this So the first step is we first define an idealized oracle that securely realizes the primitive P For example in the case of the Connecticut where they show that IO cannot be based on one-way function in a black box way Their idealized model happens to be the random oracle And the second step is that now that we have the idealized oracle The second step is to compile out this idealized oracle from IO in the idealized model And get back an approximate IO in the plain model And by approximate IO we simply mean that it is correct on almost all inputs Then we use the work, the third step is that we use the work of Brackersky, Bruschka and Fleischacker To conclude that from the previous two steps we find that there is no black box construction of IO from P And we want to apply this plan for the case of proving that monolithic constructions of IO do not, from witness encryption, does not exist And I will only focus on the first two steps since this is where the main challenges of our work appear And notice that in the first step where we need to define idealized oracle, we need to define idealized oracle that implements extended witness encryption Because recall that a monolithic construction of IO from witness encryption is actually a fully black box construction of IO from extended witness encryption So we need an I oracle that implements extended witness encryption So what is witness encryption in case you're wondering? So witness encryption says that you can encrypt a message with respect to some circuit, let's call it F And if we want to decrypt the circuit I would only get back the message if the supplied witness is a satisfying statement to the circuit If it is not a satisfying statement I would get nothing And when we want to define what extended witness encryption is We basically mean that the function that we supplied during encryption and evaluated during decryption can only contain witness encryption case That is encryption and decryption case So that is what we mean by extended witness encryption And if we want to define such an oracle it's quite simple to define We just simply define it as a form of idealized encryption and decryption functionality Where the encryption could happen could happen to be for example a normal random oracle So given this oracle our next step is to compile out this oracle from IO Okay, let's see how one does this we are starting with an extended witness encryption oracle In the IO and we have an IO in this idealized oracle And we want to end up with an IO in the plain model that does not ask any queries to the oracle but it is approximate And the two main questions that we'd like to ask when we compile out this IO is how do we obfuscate in this new obfuscation And how do we evaluate this new obfuscation So the general idea behind the compilation process was introduced by Kanati Kali and Panath In the context of compiling out the random oracle from an obfuscator in the random oracle model And it consists of two steps The first step being an emulation phase where I would run the ideal model obfuscation While emulating the queries that are asked by this ideal model obfuscation I would emulate it consistently and I would get some output some circuit as an obfuscation The second step is the learning phase where I would run this algorithm many times on different random inputs While still emulating the queries and answers during the learning phase The purpose of this phase is I would like to learn all the highly likely queries that might occur in the evaluation So I would run it many times, answer the queries consistently And the output of this obfuscation is the ideal model obfuscation along with the queries that were asked or learned during the learning phase The queries and the answers And if I want to evaluate this new obfuscation on a new input I would simply run, execute this ideal model obfuscation on this input While answering the queries with respect to the queries and answer pairs that were learned during the learning phase So we added these queries that were asked during the learning phase in order to make sure that we answer them We answer the queries during the evaluation phase consistently and correctly And note that by adding them we do not hurt security because these queries are learnable That is any adversary in the ideal model could learn these queries on its own So it's fine to include them in the output of the obfuscation So what happens when we look at the compilation process, the same compilation process When we look at it and we want to compile out the witness encryption or the extended witness encryption oracle So the challenge that we face here is that during the learning phase There might be decryption queries that were asked And these decryption queries might have hidden queries as a result of behind the scenes queries that could be asked when evaluating F Now recall that since we're dealing with extended witness encryption, F the circuit could have witness encryption gates So due to the existence of these hidden queries We cannot add these hidden queries to the output of the obfuscation because they are not learnable And adding them will hurt security However, not adding them would hurt the correctness of the scheme because then we wouldn't be able to answer the queries of the final evaluation consistently So how do we resolve this problem? Well, let's go and look back at the oracle And we're going to modify our oracle a bit by adding a subroutine called the reveal subroutine That takes as input a ciphertext and outputs the circuit And that's it And we note that adding this subroutine doesn't hurt the security of the witness encryption oracle So now that we added this reveal subroutine We could actually make use of it to uncover these hidden queries How do we do that? During the learning phase, every time a decryption query is asked We reveal the ciphertext that we want to decrypt Get back the function and make B run the function itself This forces the hidden queries to become discoverable And once they are discoverable, they can also be learnable by any adversary in the ideal and ideal model And again, since they are learnable queries, they can be safely inserted into the output of the obfuscation as well And we can then evaluate the circuit consistently with respect to the queries and answers that we learned during the learning phase So that's how we solved it for the case of witness encryption However, when we look at predicate encryption Predicate encryption The challenge here is the same, we still have hidden queries because we're dealing with extended predicate encryption And extended predicate encryption could have circuits with predicate encryption gates And therefore they might be hidden queries behind the scenes So how do we uncover these hidden queries? Well, we can't We cannot have reveal subroutines as this would violate security We cannot do it for all decryption queries So then what can we do? Well, the thing is during learning, whenever we call a decryption If the decryption happens to succeed, then we can uncover the hidden queries that were asked by this decryption So we can only uncover, we can only do like partial discovery of the hidden queries And we can only uncover these queries if the decryption succeeds And we argue that this is sufficient, discovering like partial queries is sufficient To show that the consistency of the evaluation holds and the correctness also holds And so that's how we solved it for predicate encryption And using the same argument because of the all or nothing property of the encryption schemes We, leveraging this property allows us to discover the queries that were hidden By revealing the message that was encrypted So that's how we, that's how we, that's the high level idea of the proof And as a summary, I'm going to state that here, basically the result where there's no monolithic construction of IO From any of these primitives And so these are some future work that you might be interested in We could, for example, look at lower bounds for IO from stronger assumptions Say it's alternative or weaker forms of functional encryption Perhaps even from the learning with errors problem We still don't know whether this implies IO or not And of course we want to look at other applications of the monolithic model With respect to finding lower bounds for other primitives that have this kind of behavior Because this seems like a very useful model So, yeah, thank you