# Intuitively what makes indistinguishability obfuscation useful?

I am reading some papers about the application of indistinguishability obfuscators (IO). As far as I know, there are two techniques which enables the application of IO: shell game of secrets and punctured programs. It seems to me obfuscators are meant to make the program as close to a black box as possible, but it is known black-box obfuscation is not possible for some circuits.

I think the question is about how to force the adversary to learn by making queries. For example, standard PRFs are built upon black box model, and it is straightforward to prove the security based on some query complexity lower bound. To apply IO in the non-black-box case, PRFs are built to be puncturable to preserve functionality and randomness. Though I can follow the mathematical proof, I don't see why punctured PRFs along with IO makes the adversary see the program like a black box. Could anyone give me some intuition how IO programs differs from black boxes?

Bottomline: it is more appropriate to think in terms of indistinguishability rather than (black-box) simulation as indistinguishability obfuscation (IO) guarantees the former.

To see how IO can be useful, think of IO as a mechanism that "encrypts" the circuit (with the "encrypted" circuit being functionally equivalent to the original circuit), and its security requirement to be that for any two circuits that are functionally equivalent, the corresponding encrypted ciruits are indistinguishable.

In most applications of IO, the security argument involves showing that the adversary cannot tell the case where it is given the encryption of the actual circuit from the case where it is given the encryption of a "bogus" circuit. As certain crucial parts have been removed from the bogus circuit, an adversary cannot have a significant advantage in breaking the bogus circuit. (And since the encryption of the actual circuit is indistinguishable (by IO) from that of the bogus circuit, security ensues.)

The above uses two ingredients: punctured programs and hidden sparse triggers.$^*$ The bogus circuit is usually constructed from the original circuit by "puncturing" the underlying PRF at the challenge. As a result, the bogus circuit behaves "randomly" at the punctured point. This modification could, inadvertently, lead to the bogus circuit behaving differently from the original circuit (and the security guarantee of IO goes out of the window). The way-around is to ensure that the point at which the puncturing takes place is hard to find using, for example, a PRG (i.e., sparse hidden triggers).

The construction of public-key encryption (PKE) from secret-key encryption (SKE) given in [SW14,§1,§5.1] is an excellent example which encapsulates the usefulness of this approach, and which I'd reccommend for further reading.$^{**}$

$^*$To quote [SW14], "the idea of the technique is to alter a program (which is to be obfuscated) by surgically removing a key element of the program, without which the adversary cannot win the security game it must play, but in a way that does not alter the functionality of the program."

$^{**}$ This highlights another point of why IO is so powerful: it is known that PKE cannot be constructed from SKE in a black-box manner, but since IO uses the circuit of the underlying SKE, the constrcution is non-black-box and helps bypass the separation.

• Thanks. I had the question while reading [SW14], and the points you made helps. While I become more comfortable about punctured programs, some follow-up question arises from your comment: from the definition of puncturable PRFs, at punctured points the outputs are pseudorandom. I know GGM has the property, and I think this is critical to allow the PRF non-black-box (cf. the definition of PRF in oracle model). But isn't the evaluation pseudorandom defined upon the assumption that the adversary queries the function as if it is a black box? Commented Aug 17, 2017 at 18:56
• I am not sure that I totally understand the question, but the security definition for puncturable PRF (which is a particular type of constrained PRF) is quite different from that of a normal PRF. Commented Aug 17, 2017 at 19:39
• I wanted to make sure proving constructions using IO does not implicitly assumes the adversary has only oracle access to functions. Obviously if the adversary is given an obfuscated program, it can do more than just use it as if it is a black box. In the SKE-to-PKE example by [SW14], I was concerned about the PRF definition. After some thought, I feel there should be no such problem in the sense that the proof goes like "if the input-output behavior satisfies some properties, then no adversary takes advantages," as opposed to that the oracle distribution is pseudorandom in random oracle model. Commented Aug 18, 2017 at 19:19