Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

UCLA computer grad constructs “crown jewel of cryptography”

acm.org

Post reply on HN
Print view View original

81–90 of 145 posts

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

#81

Post by Xelynega »

Brotkrumen wrote: post #64
yjftsjthsd-h wrote: post #53

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? 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"

Except we know(and have example from cryptocurrency) that the problems with ownership in real life have little to do with cryptography.

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.

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

#82

Post by Attrecomet »

eru wrote: post #73
Animats wrote: 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…

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.

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

#83

Post by ilyt »

eru wrote: post #73
Animats wrote: 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…

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…

> Just don't trust that code,

That's even harder problem to solve

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

#84

Post by ilyt »

Vervious wrote: post #34
hgsgm wrote: post #13

Earlier quoted context omitted.

Obfuscation is itself a malware signature.

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.

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.

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

#85

Post by Attrecomet »

Xelynega wrote: post #81
Brotkrumen wrote: post #64

Earlier quoted context omitted.

"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"

Except we know(and have example from cryptocurrency) that the problems with ownership in real life have little to do with cryptography. 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.

That's true for a recipe that was developed in a past millennium. Trade secrets are still very much relevant for companies that work with more modern technologies than soda from before the Great War, and a useful protection against competition. Even if you do believe that companies within the US or EU wouldn't touch other's IP with a 10 foot pole due to strong laws, you'd have to be very naive to think this is valid in all parts of the globe.

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.

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

#86

Post by neom »

hmmmcurious1 wrote: post #78

Weird how having research of this quality only lands you assistant professorship. The competition in academia is insane

It's not weird, it's how academia works, it's not even about competition, it's about putting in the work in a sustained manner. It's about proving if you can get funding (who do you know, how often do you publish, what type of publishing do you do), how long have you been teaching for, etc etc. In addition to experience, most institutions have specific criteria and expectations for promotion to full professorship... demonstrated record of excellence in teaching, multiple significant contributions to the field through research and active engagement in service and leadership roles within the academic community. This guy has a very very sparse resume. Just because he did one impressive thing doesn't mean anything in academia (thankfully).

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

#87

Post by codethief »

hkopp wrote: post #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/ob…

Thanks, I had no idea what to make of the OP, so your comment is very valuable!

> 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?

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

#88

Post by krageon »

Animats wrote: 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…

> viruses and worms nobody can figure out

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

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

#89

Post by zamalek »

ilyt wrote: post #83
eru wrote: post #73

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…

> Just don't trust that code, That's even harder problem to solve

Any program worth obfuscating is not worth trusting.

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

#90

Post by luxcem »

throwawayadvsec wrote: post #75
7to2 wrote: post #59

Does this mean we will be able to embed private keys and API keys in deliverables? (i.e. to cryptographicaly sign artifacts, APIs tokens, and other niceties). Sucks that DRM and user rights violations is about to get much much worse.

your API tokens could still probably get sniffed in the requests?

No because the requests are encrypted (with a public-key crypto method for example).
Post reply on HN