 Hi, thanks, Brent. I'm going to present indistinguishability of fiscation from compact function encryption. And this is in joint work with Abhishek. So in the last two years, we have seen numerous applications of IO. For example, we have seen how to construct FE from IO, two-round multi-party computation, many impossibility results of crypto primitives, existence of many primitives with input-specific running times, and so on. So since IO has proven to be so powerful that it implies a lot of things, it's important to see how to construct IO. For example, what assumptions it can be based on, and so on. And the current known constructions of IO can be classified into two broad categories. And the common link between both these categories is the tool of multi-unmaps, which was dealt with in the first talks of the session. So let me talk about the first model, which is that of ideal model. Ideal model is a generalization of a generic group model, but to the multi-unmaps setting. So the main drawback of this model is we know of some constructions that are secure in this model, but which are insecure in the standard model. So this model does not mimic the standard model like what we want. And the second category is that of basing a fiscation on some concrete assumptions. So in this regime, we only know of two works, that of Paaseh Talang, who construct IO based on Uber assumptions, and that of Gentry, Lavko, Sahay, and Waters, who construct IO based on what is called subgroup elimination assumption. So while this is great, there are still some problems, which are that there have been recent multi-unmaps attacks, which have made us suspect the current known IO constructions. So this is an unsatisfactory solution that we have a fiscation only based on, only through multi-unmaps. So it is important to explore new approaches to build a fiscation. So in this regard, we only know of one other work that implies a fiscation, that is the tool of multi-input function encryption. So in this work, we show how to achieve a fiscation via this approach of multi-input function encryption. To be more precise, we show that multi-input function encryption can be built from compact function encryption. And one more result, what we obtain is that we show how to construct this compact function encryption from randomized encodings for Turing machines. So there is a star mark here. I mean, we don't build compact function encryption from any randomized encodings for Turing machines. We need a specific type of randomized encodings for Turing machines. I'm going to talk about it very soon. So for this talk, I'm only going to focus on the result of obtaining multi-input function encryption from compact function encryption. So let me first explain what is function encryption. So function encryption enables a user to obtain a constrained secret key corresponding to a function in such a way that given a ciphertext of x, he can decrypt the ciphertext to obtain f of x. And the security guarantee we require is that the user should only obtain f of x and nothing else. And now let me consider what is compact function encryption. Compact function encryption is also a function encryption scheme, except that we require the encryption complexity to be independent of the function complexity. To be more precise, we require the running time of the encryption algorithm to depend only on the security parameter and the instance size. So with this, let me state our main result. Assuming the existence of public key compact FE, we show that IO exists for all poly-size circuit. And the requirement we have on compact FE is very minimal. We only require it to be selectively secure and to be secure against adversaries who only make a single functional query. So if you don't know what are these things, you don't have to worry about it because I'm not going to deal with this in this talk. I should also mention that there was a concurrent work by Nir Britansky and Vinod Vankretanathan who achieved the same result. But they also observed that a weaker notion of compact FE suffices, where the encryption complexity depends only in sublinear in the size of the function. And I should mention that the same observation also holds for our setting. So before I move on, let me mention what are the implications of our work. Suppose let's say you believe that IO does not exist. You are an unbeliever. You really hate IO. Then you should also believe that the traditional notion of FE, which we are all familiar with, does not exist. So by traditional notion of FE, I mean non-compact FE. And this result we obtained by combining our work with the recent work on the implication of FE to compact FE. And then you should also believe that the notion of output compressing randomized encodings does not exist. At a high level, this is essentially randomized encodings for Turing machines, except that the size of the encodings does not depend on the output length of their Turing machine. This seems like a natural generalization of randomized encodings for circuits. And the star mark here is just that we require that these primitives are secure against sub-exponential adversaries. So there are other results which I don't want to deal with. So you can refer to our paper for more details. So one open problem that stems from our work is to construct compact FE from weaker assumptions, other than multi-in-map assumptions or IO. This will have a direct impact on the constructions of IO. OK, so let me move into the technical details. In order to achieve our result of IO from compact FE, we are going to consider an intermediate goal, that of constructing secret key multi-input function encryption from compact FE. So the question is, how does this help us? We can now use a theorem, which was proved by Gordon et al. That secret key multi-input function encryption implies IO. So plugging this theorem into what I'm going to show now, we get IO from compact FE. So before I prove the implication of compact FE to multi-input function encryption, so let me first briefly describe the proof of the Gordon et al theorem. So in order to describe that, let me first formally define what is multi-input function encryption. So in the notion of multi-input function encryption, a user can request for a key corresponding to a function. And this function is a multi-refunction. And in this case, it's a for a refunction. In such a way that he can use this key to decrypt ciphertext of x1, x2, x3, and x4 to recover the message f of x1, x2, x3, and x4. OK. And the security guarantee is similar to how we defined for the single instance FE. We only expect the user to get this value and nothing else. And just to establish some notation, I'm going to call x1 to be the first position ciphertext and the encryption of x1 to be the first position input and the encryption of x1 to be the first position cipher text and so on. OK. And then I'm going to call MIFE for IRE functions to be MIFEI. OK. So how do we construct IO from multi-input function encryption? So the obfuscation of a function f will consist of two components. The first component is a functional key of a universal function that has in its belly an encryption of f. I will soon explain where the secret key goes. And the second component just consists of a bunch of ciphertext. And what are these ciphertexts? These ciphertexts are just encryptions of 0 and 1 with respect to every position. Recall that f here is an NRE function. So we need to encrypt with respect to all the N positions. And then I'm going to put the secret key that decrypts the ciphertext of the encryption of f in the first position. Suppose let's say you want to evaluate this obfuscation of f on all 0s. How do we do that? You just discard all the encryptions of 1 with respect to every position. And then I'm going to evaluate the functional key on all the encryptions of 0. And how does the evaluation proceed? We first decrypt the encryption of f with respect to sk to recover f. And then you evaluate f on all 0s. And the result is the output of f on all 0s. So this is the high level idea of the proof of the theorem. So now let me describe how to obtain mife from compactive. In order to do this, I'm going to adopt what we call an iterated construction of mife. So in the first iteration, I'm going to consider an instance of public key compactive. And then I'm going to combine this instance with the secret key compactive. So it's easy to see that public key compactive implies secret key compactive. So I'm not making any additional assumptions. I'm going to combine both of them to obtain a two or mife. So once I do that, I'm now going to use this two or mife. And then I'm going to combine this with a fresh instantiation of a public key compactive. And the result is a three or mife. And I keep on doing this. And in the end, I'll get n minus 1 mife. And that I'm again going to combine with a fresh instantiation of a compactive. And the result is n or mife. So this is the high level idea behind our construction. So for this talk, I'm only going to focus on the construction of two or mife. So just to build some intuition, note that here we are starting with a functional encryption scheme that can only handle one ciphertext. And in the end, we want to build a two or mife scheme that can handle two ciphertexts, that the functional key can decrypt two ciphertexts at the same time. So somehow there must be a way to combine two different ciphertexts into one ciphertext. So in order to develop this idea, we are going to introduce a technique that we call input aggregation. So what is this technique? So to demonstrate this technique, let me consider a simple example. So suppose let's say you have a functional key, which is g. This has embedded into it a y and a master secret key corresponding to a symmetric encryption scheme. This function takes as input x and outputs an encryption of a concatenation of x and y. And this encryption is with respect to the master secret key of the symmetric scheme. And then I'm going to give you a functional key of g and I'm going to encrypt x. So now the question is, can we argue anything about the security of the ciphertext? Can we say that the ciphertext hides the concatenation of x and y? It turns out that we cannot argue anything about the security. And the reason is that the functional key did not hide anything about y or MSK, in which case we cannot argue anything. So in order to prove this secure, we require function hiding. In other words, we want functional keys that hide the functions it's associated to. And it turns out that in the public key setting, it's as powerful as IO. So we cannot assume a function hiding public key fe. So for this reason, we are going to work in the secret key setting. Okay, so what is function privacy in secret key setting? Suppose let's say you have two functional keys of g0 and g1 respectively, where g0, g1 are such that the output of g0 and x0 is the same as the output of g1 and x1. And here x0, x1 are challenge messages. If this condition holds, we say that these two functional keys are computationally indistinguishable. Okay, and there was a very elegant work by Brecker's case, who showed how to achieve function private, function encryption in the secret key setting, starting from any non-function private, function encryption. Okay, so we are going to use this very crucially. So now let's say instead of using any function encryption, now let's use a function private fe scheme. In this case, we know that the security of a CT follows from function privacy. It's not immediately obvious, but you can somehow argue by making use of the function privacy property of fe. So once we do that, how is this going to help us? I'm going to interpret the functional key as a ciphertext of y. And then I'm going to interpret the encryption of x as a ciphertext of x. And now by combining both of them, I now get a joint ciphertext of x and y. So somehow we have developed a mechanism to combine two ciphertexts into one ciphertext. Okay, so now with this intuition, let me show how to construct two or MIFE. So just to establish some notation, I'm going to denote functional keys by triangles and ciphertexts by rectangles. And then I'm going to denote the secret key compact fe by red and then public key compact fe by green. Okay. Okay, so first let me explain how to encrypt a message with respect to both the first position and the second position, okay? So let me show you the first position. So encryption of x with respect to first position is nothing but an encryption of x with respect to the red scheme. And encryption of y with respect to the second position is nothing but a functional key of g of y. And what is this function g of y? G of y essentially takes as input x and it outputs an encryption of x and y. And this encryption is with respect to the green scheme. Okay, the green scheme here is the public key scheme and the red scheme here is the secret key scheme. So this is how we encrypt the messages. So as you recall, this was the input aggregation step, right? We generated, we designed a functional key that outputs a combined encryption of two messages. So let me explain the key generation algorithm. So key generation of function f is nothing but a functional key of f with respect to the green scheme, okay, which is the public key scheme. So now how do we decrypt? Now to decrypt, I'm going to first combine the ciphertext of x and the functional key of g. Note that both these quantities are defined with respect to the secret key scheme. So we are not doing anything illegal. And then when we combine both of them, we are going to get an encryption of x and y with respect to the green scheme. So now I have an encryption of x, y and I have a functional key of f. So now let me combine both of them and the result is the output f of x, y. That's the construction, okay? So the question is how many times can we do this, okay? So we just saw in the two-way setting, but the question is does something weird happen if we keep on doing this many times, okay? In order to see this, let us plug in this construction of NRE MIFE in the transformation of MIFE to IO, okay? And the resulting obfuscation essentially looks like this. So you have a ciphertext of zero and one with respect to the first position and with respect to all other positions, you just have functional keys, okay? So what are these functional keys? Take for example, G2 zero. This has embedded into it the bid zero. It takes as input x and it's going to output the concatenation of x and zero with respect to the scheme of the fourth position, okay? In general, the function GI zero is going to take as input x and it's going to output the encryption of x concatenate with zero with respect to i plus one scheme, okay? And similarly, you can also consider G2 one, okay? Which outputs the concatenation of x and one and so on, okay? Okay, so how do we evaluate? Let's say we go back to our previous example where we want to evaluate the obfuscation on all zeros. In order to do this, I'm going to first discard the encryption of one with respect to the first position. Then I'm going to feed in the encryption of zero with respect to the second position and then I'm going to get an encryption of zero, zero with respect to the third position. And if I keep on doing this, in the end, I get an encryption of n minus one zeros with respect to the last position. And if I continue in the last step, I'm going to get an encryption of all zeros. This is with respect to the green scheme, okay? And the evaluation of the functional key and all zeros will be nothing but f of all zeros, okay, as before. Okay, okay. So in order to see whether iterating it many times will cause a problem, let us consider the case when that we start off with an FE scheme that is not compact. So what do I mean by that? Here, I'm going to assume that the functional key, corresponding to the ith level, depends on the size of the functional key corresponding to i plus one, i plus one position, okay? And let's see what happens. So we start off with this functional key, G1, in the beginning, in the first iteration. And after the first iteration, the size of G1 grows, okay? It grows by a multiplicative factor of at least a security parameter. And why is that? Because the size of G1 depends on the size of G2, okay? And if we continue for one more iteration, the size of G1 grows further, okay, by another multiplicative factor of the security parameter. And why is that? This is because the size of G2 grew, right, by a factor of security parameter because of G3, okay? And correspondingly, size of G1 blows up because size of G2 grew, okay? If you keep on doing this, then after a super constant number of iterations, the size of G1 will become exponentially sized. And so this is the main issue. And this is the reason why we require that the FE scheme we start off with is compact, okay? So I will not go into the details of the proof because I don't have time. So let me just summarize. So in this work, we show how to obtain obfuscation from indistinguishability obfuscation from public key compact FE. And the way we achieve it is by constructing a multi-import function encryption scheme, which in turn is constructed by this additive amplification technique. So one result I did not mention is how to obtain compact FE from output compressing randomized encodings. You can see the paper for more details. And one problem that is open is are there other natural primitives that also imply just to understand where indistinguishability obfuscation lies in the complexity zoo? With this, I conclude.