The first third (half?) of the book is devoted to explaining (not with code) the various complex interactions between parties who need to trust one another -- lots of stuff on key exchange, and then only later on the different types of ciphers (block vs stream ciphers). The examples are clear and well-written, and VERY memorable. Bruce explains very well what the pitfalls are in each scenario, and all the ways in which malicious attackers can try to break your trust.
The second half of the book is implementation of most of the algorithms in C.
Other books may cover the topic be better, but I haven't read them. (Sorry.) I like that Applied Cryptography gives a good noob-friendly introduction, and builds from there, yet also has depth and source code.
1: http://www.amazon.com/Applied-Cryptography-Protocols-Algorit...
A user can just open your binary and flip the jump that checks if the license is good or not. Do you really want to start wasting time making your software vastly more complicated, in order to try to lock out crackers? If the software is remotely desirable or common, it'll get cracked.
If someone wants to go and disassemble the app and read all that machine code to find the bit to flip then there's not much I can do about that I think.
Are you just trying to keep honest people honest? Then just about anything will work. Are you trying to prevent hard-core hackers from cracking your work? A whole bunch of very good people have been working on that problem for a long time and failed.
It is likely that the most dangerous licensing system you can produce is one that routinely false-positives a real user as a pirate. They will cease to be real users in the future. In general, pirates weren't going to be real users anyhow. (There are some exceptions, mostly in the games world, but in general it seems to be true.)
If you can swing it, the most bang-for-the-buck you can get for protecting your work is to not actually ship all of it; provide some sort of critical element that lives on a server somewhere under your control. This can be tricky in some cases, because you really ought to be able to say with a straight face that there's some sort of value-add resulting from that. And that has availability and growth consequences as well. But it works, it's simple (relatively speaking), easy-to-understand, and extremely difficult to bypass. (Still technically not impossible, in some sense, but you've raised the bar beyond what all but the most dedicated attacker will bother with. Cracking is fun; reimplementing a backend service by examining only the data going in and out, well... I can't say that's not fun, but it's fun for a much more select group of people, most of whom are probably using those skills to make real money somewhere.)
Take a simple checking function. Check the code, if it is wrong, show a message box saying "wrong code". Well, in that case, all you gotta do is set a breakpoint and go back. Programs like OllyDbg or IDA Pro make this kind of reverse engineering absolutely trivial, and something you can accomplish after "reading a basic text".
Most likely if someone's going to "run a program", they can run a crack, too. If you can get away with a license file, then you can do RSA properly. Otherwise, end up with short RSA and hope no one really looks.
It's almost certainly the case that you're far better off improving some other aspect of your application than investing any time trying to defend against pirates.
http://www.atrevido.net/blog/PermaLink.aspx?guid=ec99e239-89...
1. People quickly figured out that the key generator just verified RSA signatures.
2. Since he implemented RSA by hand (I guess calling OpenSSL's RSA_INIT() would be too "obvious") it had bugs. Specifically, it didn't check that the signature in the key was strictly below the key modulus, meaning that given signature X, you could add the modulus to get a new valid signature.
3. Since the license keys can't be ridiculous long pieces of text, the key was not long enough. Someone went to a website online and pasted the key into a Java prime factorization applet and cracked it, posting a key generator.
There is always a tradeoff between security and usability. Unfortunately, the tradeoff here is prohibitive: if you use a 1024 bit key and base 32 encoding, your users will have to type in a minimum of 205 characters to enter the product key. Base 32 is the densest reasonable encoding for human input, or close to it.
So the lesson is that even the simple requirement "can't create a keygenerator" is an open problem.
A good reference on how to get these things right is Schneier et al's 'Cryptography Engineering'. The standard advice line here, however, is "get professional help".
I always liked www.amazon.com/Code-Book-Science-Secrecy-Cryptography/dp/0385495323/ as beginner introduction, before going on to more advanced books. it gives you all the basics, and the basics are imo the most important to get right (that's why they're basics), plus its a fun read
That's sort of like adding more rounds to DES.
The videos are probably available for download somewhere else, so you don't have to wait. Someone posted a site here on HN that saved all the coursera videos, but I can't remember the name.
Each video lasts ~20 min if I remember correctly, but they are very intensive. I never wanted to watch more than one or two per day, my mind would have blown.
Of course I did a bit of research (ok, only 30-60 minutes on Google ;)) and didn't find anything presenting a sweet and simple solution.