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?
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.
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.
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).
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
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.
> 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.
> 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.
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.
> 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.
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.
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...