 talk. Let me maybe announce the last talk. So the last talk will be COA secure obfuscation and applications by Ran Kaneti, Subhadev, Chakraborty, Dakshita Kurana, Nishant Kumar, Oksana Kuburinaya and Manoj Prabhakaran. And before Suvaradip will tell us about this result, Ran Kaneti would like to speak a few words about the recent and tragic passing of one of the authors of this work. Thank you. Thank you. So one of our co-authors, Nishant Kumar, died last month in a tragic accident. And I would like to say a few words in his memory with your permission. Be very short. So some of these words were written by Dakshita Kurana, which was Nishant advisor and some of my own. So Nishant was born December 2, 1994 in Ranchi, Jakobar, India. And he passed away in a tragic accident on April 10 this year in Hawaii, Illinois, in US. He was 27 years old. Nishant was a bright star in our lives. He was special in his contagious, almost childlike enthusiasm and curiosity. He was also very insightful and smart. He had the makings of a wonderful researcher, and his passing is a measurable loss to our community. Even more importantly though, he was kind, patient, humble, and a caring mentor to many others. His passionate curiosity extended to a very wide array of topics spanning both theoretical and applied cryptography. He was bearing with questions and ideas, and he loved long, deep technical conversations. He would take it upon himself to drive project forward. He wouldn't shy away from spending long hours thinking about hot questions. He was a dream student and collaborator. He spent two productive years as a research fellow with Microsoft Research India, where he worked on multi-party computation compilers for machine learning. Two of these papers titled Cryptflow and Cryptflow 2 had an important impact on the area of secure inference. At the UIUC, he worked on non-modable and very probable obfuscation, which is the work that we will talk about today, and on new ways to achieve security by exploiting the properties of quantum information, which is forthcoming work. In our joint work, he was first very tentative, but as he learned more about the work and the relevant literature, he became more confident and started catching us when we were saying something wrong or just BS-ing. Soon enough, he started owning the work and providing large parts of it. Throughout, I was very much impressed with Nishant's insightfulness and his ability to say that he does not understand, that he did not understand or just know something, but when he was saying something for sure, if he was environmentally right. Last month, in March, we were working on finally putting a full version of the paper on Eprint. I was writing a new proof for one of the theorems, and I was very proud of it. It was very nice. I thought, it was nice ideas, and it looked just fine, but I sent everybody, please take a look. The following weekly meeting last Monday, Nishant said, it's very nice, but there are two issues which I don't really understand. I knew I was in trouble, and sure enough, those two issues were deep flaws in this truth, which we spent a lot of time the entire meeting to discuss. Then, time went out, and we had to stop. We said we'll talk next week. I spent most of the week thinking about the ways to get around those issues, and I was looking forward to the next Monday's meeting to discuss it again with Nishant and the others, but then Monday morning, I opened my email to the terrible news. I would like to tell Nishant, wherever he is, that we now think we have it done, and it's in the same overly. If you can take a look, it would be great. I can just say a few in one last paragraph, saying that Nishant's beautiful smile, sincerity, energy, and cheer touched the lives of everyone around him. It is still very hard to accept that he will never come back to us, but we always keep his memories of hearts and use his life to guide our own when we move forward. Thank you. Thanks, Ran, for the obituary. Indeed, it's very hard to accept that Nishant is not with us anymore, and I would like to dedicate my talk in the memory of Nishant. This talk is about COA secure obfuscation and applications. This is joint work with Ran, Dakshita, Nishant, Oksana, and Manoj. A one-minute summary of the paper. This paper provides a framework that endows software obfuscation with proofs of well-formness. In particular, it enhances many of the existing security notions of obfuscation to provide verifiability and non-malability guarantees, and we show genetic construction satisfying our definitions. The roadmap will be, I'll start with some motivations, why we consider such an ocean followed by our new definitions and some new applications to complete CC encryption and stronger software watermarking. In the interest of time, in this talk, I'll be talking about the complete CC encryption, although the software watermarking is also one of the main applications of our paper, and I would encourage people to look up our paper for the watermarking application. And finally, I would end my talk with the construction of COA obfuscation. Good. So general purpose software obfuscation holds great promise for enhancing the security of software. In general, software can be distributed and executed without fear that the internal design secrets of the program or the keys that are hidden inside the code will be revealed. And this is great for software creators because they can use obfuscation to hide the keys, both in the code and functionality. However, ubiquitous use of obfuscation might also call for some drawbacks. In particular, it's hard to verify properties of the obfuscated program. In general, it reduces to black box testing the program. And this is highly unsatisfactory, particularly if the, for example, the creator of the obfuscated program is untrusted or unknown. So yet another pressing issue is the issue of malleability in which the adversary might create an obfuscated program that depends on the secrets that are embedded in some other obfuscated program in illegitimate ways. And when I say illegitimate, it could refer to the legitimacy condition could refer to both the structural and functional properties of the obfuscated program. So for example, obfuscation might help to facilitate software plagiarism. Imagine that I publish an obfuscated program A that hides the details that it's potentially using the mold version of some proprietary software and it's not publicly announcing it. And this is a problem even if the program B is implemented correctly because the behavior of A might depend in malicious way depending upon the behavior of B. So one might expect that the already existing notions of software obfuscation like IO gives some sort of non-malleability guarantee. And in particular, this is somewhat true if, for example, IO uses inside it some module that directly does not affect the functionality of the program. But for example, imagine that you're obfuscating a pseudo random function like a puncturable PRF with a key K so that directly affects the output of the program. So in such case, it might be possible that adversary takes such an obfuscated program and produces another program that computes the same function but on a related key, K plus one, for example. So hopefully this provides enough motivation why we should study verifiability and non-malleability for obfuscation in general. So having said that, let's see what are the challenges that arise when we try to define such an ocean of obfuscation. So since we're talking about some sort of verifiability or non-malleability, we should have a verifier that takes an obfuscated program and outputs, say, accept or reject. So let's try to define in the following way that when the verifier accepts a program, then a specific circuit is being obfuscated. Of course, this is not desirable because ideally, you'd like to hide the code of C, which ideally obfuscation should do. But if you prove that a specific circuit is being obfuscated, then you reveal all the details of the circuit. The second attempt is that you would want to say that, okay, so if the verifier accepts, there exists some circuit C, which is functionally equivalent to this obfuscated circuit. This sounds reasonable. However, this is trivial to achieve because for every obfuscated program, there exists some plaintext program corresponding to it. So let's define a class of predicate. For the simplicity, let's consider a particular public predicate phi. And now the verification algorithm also takes as input some predicate and outputs accept. So we would want to say that if the output of the verification on input an obfuscated circuit and a public predicate is accept, then there exists an underlying circuit, which is functionally equivalent to the obfuscated circuit and satisfies the predicate. Now look that what we can do is that we can define the predicate in a fine-tuned way that hides the code of the circuit C, yet attest to some of the properties that you would want to verify. So for example, it might attest to the programs of some particular functionality or some particular structure, whatever you would want. Okay, so what's the trivial way to achieve this? You obfuscate a program and attach an easy proof that there exists some circuit C and randomness that results in the obfuscated circuit and satisfies the predicate. The drawback is that it requires a trusted setup phase that is a common reference string. And the goal of this work is to construct verifiable and non-manable obfuscation in the plain model. So before going into the details, let's review some prior works. So to the best of our knowledge, the closest work that is related to this topic is the verifiable functional encryption by Badrinar and Goyal, Jain, and Sahai from Isha Group 16. So the upside of their construction is that they provide a construction for IO that's verifiable and does not require any trusted setup assumption. However, the drawback is that that technique is stellar made for IO. So their idea is to use NEMI instead of NISIX. However, if you think about it, if you use NEMI, then the NEMI only guarantees that the witness is hidden if you have some alternate witnesses. So if you just obfuscate a program, you don't have an alternate witness to prove. So what they do in their construction is basically obfuscate the same program, say three times, and then prove using NEMI that two of the programs are same or functionally equivalent. And now I can use NEMI in some way to give verifiability. And I think the main drawback of their work is that it provides a limited form of hiding that can only guarantee indistinguishability for indistinguishability for obfuscations of functional equivalent circuit for which there exists only a short proof of equivalence. Say if you obfuscate, for example, a PRF and a punctured PRF, you have such a short proof of equivalence, but in general, this is not true for general circuits. And also it does not provide any sort of guarantee against malleability attacks. So it only provides guarantee against verifiability. Okay, so there's another work by Ran and Mayank from TCC 2009 with the title on malleable obfuscation. And this gives however this considers obfuscation for point functions and related functionalities because this is a simulation-based definition. And as we know that for all cluster functions, you cannot get VVB obfuscation. So this paper considers obfuscation for point functions and multi-point functions. But if you think about it, to define non-malleability, it's natural that you would want to have a simulation-based definition that whatever the adversary could come up with a black box axis, you can also simulate. Unfortunately, it's plagued by impossibility result. So this brings us to our definition, what is COA stands for chosen obfuscation attacks. So as before, let's consider a class of circuits and some predicate phi. And you'd expect that so the obfuscation algorithm also takes some circuit C and a predicate phi and outputs the program C hat. And the verification algorithm also takes the predicate phi and it should output 1 or 0. However, it turns out that so the obfuscator can be randomized and the verifier is deterministic. So in this setting, it turns out that it's very difficult to achieve security, I mean even verifiability for a general class of circuits. So what we do is relax the notion and say that the verifier can also be randomized. And the output of the verifier is not a single bit, instead it's a circuit. So let's try to understand this notion. So the obfuscation is basically a two step process where the obfuscator takes as input some circuit C and outputs some semi-functional obfuscation. It's not yet a fully functional program, so think of it as an encoding. And the verifier then transforms this encoding into a fully functional obfuscated circuit. So what is the correctness guarantee? The correctness guarantee is that for a legitimate circuit that is a circuit which satisfies the predicate, the output of the verifier is functionally equivalent to the circuit that you obfuscated. Soundness says that for any arbitrary program intermediate program C hat, if the output of the verifier is not bottom, that is it's a circuit C tilde which is not bottom, then there exists an underlying circuit which is functionally equivalent to C and satisfies the predicate. So this means that if the verifier outputs some circuit, then there exists some explanation of the circuit in the plaintext space and such that the plaintext program is legitimate. And finally, I come to the main notion which is COA security which says that for sufficiently similar circuit C0 and C1, the obfuscation of these two circuits is indistinguishable even given access to a de-obfuscation oracle. So I'll make it more explicit in the next slide. So let's consider this game between a challenger and an adversary. So the adversary uses a sampler to sample circuit C0 C1 along with some auxiliary input set and passes it to the challenger. Now when I say that the circuits must be sufficiently similar, so what do I mean by that is that the sampler should be admissible. So in some sense, the circuit C0 and C1 should satisfy the predicate and they should be indistinguishable by black box access. Okay, so note that this is powerful enough to capture any notion of obfuscation that provides some sort of hiding guarantees. Like in case of IO, C0 and C1 are functionally equivalent and Z is just null. Or you can think of Z as C0 C1. You can also capture PIO, XIO in this notion where you can define the sampler accordingly. Now the challenger samples a random bit and obfuscates a circuit Cb and sends C hat. So note that C hat is still not the fully functional program, right? It's the intermediate program. Now the adversary can ask for de-obfuscation queries. So it gives us input to the challenger some string C hat, which is a semi-functional program. And what the challenger does is that if it is equal to the challenge intermediate program, it outputs bottom. Else it runs the randomized verifier to transform it into a fully functional obfuscated circuit, C tilde. And if C tilde is not bottom, it returns. So there is a typo here. So basically you can think of it that when C tilde is not bottom, it returns a lexicographically first circuit, which is functionally equivalent to C and satisfies the predicate. So this is how the de-obfuscation oracle is defined. So note that this holds because if the output of the verifier is not bottom, then as I said, then there exists an underlying plaintext circuit which satisfies the predicate. And in particular, there can be many such circuits. So the challenger is inefficient, of course, and it outputs the lexicographically first such circuit which satisfies the predicate. And it returns the plaintext circuit to the adversity. And the de-obfuscation circuits can, queries can be made adaptively and in arbitrary order. And for simplicity, I've assumed that the adversity in the first step gives the C0, C1, but this is not necessary. It can also ask de-obfuscation queries and then give the challenge. Okay. And finally, it outputs a bit de-prime that's a guess for which of the circuits was obfuscated. Okay. So in our work, we also provide a second definition that is more handy to work with. So in particular, this definition says that you give me any notion of obfuscation that satisfies some hiding guarantee, which is represented by the admissible sampler definition. And I can augment this obfuscated circuit to give you a COA guarantee on top of it. So we call it COA fortification. So as before, we consider a class of circuit and a predicate phi. But now, let's define O to be an obfuscation scheme, which is injective. So why do I need it to be injective? I'll later explain. But in general, you can transform any obfuscation scheme into an injective obfuscation scheme by attaching a perfectly binding commitment of the plain text program along with the obfuscated circuit. Okay. So as before, the obfuscator takes us input the circuit and the predicate outputs a semi-functional program, which is then transformed by the randomized verifier into a fully functional program. So the correctness says that for a legitimate circuit, the output of the verifier should be in the image of the obfuscator O. So in particular, C tilde can be explained as an obfuscator of C with some randomness R. Soundness says that if the output of the verifier on some arbitrary string C hat is not bottom, then there exists an underlying circuit C such that it satisfies the predicate and is in the image of the obfuscation O. And finally, COA security says that again for sufficiently similar circuit C0 and C1, given access to a de-obfuscation oracle O inverse. So this is where it becomes important why the obfuscation scheme is injective. So when I say an obfuscation scheme is injective, it means that no two plain text programs map to the same obfuscated program. So for each obfuscated circuit, there is a uniquely defined plain text program, and hence the challenger can inefficiently invert and recover the plain text program. So now the security says that if the obfuscation of the two circuits C0 and C1 are indistinguishable, I can use this distinguisher to build a distinguisher for the underlying obfuscator O. So pictorially, so this is the, it says that suppose in this world where in the left world where there is an adversary and challenger it runs this game where the adversary receives a challenge semi-functional program, which is an obfuscation of either C0 or C1. And it makes de-obfuscation queries arbitrary and adaptively. And suppose there is a distinguisher, so if the adversary can distinguish which of the two circuits was obfuscated with non-negligible advantage, then I can use this adversary to build an adversary in the right hand world where note that there are no de-obfuscation queries. So this translates to a distinguisher for the underlying obfuscator O. And it's not hard to see that this definition two for injective PIO implies our definition one. So if you have COA fortification for injective PIO for some class of samplers, so more technically X in PIO, this implies our definition in the the definition that earlier showed you. Okay, so let's jump into the application, given the definitions. So the application that I'll be talking about is a complete CCA public key encryption. So this is basically an enhancement of CCA secure public key encryption where the adversary has access to a strong decryption oracle. So normally in CCA, the adversary has access to a decryption oracle where it can feed different ciphertext and get messages, but with respect to the challenge public key. But here the adversary can submit a couple of public keys and ciphertext of his or her choice and get it decrypted. So this is a strengthening of the notion of completely non-malleable encryption which was defined by Fishlin and some later works when defined appropriately. So it turns out that this notion is too good to be achievable in the plain model. So Fishlin showed that completely non-malleable public key encryption is impossible to construct in the plain model if you're using black box reduction and if the assumption in your hand is a polynomial time falsifiable assumption. So in our work we bypass this impossibility result by using sub exponential hardness assumptions. So before going into the model we require one technical condition from the public key encryption namely unique decryptability. So what does it say? So for any public key there is a way to test whether this public key is useless. So I assume that the encryption algorithm can output a string bottom and the decryption algorithm on input such a ciphertext which is bottom outputs bottom. So I say a public key is useless when the probability that for any message the ciphertext is bottom is some negligible. And for non-useless keys there should be a unique opening for this public key. So that means there should be a secret key that decrypts the ciphertext correctly. And moreover for this unique opening there should exist a public key that is under the support of the key generation algorithm. So note that the public key pk might not be in the support of key generation. So pictorially the challenger runs the key generation and gives the public key, the challenge public key to the adversary. Now the adversary can ask for like tuples of his choice like pki ci. Now the challenger checks if pki is useless. If it is not useless it inefficiently finds the opening that is the secret key and returns the message mi which is the result of decrypting ci under the opening. And it can do it arbitrarily and as many times as it wants. And then the adversary gives two messages M0 and 1 and gets the encryption of one of them. And it can continue the strong decryption oracle phase. And at some point it outputs a guess for the bit B. So having defined this notion, let's see how to construct this strong form of public encryption. So for this we would of course be requiring our notion of COA fortification for an injective IO. So with respect to a predicate which says that the predicate attests to some program which I will shortly show. So we need zero random generator which is length doubling and two PRFs which is puncturable. So the key generation algorithm samples two keys and the public key is an obfuscation of the following circuit. So it has two PRF keys embedded inside it. It takes us input a message and a randomness and expands the randomness and uses the C1 to basically encrypt the messages like a one time pad. And C3 is basically you can think of it as like a Mac on C1 and C2. So this is basically the Sahai waters CC secure public encryption. And what we do is kind of replace the obfuscation with the COA fortification for injective IO. So the encryption algorithm. So note that the public key is not yet a fully functional obfuscated circuit. So it's the P hat is the semi functional program. So the encryption algorithm runs the verification transforms it into a fully functional program and then runs the program on input the message and some randomness and samples. And the output is basically the ciphertext from the obfuscated circuit and the decryption key is basically the two secret keys and the decryption is trivial. So why is the scheme uniquely decryptable? So it follows from the soundness of the COA fortification of IO and the injectivity of IO. So this is because if the encryption algorithm outputs some circuit P tilde, which is not bottom with that means that there exists some plain text program such that program can that program is the obfuscation of such that P tilde is the obfuscation of that program. And since we say that the program should attest to this predicate phi, which is this program P k1 k2, it means the plain text program must have this structure. So in particular, I can extract the keys k1 k2 and use it for decryption. And since the IO is injective, there exists a unique such plain text program. Okay. Right. So let's go to let's see the proof of this on a very high level. So recall this. This is the program that we're obfuscating. So broadly, the two cases might arise for each strong decryption query. First, the public key PKI that the adversary queries is equal to the challenge public key. This is an easy case because then we are basically reducing to the CCA security of Sahi waters because the challenge key has not been changed. The interesting case is when the public is changed. So the adversary queries on some P K C where P K is not equal to P K star. So in this case, you can you interpret P K some semi functional program, you run the verifier and get a fully functional circuit P tilde. And you know, and by the soundness of COA fortification, you know that there exists a plain text program, which is obfuscated by IO to get P tilde. So now you recover this plain text program by using the de obfuscation oracle. And since the secret keys of the form. So once you have the plain text program, you can read the code of the program to recover the underlying PRF keys and use it for decryption. Good. Okay, so finally, I'll go to the construction of COA obfuscation very briefly. For this, we need non interactive distributionally indistinguishable argument that was introduced by Dakshita from last year Eurocrypt. So what is a needy argument? A needy argument is defined with respect to an NP language with some relation R L such that the prover and the verifier has input the language L the prover in addition has some secret distribution D of which it can use to sample statements and witnesses from the distribution in efficient efficiently, the prover hands over to the verify one message, think of it as a sampler and the verifier can use the sampler and its randomness to verifiably sample members from the distribution. So, so in particular completeness says that the output of the verifier is in the support of the distribution on the statement soundness says that if the output of the verifier is not bottom, that means that D is in the NP language L. So think of it as the instance being in the language and privacy says that for distributions which are indistinguishable, the proof does not break the indistinguishability. So for every distribution D1 and D2, which are indistinguishable, the samplers which are output by the prover are also indistinguishable. And this paper shows that assuring sub exponential I O and one way function that exists needy for all of NP. So in our work, we need a robust version of needy which we introduce, which is a needy that guarantees similar indistinguishability but with respect to an oracle O. So as before, we have the prover and the verifier and the completeness and the soundness guarantee, but robustness in general says that the two distribution, if the two distributions are indistinguishable, maybe a couple of minutes. Then the output of the prover is also indistinguishable even if the distinguisher get access to this oracle O. And we show how to construct this robust needy by modifying the construction from the paper last year, but I won't go into the details. So for the construction, I need a CCA secure commitment scheme where the oracle O is basically the decommitment oracle and I need an obfuscation scheme that is secure against adversities that can internally store this oracle. And the obfuscation scheme is very simple. So the distribution is defined as follows. You obfuscate the circuit C with some randomness R1 and you commit to the plaintext program. So having defined this distribution, the proof is basically, the obfuscation algorithm is basically the sampler of the needy prover and the verification algorithm is just verifying the needy proof. And I won't go into the proof, but the high level idea is that in the first hybrid, I obfuscate C0 and commit to C0. And now I obfuscate using the decommitment oracle. So note that in the first game, the obfuscation was done using O inverse, but now I will obfuscate using the decommitment oracle inefficiently. And in the next hybrid, I will switch to obfuscating and committing to the other program C1, which I can show to be distinguishable based on another hybrid argument. And roughly, since we assume that all the underlying primitives are secure with respect to the decommitment oracle, in particular with respect to adversaries who can store the decommitment oracle, the proof goes through. So finally, I would conclude with some open problems. So note that the main drawback is that our definition relies on this two-step randomized process. Is it possible to construct C0 secure obfuscation for the more traditional definition where the verifier is deterministic? And secondly, can come up with more applications of C0 or obfuscation, because this seems to be, this seems that it will find more applications in other areas of cryptography. With that, I'd like to conclude and I'm open to taking questions. Right. Thank you so much. We have time for maybe one quick question. Yes. So in all most of your notions, the challenger is inefficient, right? I was wondering whether this leads to problems with the final hybrid proofs and reduction. So yeah, good question. So it does not because we assume that the underlying primitives basically are also secure with respect to sub-exponentially secure. So for example, in the last construction that I showed, the obfuscation oracle is basically inefficiently opening the commitment. So it's the decommitment oracle. So suppose that oracle is of size some capital T because it's a finite truth table. You can write it down. And if you assume that the other primitives are secure with respect to adversaries that run in that time, then it's possible to argue security. So yes, we need security of all the underlying primitives to satisfy sub-exponential hardness. So that's how we kind of cope with the inefficiency of the challenger. Okay. So this would conclude this session. I would say let's thank all the speakers again. See you after lunch break.