UCLA computer grad constructs “crown jewel of cryptography” • Hacker News Board

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

#71

Post by blurbleblurble » Thu, May 25, 2023, 7:32 AM UTC

amoss wrote: post #63

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…

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

Just wait until the legislators catch wind of this.

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

#72

Post by gmerc » Thu, May 25, 2023, 8:07 AM UTC

But does it withstand a powerful LLM attack? Because cursory tests on existing commercial code obfuscation solutions so far look like it’s clubby baby seals for them LLM

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

#73

Post by eru » Thu, May 25, 2023, 8:12 AM UTC

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 something like that.

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

#74

Post by derrida » Thu, May 25, 2023, 8:17 AM UTC

1 year old

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

#75

Post by throwawayadvsec » Thu, May 25, 2023, 8:33 AM UTC

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?

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

#76

Post by eerikkivistik » Thu, May 25, 2023, 9:16 AM UTC

So wait, doesn't this also indirectly imply that we will never be able to decipher neural networks of sufficient size for the general case?

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

#77

Post by denton-scratch » Thu, May 25, 2023, 9:23 AM UTC

The article doesn't explain what "indistinguishability obfuscation" does, nor why it is the "crown jewel of cryptography".

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

#78

Post by hmmmcurious1 » Thu, May 25, 2023, 9:41 AM UTC

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

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

#79

Post by denton-scratch » Thu, May 25, 2023, 9:58 AM UTC

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)…

> and why iO is called a crown jewel.

Ah, thanks. That's far from clear in the article.

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

#80

Post by Xelynega » Thu, May 25, 2023, 10:13 AM UTC

consp wrote: post #62

moring wrote: 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? 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…

> No. Most obfuscation is done to increase the time needed to reverse the source of publicly available programs.

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.