5 ms·

Does anyone know of a decent introductory, authoritative text on cryptography? I haven't needed to know this stuff before beyond "use bcrypt because it's good,

Does anyone know of a decent introductory, authoritative text on cryptography? I haven't needed to know this stuff before beyond "use bcrypt because it's good, MD5 is rubbish", but have recently been given the task of generating license keys for our product. I would like to be able to test that what I've created isn't trivially crackable.

stevejalim 14y ago
I'm (still) a fan of http://www.schneier.com/book-applied.html http://www.schneier.com/book-applied.html
ChuckMcM 14y ago
Applied Cryptography is pretty much the standard.
zobzu 14y ago
gonna be fun when bcrypt will be "rubbish" and people won't understand that due to simplifications. Certainly is a good idea to inform yourself instead (despite the so called experts that will tell you not to even look at it) 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
- ptomato 14y ago
  Short of an extremely significant change in the way we do computing, my understanding is that you can just push up the work factor on bcrypt and be fine.
  - zobzu 14y ago
    We find logical issues that reduce the strenght of the algorithms every year or so, til now. You're saying that bcrypt doesn't suffer this and you can just add more rounds. That's sort of like adding more rounds to DES.
qubitsam 14y ago
Cryptography Engineering: Design Principles and Practical Applications.
pbsd 14y ago
To make license keys unforgeable, you have to go public key. Typically some sort of digital signature. This won't make your application uncrackable, but will make it impossible to fake legit licenses. 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".
mylittlepony 14y ago
Cryptography I by Dan Boneh (Stanford University): https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto 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.
- blablabla123 14y ago
  Is there something shorter? I mean something consisting only of 5 pages or so? My current knowledge (for web dev purposes) is this: sha1(md5(pw + salt)) is pretty safe. And I heard that doing the sha1 recursively is better. On the other hand my boss is convinced that is no good. 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.
  - throwaway125 14y ago
    http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ or PBKDF2 is also a good solution. the tl;dr version is: sha1(md5(pw + salt)) is too fast to be good, crackers can run millions of attempts per second if they have access to the hash.
    - stouset 14y ago
      TLDR 2; Stop inventing your own cryptography. This doesn't just mean "cryptographic cipher". If you're passing data into cryptographic functions and the parameter names don't conceptually match what you're putting in them, you're probably doing voodoo cryptography.
MichaelGG 14y ago
You're going to have to define "trivially crackable". Sure if you use a public key they can't create a keygenerator. After that, crypto has little use to you. 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.
- philbarr 14y ago
  For me, trivially crackable here refers to having someone who has read a basic text picking the license key out of the registry and going "hmm, that looks like a such-and-such key, I wonder what happens when I run it through this program here. Oh look it works, I think I'll just extend the date of the license to forever and tell all my friends." 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.
  - jerf 14y ago
    Step 1: Define what attack you are trying to prevent. 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.)
gknoy 14y ago
When I worked with people who wrote hardware crypto for a living, the book they recommended was Brush Schneier's Applied Cryptography [1]. It's __excellent__. It's the best technical book I've ever read. It's more readable than the Perl cookbook. 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-Algorithms-Source/dp/0471117099 http://www.amazon.com/Applied-Cryptography-Protocols-Algorit...

stevejalim 14y ago

I'm (still) a fan of http://www.schneier.com/book-applied.html http://www.schneier.com/book-applied.html

ChuckMcM 14y ago

Applied Cryptography is pretty much the standard.

zobzu 14y ago

gonna be fun when bcrypt will be "rubbish" and people won't understand that due to simplifications. Certainly is a good idea to inform yourself instead (despite the so called experts that will tell you not to even look at it) 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

ptomato 14y ago
Short of an extremely significant change in the way we do computing, my understanding is that you can just push up the work factor on bcrypt and be fine.
- zobzu 14y ago
  We find logical issues that reduce the strenght of the algorithms every year or so, til now. You're saying that bcrypt doesn't suffer this and you can just add more rounds. That's sort of like adding more rounds to DES.

qubitsam 14y ago

Cryptography Engineering: Design Principles and Practical Applications.

pbsd 14y ago

To make license keys unforgeable, you have to go public key. Typically some sort of digital signature. This won't make your application uncrackable, but will make it impossible to fake legit licenses. 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".

mylittlepony 14y ago

Cryptography I by Dan Boneh (Stanford University): https://www.coursera.org/course/crypto https://www.coursera.org/course/crypto 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.

blablabla123 14y ago
Is there something shorter? I mean something consisting only of 5 pages or so? My current knowledge (for web dev purposes) is this: sha1(md5(pw + salt)) is pretty safe. And I heard that doing the sha1 recursively is better. On the other hand my boss is convinced that is no good. 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.
- throwaway125 14y ago
  http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ or PBKDF2 is also a good solution. the tl;dr version is: sha1(md5(pw + salt)) is too fast to be good, crackers can run millions of attempts per second if they have access to the hash.
  - stouset 14y ago
    TLDR 2; Stop inventing your own cryptography. This doesn't just mean "cryptographic cipher". If you're passing data into cryptographic functions and the parameter names don't conceptually match what you're putting in them, you're probably doing voodoo cryptography.

MichaelGG 14y ago

You're going to have to define "trivially crackable". Sure if you use a public key they can't create a keygenerator. After that, crypto has little use to you. 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.

philbarr 14y ago
For me, trivially crackable here refers to having someone who has read a basic text picking the license key out of the registry and going "hmm, that looks like a such-and-such key, I wonder what happens when I run it through this program here. Oh look it works, I think I'll just extend the date of the license to forever and tell all my friends." 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.
- jerf 14y ago
  Step 1: Define what attack you are trying to prevent. 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.)

gknoy 14y ago

When I worked with people who wrote hardware crypto for a living, the book they recommended was Brush Schneier's Applied Cryptography [1]. It's __excellent__. It's the best technical book I've ever read. It's more readable than the Perl cookbook. 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-Algorithms-Source/dp/0471117099 http://www.amazon.com/Applied-Cryptography-Protocols-Algorit...