 Thank you for tuning in to this talk on the impossibility of quantum virtual black box obfuscation of classical circuits. My goal today will be to argue that it's impossible to securely construct a certain cryptographic primitive, and that primitive is some variant of the obfuscation primitive. An obfuscation seems to be an extremely powerful primitive, and so it has gotten a lot of attention already in the crypto community in the last years, and you may have already heard about it many times. But just in case you haven't, I will give you some intuition. Informally, the obfuscation of a program, for example, this Hello World program, is another program that does exactly the same thing, but somehow it is less intelligible. So if you run this long piece of code in blue, you will also print the text Hello World. So it's functionally equivalent, but that's very hard to tell just by looking at this code. And a good obfuscation reveals nothing more about its functionality than what you can already learn from actually running it and just observing the input-output behavior of the program. One observation that will be crucial for today's talk is that the obfuscation of a program does not necessarily need to be a program itself. There is no fundamental reason why it couldn't be, say, an image, together with some public instructions on how to interpret that image, how to run the program that's encoded by that image. Or why couldn't an obfuscation be a quantum state that you can interact with in order to execute your program? So when I say obfuscation of a program or of a circuit, I really mean it to be any possible object. After this informal definition of obfuscation, let's take a look at the plan for this talk. I'll first formalize the definition of the type of obfuscation that we're looking at today, the virtual black box obfuscation. Then I will walk you through the ideas behind a famous proof which shows that it's impossible to obfuscate programs into classical objects according to this definition. And then I will move on to our contribution, which was adapting that classical proof to show that a wider notion of obfuscation is also impossible, namely that we cannot even obfuscate classical programs into quantum objects. And finally, I will put our result into some context of previous and concurrent work and comment on some open questions. OK. The formalization of obfuscation that we will be interested in today is called virtual black box obfuscation. And it is as follows. An obfuscator O for some family of classical circuits F is an algorithm such that the following three things hold. First, the obfuscation of a circuit is not too big. It's polynomially related to the size of the original circuit C. We call this polynomial expansion. Second, if the obfuscation is itself a circuit, then that circuit is functionally equivalent to the original circuit C. And we can generalize this second point whenever O of C is not a circuit but any other object. Then we need to add a publicly known interpreter, J, to the definition. And J just contains instructions on how to use the obfuscation object. Functional equivalence then becomes if the interpreter is run on the obfuscation and input X, then it should use the correct outcome C of X. And note that O of C can also be a quantum state, like I already mentioned. And in that case, this polynomial expansion property talks about the number of qubits in OC. And third, for security, we use the virtual black box property, or VBB, which says that any efficient adversary that received an obfuscation of C, so O of C, and outputs a single bit can be simulated by an efficient simulator that does not get the obfuscation at all, only the size of the circuit, but has oracle access to the functionality of the circuit. So essentially anything you can learn about the circuit from the object O of C can also be learned from querying the oracle for C, polynomial number of times. And if O of C is a quantum state, then the adversary and simulator are also considered to be quantum algorithms, of course. And the simulator still interacts with the classical oracle because the functionality of C is still classical, but it can then query it in superposition. So that's something to keep in mind. To get some intuition for how hard it is to satisfy its third property, the VBB property, let's consider the difference between getting O of C as an input or just interacting with an oracle for C. And getting O of C as an input is quite significant because it allows the adversary to manipulate this object. It can dissect it into pieces, for example, or it can make changes to it and see what happens. So as an example, think again of this pictorial obfuscation from earlier. You could try to see as an adversary what happens to the input output behavior if you change a red area into blue or if you run the interpreter on the upside down version of the image and so forth. And the simulator, on the other hand, really only sees inputs and outputs and cannot do all of those things. And for some function families, like learnable functions, the difference really doesn't matter. Those function families are obfuscatable in the VBB sense, but for some more general function families, the adversary can take advantage of having an object to manipulate. And those function families are not obfuscatable. In 2001, Barak et al showed the existence of such unobfuscatable function families. And they did so by defining circuits where the adversary could really take advantage of the fact that they held this concrete obfuscation object in their hand and that they could break it up into individual parts or individual gates. And since our result will be a generalization of this classical impossibility result, I will explain some details of this unobfuscatable family that they defined. It will be a family F of circuits parameterized by an alpha and a beta. And the family will essentially consist of two types of circuits, a type that we will call C alpha beta and a type that we will call Z alpha beta. In total, this is still a subset of all polynomial-sized classical circuits, but if one can show that already this subset is unobfuscatable, then certainly the set of all poly-sized classical circuits is also unobfuscatable. And Barak et al then defined an algorithm A such that for all simulators S, the following holds. If the adversary receives an obfuscation of the first type of circuit, C circuit, it will almost always output one. If it instead receives an obfuscation of the second type, it will almost always output zero. So the adversary will almost always be able to tell the difference between a C and a Z circuit. And at the same time, they show that with just Oracle access, it is impossible to tell the difference between the two types of circuits. So no simulator can tell this difference. And now towards this contradiction, suppose that this entire class would be obfuscatable. That would mean that there is a simulator that can always simulate the output of the adversary. So both if the adversary got a C or a Z circuit, the simulator would be able to simulate its output. But that leads to a contradiction because no simulator could correctly output one whenever the adversary outputs one on a C circuit. And at the same time, output is zero whenever the output is zero on the Z circuit. Because that would mean that the simulator would be able to distinguish. This is a general structure of the argument to show that this particular class F is unobfuscatable. And now of course, it just remains to find a definition of C and Z so that the adversary can tell the difference, but the simulator cannot. And that's what I will do now. So starting with C, each circuit of this type is defined for the parameters alpha and beta. And it's defined for three different cases determined by the first digit of the input. So if you give it input one, the function returns a fixed encryption of alpha. And this encryption is homomorphic, which means that anyone, even if they don't know the secret key, can turn the encryption of some value Y into an encryption of F of Y for any F of that choice. They do need to know the public key for this, which is why that is also returned upon input one. That's the PK. On inputs two comma X for some X, the function returns beta if and only if the other input X was equal to alpha. This is called a point function. It is zero everywhere except at the point alpha where it outputs beta. And on input three comma X, the function tests whether this other input X decrypts to beta. If it does, it returns one and otherwise it returns zero. This type of function is known as a compute and compare function. It computes a function on the input, in this case, the decryption function, and it compares the result with a target value, in this case, beta. Now, notice that if you have access to this functionality through an obfuscation of C alpha beta, you could first request an encryption of alpha, then turn that encryption of alpha into an encryption of beta by homomorphic evaluation of the second line of C and then input that resulting encryption into the third line to observe the output one. And for the homomorphic evaluation, it's crucial that you have access to the obfuscation for C, not just an oracle, because you want to run the homomorphic versions of each gate in that obfuscation. So you need to be able to see those gates, like break the obfuscation up into its individual gates, see those gates and run the homomorphic version of them. And if you do this on this circuit C, you will get output one out of the last line. Okay, now for the second type of circuit, Z, this circuit is identical to C, except for the second line. There, instead of a point function, it just always outputs zero. And what this means in particular is that since there is no connection between the alpha and the beta anymore, if you try the same tactic as before, your third line will always end up in the otherwise case. So outputting zero. You will not be able to recover an valid encryption of beta if you have access to the Z functionality, not even if you have a physical obfuscation in your hand. And what I've argued here is that an adversary, given obfuscation of either C or Z, can tell the difference. There is a way to make the C circuit always output one, and the Z circuit always output zero. And to complete the impossibility argument from the previous slide, you would have to still argue that a simulator cannot tell the difference between these two types of circuits if they're given only oracle access to them. I will not go into this during this talk, but essentially you can argue that a simulator would have to guess the plain text value of alpha and thereby it would have to break the encryption in order to tell the difference by querying the second line. Okay, so we established that classical circuits cannot be obfuscated into classical circuits, or you could even generalize these arguments and say that they cannot be obfuscated into any classical objects. But what about obfuscating classical circuits into quantum states? This is a potential way around the impossibility result from 2001, and it was already observed quite soon after that appeared and posed as one of the 10 semi-grant challenges in quantum computing theory by Scott Aronson already in 2005. It was only in 2016 that a luggage and featherman made some progress in adapting the classical proof, and they were able to show that classical circuits could not be obfuscated into something they call reusable quantum objects, such as quantum circuits. But the full general result of quantum states turned out to require some tools that we didn't even have back then. And then in this talk, I will complete their argument and show that obfuscating classical circuits into quantum states is also not possible. Our result generalizes this classical impossibility result, but it only holds under the variant of the learning with error assumption. The classical proof doesn't immediately work in the quantum setting anymore, and that's mainly for two reasons. First, the homomorphic evaluation. A quantum obfuscation would not be a classical circuit anymore. So we cannot just straight forward, we break it up into gates that we can homomorphically evaluate. It's not even a quantum circuit necessarily, it can be a quantum state. So how do you break it up into individual gates? For this problem, there's a pretty straightforward solution. And the reason is that I already slightly adapted the classical impossibility proof when I presented it to you by assuming that fully homomorphic encryption exists. At the time that the original proof appeared, this was not just established. So if you go and look at the original paper, you will find that C and Z were defined somewhat differently. However, with this current formulation, we can simply say, well, the obfuscation may not be a circuit that we can run homomorphically, but the interpreter algorithm is. The interpreter may be a quantum circuit though. So we do require quantum homomorphic encryption. The second problem is a little bit bigger and we call it reusability. So in the classical proof, we run this obfuscated circuit several times. First to retrieve an encryption of alpha, then homomorphically, and finally for the computing comparative encryption. If the obfuscation is classical, that's all fine, but if the obfuscation is a quantum state, it's not so clear that it's possible to just reuse it many times. For example, maybe the interpreter algorithm is supposed to measure the obfuscation state in some way or do other stuff that destroys the state during the computation. And to solve this, we do two things. First, we note that if the output one of those steps is classical and deterministic, we can just safely measure it without disturbing the state and then revert to the interpreter to retrieve the original obfuscation, which can then be used again. So for example, after we run the first line to obtain the encryption of alpha, that's always just the same fixed encryption. We can just measure it, then reverse the computation and we will get our obfuscation back. And the same thing holds for the third line where the output is always deterministically zero or one depending on your input. Of course, this doesn't work if the output is mixed, which it could be after the homomorphic evaluation of line two because then the output may be a superposition of ciphertexts. Maybe there's a superposition of all for the same value, beta, but still measuring that ciphertext before reverting may collapse the superposition over the different ciphertext and then disturb the obfuscation. And to get around this problem, we have to reshuffle the circuit C a bit to make the homomorphic evaluation step occur last. The change to the circuits C and Z that we make will be in the last line. So instead of it being a computer compare function itself on the input X, we let it return a fixed classical obfuscation of that computing compare function. So I haven't changed anything about the function within the brackets here. It's just that the circuit C doesn't compute that function itself, but it statically returns an obfuscation and this O sub CC stands for a classical obfuscator for the class of computing compare functions. This is a subclass for which obfuscation is not impossible and it does exist under some variant of the learning with errors assumption and it's secure as long as beta is sufficiently random. And the adversary can do almost the same tactic now and still distinguish between an obfuscation of C where it will get output one and an obfuscation of Z where it will get output zero. The only thing is that the order in which the adversary has two things is slightly different. As it starts again with running the first line to retrieve an encryption of one which is a deterministic action and then reverts. And then instead of running the second line homomorphically which could destroy the obfuscation state it runs the third line to retrieve the obfuscation of the computer compare function which again yields a fixed deterministic result so that too can be just safely reverted. And it just remembers the encryption of alpha and the obfuscation of this computer compare function and only then the adversary runs the second line to either get an encryption of beta if the obfuscation was of the circuit C or an encryption of zero if the obfuscation was of the other type of circuit Z. This action may destroy the state but that's okay because the only thing left to do now is to use the already retrieved information in the second step about the computer compare obfuscation to distinguish between the two types of circuits. And note that this small change to the circuits although it made a lot of difference for the visibility of the adversary strategy doesn't help the simulator at all. A simulator would still not be able to tell the difference between a C or a Z circuit. All right, so those were the two main changes we made to the classical proof running the interpreter homomorphically using quantum homomorphic encryption scheme and solving this reusability problem by introducing an obfuscation of a computer compare functionality so that we could change the order in which the adversary run the circuit. But if you were paying close attention you may have noticed some problem already in the way I presented the classical impossibility proof. So recall that the first line of C it returns among other things the public evaluation key for the encryption. Of course, if this key is longer the size of the total circuit C grows as well. And since we need to evaluate C homomorphically in one of the steps that means that the depth of that evaluation also increases and that requires more key again. And one solution to this kind of loop problem is to assume a circular security of the homomorphic encryption so that the length of the public key does not have to depend on the depth of the homomorphic evaluation then we can break this loop. But we get around this problem in a different way namely by slightly adapting the circuit C again. We define the notion of decomposable public keys and have the circuit C return small blocks of the decomposed key at a time. These blocks can be generated efficiently and their size is independent of the evaluation depth. The user can reassemble the blocks again into the original public key after requesting sufficiently many blocks and the blocks do not reveal any additional information. And in the proof there are some subtleties to consider. At the point in time where we have to fix the circuit class the size of the interpreter algorithm is not yet fixed. So we don't know an upper bound to the number of blocks that we'll need. And in the end we have to really carefully work around the quantifiers and construct a circuit class so that for any poly-sized interpreter there is some circuit in the class that reveals sufficiently many blocks. And this is still sufficient to show impossibility of quantum black box virtual black box obfuscation because there are circuits in the class for which the adversary will succeed but the simulator will not. Okay, to just summarize, it will compare a construction to the two earlier works on impossibility of obfuscating classical circuits, the classical Barok et al result and the quantum obfuscation paper by a luggage and peppermint. So the circuit class that we proved to be unobfuscatable is the class of classical circuits. 2016 results, the circuit class contained a quantum homomorphic evaluation step making the unobfuscatable class quantum. This is a broader class and therefore the resulting impossibility theorem was somewhat weaker. The type of obfuscation that is shown to be impossible is improved from classical circuits or classical strings in 2001 to reusable quantum states in 2016 and to the most general case of quantum states in our work. And the compromise that we have to make for this is that our assumptions are stronger than what was needed before. In the earlier works, they only needed to assume that one-way functions exist or quantum secure one-way functions in the 2016 paper. Whereas for our result, we need a quantum fully homomorphic encryption and on top of that, we also need the compute and compare obfuscation. And for those two ingredients, we require the assumption that a variant of the learning with errors problem is hard for quantum computers. We were able to get rid of the additional assumption that homomorphic encryption would need to be circularly secure, however. So in summary, we strengthened the impossibility result by showing that an even smaller class is unobfuscatable even if the obfuscation could be a quantum state. But we do that at the expense of a stronger but still standard assumption. I also want to mention some concurrent work by Rolando and La Placa who made essentially the same construction as ours in the context of secure software leasing. Their goal is slightly harder because for secure software leasing, they need to exhibit a circuit class where the adversary cannot just tell the difference between C and Z but can extract some meaningful information from the obfuscation enough to produce a copy of the functionality. So in that sense, the result that they achieve is stronger and more general. They do use a circular security assumption but we believe that it could be removed from their construction using our techniques. And to end this talk, I will give a bit of an outlook on possible future work. The first one is a bit fake but it may be possible actually to get rid of the LWE assumption that we based our result on. And to do this, you would have to do two things. You would first have to find an alternative for the quantum fully homomorphic encryption maybe moving some classical part of it back into the circuit so that it doesn't rely on the learning with errors assumption anymore. And second, you would also have to get rid of this compute and compare obfuscation finding a different solution for the fact that the obfuscated state may be destroyed after homomorphic evaluation or showing that it's actually not really destroyed. And on the possibility side, a weaker notion of quantum obfuscation might still be possible. So for example, indistinguishability obfuscation is not ruled out for impossibility result. And it is getting a lot of attention in the classical crypto world and lately also in the quantum crypto world. So maybe possible to quantum obfuscate classical or quantum functionalities in this weaker sense. That's all for now. I hope you enjoyed watching this video and I wish you a great rest of the conference.