Black-box Obfuscation

In cryptography, black-box obfuscation was a proposed cryptographic primitive which would allow a computer program to be obfuscated in a way such that it was impossible to determine anything about it except its input and output behavior. Black-box obfuscation has been proven to be impossible, even in principle.

Impossibility

The unobfuscatable programs

Barak et al. constructed a family of unobfuscatable programs, for which an efficient attacker can always learn more from ''any'' obfuscated code than from black-box access.

Broadly, they start by engineering a special pair of programs that cannot be obfuscated together. For some randomly selected strings $\alpha, \beta$ of a fixed, pre-determined length $k$, define one program to be one that computes

$C_(x) := \begin \beta & \textx = \alpha\\ 0 & \text \end$

and the other program to one that computes

$D_(X) := \begin 1 & \textX(\alpha) = \beta\textX\text\leq\text(k)\\ 0 & \text \end.$

(Here, $D_$ interprets its input as the code for a Turing machine. The second condition in the definition of $D_$ is to prevent the function from being uncomputable.)

If an efficient attacker only has black-box access, Barak et al. argued, then the attacker only has an exponentially small chance of guessing the password $\alpha$, and so cannot distinguish the pair of programs from a pair where $C_$ is replaced by some program $Z$ that always outputs "0". However, if the attacker has access to any obfuscated implementations $C'_, D'_$ of $C_, D_$, then the attacker will find $D'_(C'_) = 1$ with probability 1, whereas the attacker will always find $D'_(Z) = 0$ unless $\beta = 0$ (which should happen with negligible probability). This means that the attacker can always distinguish the pair $(C'_, D'_)$ from the pair $(Z, D'_)$ with obfuscated code access, but not black-box access. Since ''no'' obfuscator can prevent this attack, Barak et al. conclude that no black-box obfuscator for pairs of programs exists.

To conclude the argument, Barak et al. define a third program to implement the functionality of the two previous:

$F_(b, x):= \begin C_(x) &\text b = 0\\ D_(x) &\text b = 1\\ \end.$

Since equivalently efficient implementations of $C_, D_$ can be recovered from one of $F_$ by hardwiring the value of $b$, Barak et al. conclude that $F_$ cannot be obfuscated either, which concludes their argument.

Impossible variants of black-box obfuscation and other types of unobfuscatable programs

In their paper, Barak et al. also prove the following (conditional to appropriate cryptographic assumptions):

* There are unobfuscatable circuits.
* There is no black-box ''approximate'' obfuscator.
* There are unobfuscatable, secure, probabilistic private-key cryptosystems.
* There are unobfuscatable, secure, deterministic digital signature schemes.
* There are unobfuscatable, secure, deterministic message authentication schemes.
* There are unobfuscatable, secure pseudorandom functions.
* For many protocols that are secure in the random oracle model, the protocol becomes insecure if the random oracle is replaced with an artificial cryptographic hash function; in particular, Fiat-Shamir schemes can be attacked.
* There are unobfuscatable circuits in TC0 (that is, constant-depth threshold circuits).
* There are unobfuscatable sampling algorithms (in fact, these cannot be obfuscated approximately).
* There is no secure software watermarking scheme.

Weaker variants

In their original paper exploring black-box obfuscation, Barak et al. defined two weaker notions of cryptographic obfuscation which they did not rule out: indistinguishability obfuscation and extractability obfuscation (which they called "differing-inputs obfuscation".) Informally, an indistinguishability obfuscator should convert input programs with the same functionality into output programs such that the outputs cannot be efficiently related to the inputs by a bounded attacker, and an extractability obfuscator should be an obfuscator such that if the efficient attacker ''could'' relate the outputs to the inputs for any two programs, then the attacker could also produce an input such that the two programs being obfuscated produce different outputs. (Note that an extractability obfuscator is necessarily an indistinguishability obfuscator.)

, a candidate implementation of indistinguishability obfuscation is under investigation. In 2013, Boyle et al. explored several candidate implementations of extractability obfuscation.

References

{{reflist

Software obfuscation
Cryptographic primitives
Unsolvable puzzles