131–140 of 145 posts
The precise mathematical definition of obfuscation and what is considered obfuscation for an average software engineer are two very different things. 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/ob…
The precise mathematical definition of obfuscation and what is considered obfuscation for an average software engineer are two very different things. 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/ob…
To try to make this concrete, if you have a program A that does bubble sort, and a program B that does selection sort: 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 cas…
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.
Earlier quoted context omitted.
Just don't trust that code, and don't run it? 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 somethin…
> You should require positive proof that code does what you want. That's just saying you should only ever solve simple problems with your computer.
Earlier quoted context omitted.
Just don't trust that code, and don't run it? 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 somethin…
Yes great so let's not use any software at all on our machines! only things we can program ourselves or are open-source. what a dystopia we live in...
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.
Earlier quoted context omitted.
Any program worth obfuscating is not worth trusting.
Among other things, tons of desktop software and most mobile apps and even javascript you run from most websites is obfuscated. How is it possible to avoid that? Do you run 100% open source for everything with javascript disabled?
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.
Earlier quoted context omitted.
Just don't trust that code, and don't run it? 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 somethin…
Wouldn't this be a great case for a sort of machine or program that delivers Zero Knowledge Proofs for each input and output?
I'm not sure what you would do with a zkp of each input and output of the program?
Earlier quoted context omitted.
Well, no. 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…
> 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. 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 !
That future is already here for most people. See things like Secure Enclave or Intel's SGX.
Earlier quoted context omitted.
> 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. 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 !
In practice, as the thesis proves, you can use iO to generate a lot of things people care about in cryptography. I will go out on a limb and say you can use it to build almost everything interesting :) 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…
For those, like me, wondering what this is about; > 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).…
You can frustrate this by computing a very long hash and sprinkling the checks of the various pieces throughout the program's execution.
The article doesn't explain what "indistinguishability obfuscation" does, nor why it is the "crown jewel of cryptography".