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?
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
> 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.
baby|2 years ago
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...
lbriner|2 years ago
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?
imjonse|2 years ago
For a more theoretically backed approach Dan Boneh's book ( https://toc.cryptobook.us/ ) is a very good resource.
nmadden|2 years ago
h0h0h0h0111|2 years ago
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
antirez|2 years ago
rpicard|2 years ago
Published in 2021, so it’s very up-to-date.
https://www.manning.com/books/real-world-cryptography
3abiton|2 years ago
NaOH|2 years ago
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)
k__|2 years ago
https://cryptobook.nakov.com/
pluto_modadic|2 years ago
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)
FergusArgyll|2 years ago
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.
kazinator|2 years ago
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.
Tomte|2 years ago
xpe|2 years ago
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.
lvh|2 years ago
User23|2 years ago
cies|2 years ago