Hacker News new | past | comments | ask | show | jobs | submit login

They don't actually have to run portions of the game on the servers. They can just serve bits of logic code back to the client as certain milestones are met. You can easily cause 1000's of halting points in a program at the price of just a few kilobytes of data this way.

The point is not to make a game hack-proof. Just to make the time to crack long enough for your purposes. (In this case, it just has to last a few more weeks than ususal.) Safes are rated like this, partly by the worst-case time it takes to break into them. http://en.wikipedia.org/wiki/Safe

EDIT: I see from other posts that AC2 has been cracked since 2 weeks before release. In the case of safes, the laws of physics are on your side. In the case of general purpose Von Neumann architecture computers, the mathematical laws are on the side of the crackers.

In short, if you can execute it, you can read it, therefore you can crack it. To work perfectly, which is equivalent to working at all, DRM needs a "trusted" execution environment supported by hardware. Even a server environment is not going to cut it.




It's not settled computer science that the content protection problem always favors attackers, although it's clear that the state of the art does.

I'm only reacting to the "laws of physics" comment you're making. It's not true that "if you can execute it, you can read it", at least for important definitions of "read" (that include "understand" or "modify"). Take, for an example, white box cryptography.

Some problems clearly favor attackers (executing code on general purpose shared Von Neumann architectures with general purpose operating systems). Other problems favor defenders (the halting problem). It's also the case that, smart as (say) 'DarkShikari is, high-end performance graphics and systems coders are not necessarily expert practical compiler theory people.


What would be a summary of that part of "White Box Cryptography" which is new and distinct from the software obfuscation techniques that have been around for most of the history of programming? Is it more than just a bit of mathematical formalism applied to such? That's all I can tell at a first glance.


Within the context of this discussion: WBC on AES would mean that one would be able to execute a white-box AES software implementation, but would not be able to "read"/extract the secret key that is used.

Basically, WBC is a set of very dedicated obfuscation techniques to implement a cryptographic scheme in a "secure" way.

IMHO, The main disction with "usual" obfuscation is the following:

* Obfuscation is a computer science term that refers to hardening a given application, such that it is difficult to reverse engineer. That is, to make it difficult to understand what functionalities are implemented, and how.

* In white-box cryptography on the other hand, an adverary will know that a specific scheme (such as the AES) is implemented, and how it is implemented: the compiler and program specifications are public; the cryptographic key, and the randomness that is used at compilation-phase is private. This is similar to the Kerckhoffs-principle in cryptography, where the security of a scheme should not break down when the specifications of a scheme are known.

There have been some attempts to formalize white-box cryptography. See https://www.cosic.esat.kuleuven.be/publications/article-1260...

If you have any further questions, feel free to contact me. In the near future, I plan to setup a webpage on http://www.whiteboxcrypto.com where I will adress these issues, and explain how WBC works.

Best regards, Brecht Wyseur


That's a hand-wavy comment. AES is just a bit of mathematical formalism away from XOR.


It's a legitimate question by a curious onlooker who's was just introduced to the whole concept of "White Box Cryptography." Apparently there's not a whole lot of proofs, though I perhaps it's plausible to get something useful proved.

Hopefully for it, your (non) answer is not telling.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: