Live data from Hacker News

UCLA computer grad constructs “crown jewel of cryptography”

acm.org

61–70 of 145 posts

Re: UCLA computer grad constructs “crown jewel of cryptography”

#61
post #2

That is a fascinating result. A remarkable mathematical achievement. And a nightmare. 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…

Wouldn't this also be a field day for encryption maximalists?

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.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#62
post #60

Earlier quoted context omitted.

I mean, the same argument has been applied to other cryptographic tools. Why encrypt your messages, unless you're sending something sketchy? Why obfuscate programs, unless you're hiding something? 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)…

> I mean, the same argument has been applied to other cryptographic tools. Why encrypt your messages, unless you're sending something sketchy? Why obfuscate programs, unless you're hiding something? 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 c…

> while obfuscation is used to hide something from the intended 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.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#63
post #2

That is a fascinating result. A remarkable mathematical achievement. And a nightmare. 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…

Ah, "code is law". Good luck with that.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#64

Earlier quoted context omitted.

I mean, the same argument has been applied to other cryptographic tools. Why encrypt your messages, unless you're sending something sketchy? Why obfuscate programs, unless you're hiding something? 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)…

> I mean, the same argument has been applied to other cryptographic tools. Why encrypt your messages, unless you're sending something sketchy? Why obfuscate programs, unless you're hiding something? 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?

"This is a trade secret. We have not patented it, because it's so clever and valuable that it needs to be protected longer than a patent lasts"

Re: UCLA computer grad constructs “crown jewel of cryptography”

#65
post #22

Earlier quoted context omitted.

You'd still know what syscalls a cryptographically obfuscated userland program was making.

If it's a total black box, wouldn't the NOBUS thing to do would be to have some large key that it's watching input for that flips it into a malicious mode? 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?

Easy, have all executable segments read-only with none (or fixed) syscall instructions.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#66

Earlier quoted context omitted.

The code obfuscation that DRM implementations use is not provably secure. I don't think anyone would (or should) hide a bitcoin secret key inside of an obfuscated program. There's no formal guarantee of security. 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,…

How does obfuscating a key differ from encrypting it?

For example, we could write a program that hard-codes a secret key, and then signs bitcoin transactions with that secret key, but only if the transaction has value less than 0.5 bitcoin. Then anyone who has the program can sign things of small value on our behalf; if the program is indistinguishably-obfuscated, they won't be able to get any additional information about the key itself, or use it in any other way.

I guess just encrypting the key won't let you use it to sign things.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#67
post #38

DRM implementations already use code obfuscation heavily. Can someone with knowledge of the math clarify why this is a big deal? Why would it matter that there is mathematical proof that someone cannot figure out what the code is doing? How does it apply to crypto?

Imagine you wrote a decoder program with the key embedded in it. From looking at the program you can't work out what the key is, but you can use it to decode a secret message. You can have a secret encoder program too. Effectively blackbox obfuscation among other things allows you to turn symmetric encryption into asymmetric encryption.

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.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#69
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/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.

Re: UCLA computer grad constructs “crown jewel of cryptography”

#70

Earlier quoted context omitted.

Until it’s standard practice by all companies to protect up under the guise of consumer protection with all closed sourced software.

like that time sony gave everyone a rootkit: https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk...

similar to starforce for those that don't know: https://www.youtube.com/watch?v=p-wyIalhdPU
Post reply on HN