UCLA computer grad constructs “crown jewel of cryptography”
acm.org
acm.org
In fact, the article is only about indistinguishability obfuscation. What is mostly discussed in this thread is the notion of virtual black box obfuscation (VBB). VBB has been proven to be impossible in the general case (see https://www.wisdom.weizmann.ac.il/~oded/PS/obf4.pdf). There are a few special programs where VBB is feasible, such as point functions, but in general in cannot be achieved.
Indistinguishability obfuscation (iO) means that if you obfuscate two programs that compute the same function, then you cannot distinguish them. Or put in different words, if you get two obfuscated programs, then there is no better way than random guessing (except for a factor that is negligible in some security parameter) to find out if they stem from the same original program.
1. VBB would be making it so you can't glean information about A or B by running VBB(A) or VBB(B) or examining them, for various definitions of "information".
You can't tell A is a bubble sort at all, and you can't tell B is a selection sort at all.
VBB is, as mentioned, impossible in the general case.
2. IO would be making it so if you are holding IO(A) and IO(B), you can't tell them apart, and can't tell if the original was A or B.
So you can have functionally identical programs, and when you run them through IO, you can't tell whether the original was A or B.
See the formal model here: https://en.wikipedia.org/wiki/Circuit_(computer_science)
There are extensions of iO to RAM programs, but this is not it.
That doesn't make any sense. You can trace them while they execute, then compare and analyze the two traces?
By definition obfuscation is always reversible or the software wouldn't even work any more.
You can make it infeasible (timewise) to figure it out, but it's still possible, even if it takes infinite time.
Or what is it for?
And how does it deal with timing? İf two programs I gave it have different complexity, would it pad the running time to some fixed value? İf so, how is that value chosen?
> Or put in different words,
I don't see how the second phrasing follows from the first one. In fact, I don't understand what the second statement is supposed to mean to begin with. Could you elaborate?
Roughly: VBB is the ability to take any program and make it indistinguishable from random.
IO is the ability to take two programs that compute the same function and make them indistinguishable from each other.
For example, if I plot how long both programs take at various scales, at some point I should be able to determine which one is O(n log(n)) right?
It is about what information you can glean about either of the originals. Formally (from the paper):
Indistinguishability: For every two ensembles {C0,λ} and {C1,λ} of polynomial-sized circuits that have the same size, input length, and output length, and are functionally equivalent, that is, ∀λ, C0,λ(x) = C1,λ(x) for every input x, the following distributions are computationally indistinguishable:
{iO(1λ, C0,λ)} {iO(1λ, C1,λ)}
I don't understand. Shouldn't a different secret key yield a different function / circuit?
https://eprint.iacr.org/2013/454.pdf and friends have a direct description of the latter and references to the former.
This is just one mechanism.
This thesis says that it's possible to obfuscate code in such a way that there is a lower bound on the level of effort needed to de-obfuscate it. That lower bound can apparently be comparable to the level of effort required to break a cryptosystem.
So, coming soon, viruses and worms nobody can figure out. Code where no one can tell if it has a backdoor. ML classifiers where no one can be sure what they really do.
What you are worried about is VBB (roughly can i take a program a and obfuscate it in a way that you get no information about the original from the obfuscated version), which has been proven impossible.
This is about indistinguishability, which is a form of obfuscation, but not the kind you are thinking about.
This is really something like "If you have two programs a and b that compute the same function, it's possible to obfuscate them in a way that the resulting programs are indistinguishable from each other"
So if program a is "bubble sort" and program b is "selection sort" (function here is the mathematical sense, so these compute the same function), obfuscation can make it so you can't tell them from each other, and you can't tell if the original program of what you are holding was bubble or selection .
Roughly: VBB is the ability to take any program and make it indistinguishable from random.
IO is the ability to take two programs that compute the same function and make them indistinguishable from each other.
"compute the same function" is actually what makes it feasible :)
The original use case was really trying to turn secret key systems into public key systems by hardwiring the secret key into the program and then obfuscating it.
So an example use case today would be "every DVD decoding program has a different key but computes the same function, can you make them all indinguishtable and thus hide the key" or something like that.
Wow, that definitely qualifies as a "crown jewel." I, for one, would not look forward to a future in which software running on my hardware is able to hide secrets, like one-off media encryption keys, from me!
Now, it happens for a lot of those we don't need iO and iO may be impractical, but as a theoretical building block, it's quite nice.
As for your concern, yes, this is now possible, at least in the sense that you do as good as is possible to do in making them computationally indistinguishable. This does not prevent you from attacking it in other ways :)
Two things, good or bad depending on how you look at it:
1. You can prove iO is as least as good as the best possible obfuscation scheme that can ever exist. So whatever that enables you to do or not, it's the limit.
2. It also means you can get away with handing over less secrets, ensure better isolation, etc.
The following things are possible with iO (trivially so), due to this paper:
Adaptively secure succinct garbled RAM - which would let you hand secure databases to untrusted providers and not worry about it.
Sender deniable encryption where you can't prove what the original plaintext was and various options are equally likely.
Fully deniable interactive encryption where secrecy of communication is protected even if the parties are later coerced (or willingly bribed) to expose their entire internal states: plaintexts, keys and randomness.
etc
These are just some examples.
Now, some of this, as I said, we know how to do already, some we don't. But this paper gives you iO as a building block that can do them without having to separately prove that it is as sound and secure as existing crypto systems are.
Again, iO only provides computational indistinguishability, not other things, but it is a nice primitive.
Everything you write makes sense to me -- though I had to lookup and skim Canetti and Holmgren's work to understand the bit about succint garbled RAM.
We live in interesting times!
That future is already here for most people. See things like Secure Enclave or Intel's SGX.
virus writers vs anti-virus code.
game hackers vs anti-cheat software.
license checking code vs cheapskates.
Stuxnet.
> Code where no one can tell if it has a backdoor.
Back in 1984, Ken Thompson wrote Reflections on Trusting Trust [0]. The short answer is "no, you can never ever tell if it has a backdoor. Ever."
> The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode.
Back in the 90s, I was interested in hacking. The sort of hacking that starts with "this is the disassembler. Step one, hack the trial version of IDA Pro." It was fascinating at the time (and bores me now, my punishment for growing up, I guess) so I read & did lots of stuff like that.
0 - https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
You should require positive proof that code does what you want.
Similar to how eg Haskell's type systems doesn't have to solve the halting problem [0]: it just rejects some programs that would be ok, but don't conform to the type system.
See also proof-carrying code. https://en.wikipedia.org/wiki/Proof-carrying_code
[0] Ok, unless you use undecidable instances or something like that.
That's just saying you should only ever solve simple problems with your computer.
First, for already closed source programs the obfuscation results don't make a difference at all. They remain just as obscure before as they are now. (Unless you routinely try to de-compile all closed source programs?)
The obfuscation result in the submitted article really only makes a difference to open source programs.
But: thanks to advances in mathematics and cryptography, a vendor can prove to you that their program does what it's supposed to, without having to reveal the source code or anything else about the program.
That's even harder problem to solve
Mobile apps also typically have tightly controlled permissions these days.
And, of course, people don't typically review most softwares's sources anyway. They rely on trust and reputation.
I'm not sure what you would do with a zkp of each input and output of the program?
Unlike a Turing machine, a circuit is finite. All circuits are "solveable" (given a outputs, compute an input which yields them) by trying all the input patterns.. There's no undecidability and no halting problem. There's just difficulty. "Difficult" here means there's no way easier than trying all the patterns. This is the same property sound cryptosystems are supposed to have - there's no easier way than trying all the keys.
Whether this result can be extended to programs with iteration I'm not sure. The paper doesn't seem to mention iteration or storage.
The class of circuits in question is P/poly which includes BPP (which includes P, the class of polynomial-time programs). So the result is quite general, since most practical programs are in P.
For an introduction to complexity theory, see Arora, Barak (2009) (Draft available here https://theory.cs.princeton.edu/complexity/book.pdf ); same Barak that did the presentation "On the (Im)Possibility of Obfuscating Programs" (2001) mentioned in the abstract.
As shown by the DRM schemes used in modern games, this type of obfuscation comes at the cost of performance: Unless you want to compute a sensitive function at the user's end in an obfuscated manner, it'd be much simpler to just run that function on your end and optimize it in terms of running costs & performance.
Such a design would also runs counter to the everything-as-a-service model that companies are trending towards, as it places more power back at the user's end, even if the user can't decipher the obfuscated function's inner mechanisms. Such a design would reduce the need to phone home, and thus the need for EaaS.
Unfortunately, the biggest industrial use case is making wi-fi routers that are absolutely impossible to install OpenWRT on, etc...
I was feeling crazy after reading that.
There's no way to know. But the NSA (at least) has a documented history of making crypto breakthroughs and keeping them secret (e.g. public key crypto: https://en.wikipedia.org/wiki/Public-key_cryptography#Classi..., differential cryptanalysis: https://en.wikipedia.org/wiki/Differential_cryptanalysis#His...).
And yet the machines we can actually build are far closer to LBAs than TMs.
I think Saberhagen's Berserkers actually had this feature.
Yes. Code decoded other code, etc. So if the code wasn't running normally, it couldn't be analyzed. It was handwaving back then, but it may become real.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
Yet I think the utility of encryption is well-demonstrated, and not just theoretical. It can be used by good people to defend against adversarial intent. And it may well be that obfuscation (in its most direct application) has the same effect. (e.g. companies sharing proprietary algorithms for you to run at home, without revealing the secret sauce; or me delegating computation to AWS without revealing secrets)
Note that this is not why indistinguishability obfuscation (iO) is a crown jewel, here. Practically, iO is nowhere close to obfuscating anything larger than a tiny circuit. But it can still be useful to do things like obfuscate secret keys when designing cryptographic protocols. Theoretically, iO allows us to derive essentially every cryptographic primitive, which is why this paper is interesting, and why iO is called a crown jewel. And now, we can build iO for the first time from well-studied hardness assumptions.
There is a huge difference: Encryption is used to hide something from a third party, while obfuscation is used to hide something from the intended recipient.
Or, if you'd like to argue that the intended recipient is the computer, not the user: To turn that computer into a deputy of the sender, while still formally belonging to the recipient.
No. Most obfuscation is done to increase the time needed to reverse the source of publicly available programs. Not the user (99% of the recipients) but the adversary is the intended target. The users are just cought in the crossfire.
Unless you consider every user of apps as someone who has both the skill and the need to reverse engineer your app.
So to stop the intended recipient from deciphering the program.
"Adversaries" are the strawman used to hurt legitimate customers who are left with black boxes for device drivers and no functioning hardware since the manufacturers make it impossible to open source firmware updates.
I share the sentiment that in most cases it just serves DRM vendors and is disservice to users but that's not all the cases.
It's easy to argue that everyone has legitimate interest in hiding some things in data, but what would be a legitimate case for hiding things in code?
The reason coca cola doesn't use Pepsi's recipe isnt because mixing the ingredients under heat creates an irreversible mixture that you can seperate to find the recipe. They don't use pepsis recipe because its illegal.
Edit: it's also trivially not true for trade secrets in the legal sense -- if you upload your trade secret willingly to AWS, it's no longer a trade secret, unless you have extra contracts in place. With obfuscation, you could skip a lot of red tape to keep it secret.
Intent matters.
> Why encrypt your messages, unless you're sending something sketchy?
Because I am sending something private, I can't believe people bring this dumbass argument still, and even here.
> Why obfuscate programs, unless you're hiding something?
Why indeed. This one is the red flag, not message in your e-mail client being encrypted. Again. Intent, and context, matters.
It can’t be about applications, because I can come up with a thousand applications for obfuscation with benign intent. Such as delegating private computation to AWS without Amazon learning my personal information.
Ah, thanks. That's far from clear in the article.
If BB(6) took years to execute, how long would you have to spend feeding random input to a suspected-hostile 10000 symbol Turing machine (whose source code and state you can't examine) in a sandbox before you decided it was safe?
I'd imagine if all code were to be perfectly obscured then to the public it wouldn't matter, but many would demand for more open source and that'd be the only way to trust.
Seems like there is an opportunity for bot nets to perform computations, say BTC mining, in a completely sealed and zero-knowledge environment, which now may not even need a backdoor or are able to hide it perfectly.
Sandboxing and modeling interaction are still possible and useful, and is a large part of figuring out viruses and worms. That's not going away
The malware seems trickier. Maybe systems will need to require proof of unobfuscated source to run code?
[1] https://en.wikipedia.org/wiki/Indistinguishability_obfuscati...
This work, on the other hand, shows a provably secure construction for obfuscation (assuming that some assumptions about the hardness of various well-studied mathematical problems are true). In other words, extracting a bitcoin secret key from an obfuscated algorithm is as hard as insert math problem here. (This is how all cryptography works; e.g. breaking RSA encryption is as hard as factoring large products of primes.) This paper is special because, for the first time, the hard math problem they use (to build the obfuscation) is "reasonable": they've been studied for decades, and no one knows how to break them. (Indeed, a lot of cryptography is built on top of the same assumptions/problems.)
Thus, we would be surprised if someone extracted our bitcoin secret key from our obfuscated program, because it means they solved some "thought-to-be-unsolvable" mathematical problem. This is a much nicer guarantee than the alternative, e.g. with current obfuscation, where we say "oh, it looks pretty random, let's stick my key in" and then trusting that no one will break it. (That's a lot of trust, when you might have a 100,000 Bitcoin at stake.)
Of course, none of this is really feasible; at best, we can securely obfuscate tiny circuits (in the present time). So the main utility is probably to hide keys and the such, not to obfuscate entire programs. This might enable better secure MPC schemes, NIZKs, etc. So I guess, per your question, it's also targeted towards a different use case.
Now, as to why theoretical cryptographers care about obfuscation in general: it's not so much about the direct application of obfuscating programs. (It's not obvious why obfuscation is more interesting than encryption, etc, from an applied point of view.) Instead, from a theoretical point of view, if we can build indistinguishability obfuscation, we can directly build public key encryption, non-interactive zero knowledge proofs, Multiparty computation, etc. etc. (assuming one-way functions). So really, this is a primitive that somehow connects all of the other primitives, which is why theoreticians think it is a big deal.
I can't remember where I read this, or if it was just a hypothetical, but I think I heard of people doing this deliberately as a sort of canary. If the wallet gets drained, then you know someone cracked your obfuscation.
I guess just encrypting the key won't let you use it to sign things.
Another possible use is in cloud computing. You could prepare a program with private information in it and still safely submit it to a third party to execute. This would also be very useful with smartcontracts. Since the smart contract code is public it can't contain any secrets unless it's safely obfuscated.
As I understand it we are still quite a way off from any of these techniques being feasible, since the overhead at the moment is huge.
> Program obfuscation would enable a host of useful applications: For instance, you could use an obfuscated program to delegate particular tasks within your bank or email accounts to other individuals, without worrying that someone could use the program in a way it wasn’t intended for or read off your account passwords (unless the program was designed to output them).
I relate this to cracking; run a program and watch the memory, see where the password is checked and edit the binary at that location to bypass. So this level obfuscation would make that impossible? Seems like magic honestly.
You can frustrate this by computing a very long hash and sprinkling the checks of the various pieces throughout the program's execution.
Sucks that DRM and user rights violations is about to get much much worse.
Homomorphic Encryption won't prevent you from decrypting other outputs (if you have a decryption key), and with Functional Encryption it's assumed both parties know the function being evaluated, so OTP is really the closest.
> established the feasibility of mathematically rigorous software obfuscation from well-studied hardness conjectures
Maybe you could obfuscate software eventually, but we don't have practical efficiency even for tiny circuits. It's a bit like saying how fully homomorphic encryption allows you to securely run "software" on someone else's computer: theoretically maybe yes, but in practice it's used within software to run very specific computations.
Indistinguishability obfuscation (plus one-way functions) implies basically every cryptographic primitive there is, including public key encryption, NIZKs, and MPC. It gets close to giving us FHE (open question, I think). In some sense it is a "unifying primitive". Absolutely a holy grail to cryptographers, even if it isn't for you.