I work for a software protection company. We have a White-box cryptography product. Setting aside the ambiguity of a term like "serious cryptographers," the b

I work for a software protection company. We have a White-box cryptography product. Setting aside the ambiguity of a term like "serious cryptographers," the best I can do is point you to this overview of the field: http://homes.esat.kuleuven.be/~bwyseur/research/wbc.php http://homes.esat.kuleuven.be/~bwyseur/research/wbc.php For a more approachable introduction, see http://rdist.root.org/2007/03/23/protecting-the-protection-code/ http://rdist.root.org/2007/03/23/protecting-the-protection-c... Nate Lawson (the author of that post) designed the protection scheme for Blu-Ray DVD's. One of the key features of Blu-Ray's DRM scheme is that it is renewable -- breaking one DVD's protection does not lead to breaking all protections. A closely related field that will be very interesting to see develop is homomorphic encryption: http://en.wikipedia.org/wiki/Homomorphic_encryption http://en.wikipedia.org/wiki/Homomorphic_encryption. I believe homomorphic encryption is taken seriously by cryptographers, and it will help in certain situations where Eve is Bob. There are published algorithms for white-boxing DES and AES, with corresponding papers discussing how to break those implementations. The general idea behind the publicly disclosed algorithm is to compose portions of the operation into a series of table lookups. If you're familiar with AES, think of it as the s-box transformation and the AddRoundKey transformation happening simultaneously in one lookup table. Add to that lookup tables that perform random, bijective mappings throughout the decryption operation. That gives you a feel for how one implementation works. It ends up with the same output as stock AES, just implemented in a completely different way. The canonical attack involves fault injection. Basically, the attackers inject bad data into the state matrix during the operation. By mapping the error propagation throughout the decryption process, they are able to recover the key through some pretty heavy analysis. If you really want the details, take a look at the paper. If you add tons of obfuscation, anti-debugging, code checksumming, and self modifying code to that library, it becomes a nightmare to figure out what is going on. DRM libraries, like malware samples, actively fight back against being examined. Now, add on top of that the fact that you are trying to launch a statistical analysis attack of the data being produced and it becomes a very hard problem. All that explanation is simply to say that using DRM in this scenario is about more than keeping honest people honest. It really is about preventing that one Eve from creating something for every Bob to consume.