 I am going to talk about universal indistinguishability obfuscation and witness encryption. And this is in joint work with Ayush, Moni, Amit and Elon. So in the last few years we have seen numerous interesting results such as the feasibility of functional encryption, two round MPC, self binary maps and impossibility results and so on. And the tool that enabled all these results is the notion of indistinguishability obfuscation. So what is indistinguishability obfuscation? It's just a circuit compiler that takes as input a circuit and spits out another circuit such that it satisfies two properties. The first property is the correctness. We require that the compiled circuit agrees with the original circuit on all inputs. And the second property is the security property. Suppose we start with two circuits that are functionally equivalent. Let's say you apply IO on both these circuits. We require that the compiled circuits are computationally indistinguishable. So this is the security guarantee. So now that we have seen that IO is a powerful notion and it implies useful results, the next natural question is to ask is how do we construct this primitive? And the very first construction of IO was given by Gerg Gentry, Hallevi, Raikova, and Waters in 2013. And they built this primitive using the notion of multi-linear maps. Since then there have been numerous constructions and all these constructions have been built using multi-linear maps. I can broadly classify all these constructions into two categories. In the first category, we have IO constructions whose security has been proven in ideal multi-linear map model. So in this model we consider adversaries who can access the encodings in a black box manner. And on the other hand, we have some constructions which are based on concrete assumptions on M-Maps. So now that we have seen that we can build IO from multi-linear maps, the next question to ask is can we instantiate multi-linear maps? And the good news is that there are several candidates of multi-linear maps known starting from the work of Gerg Gentry and Hallevi. But the bad news is that several concrete assumptions on M-Maps are broken. In fact, there are also attacks on IO candidates from M-Maps as well. So at this point given the attacks on multi-linear maps, it's natural to ask if all the candidates of IO are broken. And the answer turns out to be no. I should also confess that I'm not attending the cryptanalysis talks. So I will show the status of all the IO candidates in this table. So the rows indicate all the IO candidates. And the columns indicate the functions for which these candidates are defined. And we are going to mark an entry in this table to be using cross mark if this particular candidate for this functionality is broken. And we mark it with dot if we don't know of any attack so far. And I'm not describing what are these class of functions. These are the class of functions such that it suffices to build IO for them in order to get IO for arbitrary class of functions. This is obtained via what we call bootstrapping theorems. And the table extends to the next page as well. So as you can see, there are a lot of dot marks here. So now that we have seen that we have so many candidates that we don't know whether they are broken or not, we want to find a candidate that is the most secure among all of them. Perhaps a more ambitious goal is if you give me a set of IO candidates, I need to find an IO candidate that is secure as long as there exists an IO candidate in your set that is secure. And this is what we will call as IO combiner. So IO combiner essentially gives a mechanism of combining different candidates into a single candidate that is secure as long as any of the candidates you have combined is secure. And in fact, we achieve something stronger, what is called as robust IO combiner. We only require that the secure candidate be correct. So it could be that all the other insecure candidates have given me are incorrect. And even then our combiner would work. So let me define this notion more precisely. But before that, I want to mention the concurrent work by Fishtien Atal. They show how to get robust IO combiner for constant number of candidates. And they assume that an honest majority of them are secure and correct. And it's going to be in the next talk, so I don't want to talk about it in more detail. So let me define what are robust IO combiner more formally. So suppose let's say you give me N candidates, P1 to PN. So these are the descriptions of the candidates. So my IO combiner will have two algorithms. The first algorithm is an obfuscate algorithm that takes as input the description of all the candidates, the circuit to be obfuscated. And it outputs C star, which is the obfuscated circuit. And then you have the evaluation algorithm that takes as input again the description of all the candidates, the obfuscated circuit, the input on which you want to evaluate the obfuscated circuit on, and it outputs Y. Just as in any IO scheme, this needs to satisfy two properties, which are correctness and security. And both these properties will be parameterized by an index I from 1 to N. That is, let's say there exists, so we want to define both these properties as a function of I. So the correctness guarantee just says that the output of the evaluation algorithm is C of X. And this should be true as long as the Ith candidate satisfies the correctness property, okay? And the security property says that if you give me two equivalent circuits, then the output of the obfuscate algorithm on C0 is computationally indistinguishable from output of the obfuscate algorithm on C1. And this again should hold as long as PI satisfies the security property of the IO scheme. Just to summarize, if PI is a correct and secure scheme, then the combined candidate is also correct and secure. So and the rest of the candidates could be incorrect and insecure, that doesn't matter, okay? So let's see why robust combiners are useful. It implies what we call the universal IO. So what is universal IO? A scheme is said to be a universal IO scheme. If at all IO exists, then this particular scheme is a secure IO scheme, okay? So in just to state it in a different way, if you show that IO exists, then this particular description of the universal IO scheme is a secure IO scheme. And I'm omitting parameters t and q from this description where t denotes the running time of the IO scheme that exists. And q is the security loss. And our work answers a question posed by Goldwasser-Kallai, who posed the question of constructing universal IO, okay? So let me state our main theorem. We show that assuming sub-exponentially secure LWE, there exists a robust IO combiner. We also have another result where we show how to get robust IO combiner from sub-exponentially secure DDH. And as a corollary, we get universal IO under the same assumptions. So we also consider robust combiners for witness encryption. I'm not going to define what is witness encryption. But the only thing you need to know is that all constructions of witness encryption are currently based on multi-year maps. And so suffer from the same vulnerabilities as that of IO. And we can also define robust witness encryption combiners along the same lines as that of robust IO combiners. So, and in this work, we show how to get robust IO combiners from one-way functions. And as a corollary, you can also get universal witness encryption, assuming one-way functions, okay? So the notion of combiners and universal constructions is not a new thing. So let me briefly recall what is known. The famous example is that of Levenson universal one-way function. And Asmuth studied combiners for encryption schemes. There was a beautiful work with studies, combiners for some crypto promoters such as Oblivious Transfer. And it also studies its connection to universal constructions. This is the work of Hardnick, Kilian, Naor, Raingold and Rosen. And there are also some notions of robust combiners considered for obfuscation in the work of Herzberg. Okay, so let me show how to build a robust IO combiner. So let's start with a very weak goal where we just have three candidates. Okay, so we have P1, P2 and P3. And we want to build robust IO combiner for these three candidates. So the most natural approach that comes to your mind is that of re-offuscation. So you start with the circuit C that you want to obfuscate. You're going to first obfuscate C using P1. And then you're going to obfuscate this result using P2. And then you're going to obfuscate this result using P3. So this is the nape construction. Let's see whether it works or not. So the question is whether it's secure. So for simplicity, let's just assume that all the candidates, P1, P2 and P3 are correct. Let's take a simple case where P2 is secure. But P1 and P3 are not secure. But note that all three candidates are correct. And it's an easy exercise to show that the security of P2 implies the security of the combined scheme. And you'll realize that it is crucial that P1 satisfies correctness properties in order to prove this statement. So the next natural question to ask is what if the candidates, insecure candidates are incorrect? Whether this will work or not? At first you might think that what is the connection between correctness and security, it should still be secure, right? And the answer turns out to be that the IO combiner is in fact insecure, okay? And let's see why. Let's see a count example. So let's start with two circuits C0 and C1, which are functionally equivalent. And let's start with the case when P1 is incorrect, okay? So on the left word, P1 on input C0 could potentially output a garbage circuit, in which case the combined circuit on input X will always output BOT. On the right-hand side, P1 on input C1 could output a functionally equivalent circuit, in which case the combined circuit, the combined scheme behaves correctly. So with this we have a trivial distinguisher to distinguish the left and the right words. And so this doesn't work, okay? So even though this count example doesn't work, but there's still some message that we can take. And the message is that if you have a circuit that needs to be sophisticated, then you have to hide this circuit from all the candidates. So this sort of leads to a natural idea. Just do secret sharing of the circuit, right? So you want to offer a circuit C, secret share this circuit and distribute the secret shares among all the candidates. And once you do that, we somehow on input X, these candidates jointly compute C of X. So it's not clear what this means and how to implement this step. And in order to implement this step, we are going to use techniques from MPC. At this point, you might be wondering what is the connection between MPC and the notion of IO combiners, right? To see the connection, we can view all the candidates as corresponding to parties in an MPC protocol. Okay? So every party corresponds to a candidate. And similarly, all the honest players in the MPC protocol correspond to the secure and correct candidates. And all the insecure candidates correspond to the malicious adversaries in an MPC protocol. So this is the analogy between MPC and the setting of IO combiners. So with this, let's see how to build IO combiners starting from MPC protocol. So suppose let's say C is the circuit that needs to be sophisticated. So we are going to start with the three party secure computation protocol. Note that we are still building IO combiner for just three candidates, okay? So we just need a three party secure computation protocol. So we have these three parties. You're going to secret share the circuit into three shares, G1, G2 and G3. And then you're going to upfuscate the code of these parties with the shares hardwired inside them using the candidates. So for instance, you're going to hardwire the code of the first party with G1 hardwired into it using P1. Sorry, you're going to upfuscate the code of the party with G1 hardwired into it using P1, okay? So this is sort of the high-level approach. The question is which MPC to use and how to actually implement this approach, right? In order to see which MPC to use, the first thing we observe is that all the IO candidates are actually stateless. But if you think of MPC, all the parties are actually stateful parties, stateful algorithms, right? And since the IO candidates are stateless, this actually leads to resetting attacks because the evaluator can potentially query the candidates on multiple inputs, observe different values, gain some information. So this is something we have to keep in mind while choosing the appropriate MPC protocol. So in order to avoid resetting attacks, we're just going to use a non-interactive MPC. And in particular, we are going to use techniques from threshold FHE based MPC to actually obtain IO combiner. So let me present the construction of LW based IO combiner. And again, just to keep things simple, assume all candidates are correct. And I'm going to present an IO combiner for arbitrary number of candidates. It's not just three now, okay? So in order to do this, we are going to use a tool which I'm going to call threshold FHE star. This has a setup algorithm that outputs the public key and N secret keys. Here, N will be the number of parties. And you have an encryption algorithm that encrypts M to obtain CT. There is a homomorphic evaluation algorithm. And you have a partial decryption algorithm that lets you decrypt the ciphertext using SKI to obtain the partial decrypted value CDI. And then there is a public algorithm that lets you combine all these different ciphertexts to obtain F of M. And you can actually build threshold FHE star from threshold multi key FHE which in turn can be based on learning with resolution. So let me present the construction. So we have P1 to PN candidates. So in order to obfuscate C, the first thing I'm going to do is to run the setup algorithm of the threshold FHE star scheme. Then I'm going to encrypt the circuit C to obtain the ciphertext. Then I'm going to output the following for all indices in N, one to N. So we are going to construct the circuit HI which has hardwired into it the ciphertext CT along with the partial, along with the secret key SKI. So what does this circuit do? It takes as input X, first fully morphically evaluates the universal circuit on CT. And then it partially decrypts the resulting ciphertext using SKI. And then you are going to obfuscate this HI circuit using PI. Okay? So note that CT, SKI is essentially the ith share of C. Okay? So in other words, the output of the obfuscate algorithm is essentially P1 of H1 to PN of HN. So the question is how do you evaluate? So you have this obfuscation, obfuscated circuit. For every I, you're going to feed in X and you're going to get CTI as the output of the circuit. Then you're going to combine all the partial decrypted value CT1 to CTN to produce C of X. So this is how the evaluation works. Okay, so now the question is, how do we show that this is secure? So let's say PI star is the secure candidate. The goal will be to remove the I star ith secret key from PI star and why do we want that? Suppose let's say you're able to remove SKI star from PI star, then you can just use semantic security of CT to argue that C is hidden. And how do you remove SKI star? It's going to be removed one step at a time and the number of steps will be equal to the number of inputs. If you're familiar with punctured programming techniques, it follows along those lines. But more specifically, we are going to use a technique called partition programming technique, where in the Qth step, you will have SKI star not used for the first Q inputs, but it is used for all the rest of the inputs. Okay, so this is the high-level proof intuition. You can work it out and show that this is secure. So let me move on. So far, we have assumed that all the candidates are correct, right? Now the question is, what if they are not correct? And at first, you might think that maybe the work of Bitansky-Vykontonathan might be directly applicable here, and in particular, let me recall what they show. They show how to go from half plus one by poly approximately correct IO for all circuits to perfectly correct IO for all circuits. And the thing I want to emphasize here is that they require that the scheme they start with should be half plus one by poly correct and that too, it should hold for all circuits. So, but the natural question to ask here is that, how do you even check if a candidate is half plus one by poly correct and that too for all circuits, right? And as you might have guessed, this is not possible to do it in polynomial time, okay? So we are going to use a different approach to solve this problem. So what are we going to do? We are first going to check if the i-th candidate is one minus one by NK correct on the specific circuit GI. K here is the security parameter. And this can be done by just sampling many random points and then checking if the sophisticated circuit agrees with the original circuit on these random points. And if the check phase just discard this candidate, and then we are going to observe that if you combine all the candidates that remain, then that combined scheme is one minus one by K correct and that too, it is correct for all circuits. And this you can show by union bound and also exploiting the specific structure of the combined scheme we have, okay? Once you have the second bullet, now you can just apply BV16 on top of this to show, to get an obfuscation scheme that is correct for all inputs, okay? So this is how we are going to, we are going to deal with correctness issue. So let me just conclude. So we showed how to construct IO combiner from SubExmonitually Secure LWE. What I did not talk about is to construct IO combiner from DDH and also combine us for witness encryption. I encourage you to read the paper. And this, the result of Robusti combiner implies universal IO from SubExmonitually Secure LWE. The natural open question here is that can you actually construct Robusti combiner for boundary functions? And also to construct combiners for other primitives from which are built from M maps, okay? Thank you.