Handbook of Applied Cryptography(cacr.uwaterloo.ca)
cacr.uwaterloo.ca
Handbook of Applied Cryptography
https://cacr.uwaterloo.ca/hac/
22 comments
My experience is that a lot of people could learn what they need from a few pages of crib sheets. Symmetrical, hashing, asymmetrical, key lengths etc. As soon as you need to know more about the nuts and bolts of different systems, you are already straying into the territory of needing the really deep and mathematical treaties that some of these books represent.
How many Developers need to know much more than choosing between bcrypt/scrypt/argon2/pbkdf2/etc. for password hashing and the relative merits of each?
How many Developers need to know much more than choosing between bcrypt/scrypt/argon2/pbkdf2/etc. for password hashing and the relative merits of each?
Crib sheets (i.e. listing various flavors of encryption algorithms) IMO work reasonably well when people have a decent conceptual mindset to start with.
I strive to assume very little when it comes to the knowledge of I meet. With cryptography, even less so. For example, given some developers you interact with, to what degree do they understand encryption versus digesting? I'm not even talking about the details; I'm talking about the big picture of when each is applicable.
So, even before something like a crib sheet of techniques, some people would benefit from something even simpler: an "IF-THEN" flowchart helping them recognize when they want, say, encryption versus digesting versus something else.
I strive to assume very little when it comes to the knowledge of I meet. With cryptography, even less so. For example, given some developers you interact with, to what degree do they understand encryption versus digesting? I'm not even talking about the details; I'm talking about the big picture of when each is applicable.
So, even before something like a crib sheet of techniques, some people would benefit from something even simpler: an "IF-THEN" flowchart helping them recognize when they want, say, encryption versus digesting versus something else.
While the fundamentals are always relevant, IIRC this book has been dated even 10 years ago, when Schneier's Cryptography Engineering was already recommended instead if you wanted practical advice.
For a more theoretically backed approach Dan Boneh's book ( https://toc.cryptobook.us/ ) is a very good resource.
For a more theoretically backed approach Dan Boneh's book ( https://toc.cryptobook.us/ ) is a very good resource.
Personally, I feel that HAC has aged surprisingly well compared to other books of that era. It’s focus on theory and fundamentals helps there. I still think it has some of the best introductions to cryptography topics. But, yes, read it in combination with a newer resource like Coursera’s Crypto I course, or Serious Cryptography by Aumasson. (I wouldn’t recommend the Boneh/Shoup book for newcomers. It is still very much a draft).
I wonder if Cryptography Engineering, while updated, is a good book as Applied Cryptography, that really was a pretty inspired one.
IIRC the issue with Applied Cryptography was that while it was the best resource for learning the math behind different crypto systems work and how to implement different algorithms it gave almost no guidance about how to actually use them in the real world. Which led to a lot of people deploying insecure systems based on just reading AC.
My understanding is that Cryptography Engineering and Practical Cryptography address this and focus on using crypto in the real world rather than mathematics and theory.
My understanding is that Cryptography Engineering and Practical Cryptography address this and focus on using crypto in the real world rather than mathematics and theory.
> it gave almost no guidance about how to actually use them in the real world
This is funny, because an old buddy of mine who did a brief stint at the NSA let slip that they almost never compromise the algorithm, it's virtually always the implementation where the weakness lies.
This is funny, because an old buddy of mine who did a brief stint at the NSA let slip that they almost never compromise the algorithm, it's virtually always the implementation where the weakness lies.
The obligatory xlcd reference https://xkcd.com/538/.
Always the easiest path, defeat the implementation.
Always the easiest path, defeat the implementation.
Dan Boneh is great - his lecture series on Youtube is wonderful.
A book I enjoyed a lot, that straddles the line between approachable and theoretical with a focus on implementation, is Serious Cryptography by Jean-Philippe Aumasson (one of the people behind blake2/3, amongst other things): https://nostarch.com/seriouscrypto
A book I enjoyed a lot, that straddles the line between approachable and theoretical with a focus on implementation, is Serious Cryptography by Jean-Philippe Aumasson (one of the people behind blake2/3, amongst other things): https://nostarch.com/seriouscrypto
Real World Cryptography by David Wong is a great book in this category.
Published in 2021, so it’s very up-to-date.
https://www.manning.com/books/real-world-cryptography
Published in 2021, so it’s very up-to-date.
https://www.manning.com/books/real-world-cryptography
Any recommendations for books tackling real examples of cryptography related "incident" like the recent econ paper for example?
Previous discussions:
Handbook of Applied Cryptography (2001) - https://news.ycombinator.com/item?id=6002694 - July 2013 (19 comments)
Handbook of Applied Cryptography (2001) - https://news.ycombinator.com/item?id=11662441 - May 2016 (17 comments)
Handbook of Applied Cryptography (2001) - https://news.ycombinator.com/item?id=6002694 - July 2013 (19 comments)
Handbook of Applied Cryptography (2001) - https://news.ycombinator.com/item?id=11662441 - May 2016 (17 comments)
I liked this one:
https://cryptobook.nakov.com/
https://cryptobook.nakov.com/
I love this. In my college library there's a row of books on mathematics,
a single shelf unit on computer science (system admin, SQL, the works),
a shelf on cryptography
most books on RSA
two books on ECC
and ONE single book on essoteric protocols, and it's this one (not this edition)
covers things like blind signing, dining cryptographers, homomorphic encryption, zero knowledge proofs,
all before the whole bitcoin thing got annoying.
bring back cool cryptography
(blind ECC is annoyingly hard to explain)
a single shelf unit on computer science (system admin, SQL, the works),
a shelf on cryptography
most books on RSA
two books on ECC
and ONE single book on essoteric protocols, and it's this one (not this edition)
covers things like blind signing, dining cryptographers, homomorphic encryption, zero knowledge proofs,
all before the whole bitcoin thing got annoying.
bring back cool cryptography
(blind ECC is annoyingly hard to explain)
> all before the whole bitcoin thing got annoying.
interesting, I feel like Bitcoin (& entire crypto ecosystem) has been good for cryptography.
More research, more innovative ideas, for ex zero knowledge proofs have been getting a lot of traction because of ETH etc. though I think it was discovered before cryptocurrencies.
interesting, I feel like Bitcoin (& entire crypto ecosystem) has been good for cryptography.
More research, more innovative ideas, for ex zero knowledge proofs have been getting a lot of traction because of ETH etc. though I think it was discovered before cryptocurrencies.
> Please read this copyright notice before downloading any of the chapters.
Why would I need to do that if I have no intent to redistribute?
I'm not the one making a copy; the website is.
> CRC Press has generously given us permission to make all chapters available for free download.
Exactly; permission for them to give away copies under terms they have to understand, not me.
Why would I need to do that if I have no intent to redistribute?
I'm not the one making a copy; the website is.
> CRC Press has generously given us permission to make all chapters available for free download.
Exactly; permission for them to give away copies under terms they have to understand, not me.
Because you might want to redistribute. They ask you to be aware of the copyright status, it's not some evil threat or misdirection or so. Feel free not to read it if you already know about your rights and obligations under copyright law.
I like this discussion of cryptographic wrong answers at
https://www.okta.com/au/video/oktane19-cryptographic-wrong-a...
> And crypto has generally become, I think, less scary, at least for cryptographic engineers. I don't know if that's true for a wider developer audience. But again in 1995 phlogiston era crypto, nobody really knew what they were doing, right? And the official story if you tried to learn more things, very often you'd hear, what I call, abstinence only education where people just tell you like, oh you want to do some cryptography? Okay don't.
> ...
> So in conclusion, we're going to look for pitfalls that we can recognize. And to do that I'm going to run through a bunch of bad ideas that keep coming back and that every time lead to disaster for some reason.
> And so one of the very popular ones is algorithmic agility. Same spiel, you know the idea is look we have primitive-A and primitive-A might be, I don't know, AES or something. But what happens if is breaks? We like that, we want to use that primarily but we want to have option just in, we want to have something to fall back on. And the idea is we support both, and when A breaks, we just go turn on B and everything copacetic. A very related problem is negotiation, so lets say that I support A, B and C, you support B, C, and D and some how we're going to figure out that B and C is what we can both agree on, but we like C better so somehow hopefully we're going to end up with C. This is a really, really plausible sounding engineering decision and turns out to very regularly turn into, get us into trouble.
> The poster child for this is TLS. So TLS has a cornucopia of things that you need in order to make it work, right? There's signing, there's key agreement, there's bulk encryption, there's MAC algorithms in there. I'm not even going to mention like the variety of curve choices and key sizes. But for each of these choices, TLS gives you a handful of options. And it's not like a perfect Cartesian product, but it's pretty darn close. Now the question is, why does it hurt to support more things, just go turn them off. Well it doesn't really work that way, because very often you'll see protocols come back from the dead. So FREAK and logjam were real world TLS vulnerabilities that exploited export grade ciphers which pretty much died out in the late nineties.
https://www.okta.com/au/video/oktane19-cryptographic-wrong-a...
> And crypto has generally become, I think, less scary, at least for cryptographic engineers. I don't know if that's true for a wider developer audience. But again in 1995 phlogiston era crypto, nobody really knew what they were doing, right? And the official story if you tried to learn more things, very often you'd hear, what I call, abstinence only education where people just tell you like, oh you want to do some cryptography? Okay don't.
> ...
> So in conclusion, we're going to look for pitfalls that we can recognize. And to do that I'm going to run through a bunch of bad ideas that keep coming back and that every time lead to disaster for some reason.
> And so one of the very popular ones is algorithmic agility. Same spiel, you know the idea is look we have primitive-A and primitive-A might be, I don't know, AES or something. But what happens if is breaks? We like that, we want to use that primarily but we want to have option just in, we want to have something to fall back on. And the idea is we support both, and when A breaks, we just go turn on B and everything copacetic. A very related problem is negotiation, so lets say that I support A, B and C, you support B, C, and D and some how we're going to figure out that B and C is what we can both agree on, but we like C better so somehow hopefully we're going to end up with C. This is a really, really plausible sounding engineering decision and turns out to very regularly turn into, get us into trouble.
> The poster child for this is TLS. So TLS has a cornucopia of things that you need in order to make it work, right? There's signing, there's key agreement, there's bulk encryption, there's MAC algorithms in there. I'm not even going to mention like the variety of curve choices and key sizes. But for each of these choices, TLS gives you a handful of options. And it's not like a perfect Cartesian product, but it's pretty darn close. Now the question is, why does it hurt to support more things, just go turn them off. Well it doesn't really work that way, because very often you'll see protocols come back from the dead. So FREAK and logjam were real world TLS vulnerabilities that exploited export grade ciphers which pretty much died out in the late nineties.
Thanks! I'm glad you liked it. Happy to answer any questions about that talk.
U of Waterloo is a gem of a school. It's one of the few schools that when I see it on a resume it actually moves the needle for me. Their co-op program deserves every bit of the praise it gets.
I read it 20+y ago and it felt like a good intro back then.
If you’re looking for a more gentle introduction to all things cryptography check my book https://www.amazon.com/Real-World-Cryptography-David-Wong/dp...