Handbook of Applied Cryptography(cacr.uwaterloo.ca) |
Handbook of Applied Cryptography(cacr.uwaterloo.ca) |
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...
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?
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.
For a more theoretically backed approach Dan Boneh's book ( https://toc.cryptobook.us/ ) is a very good resource.
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
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.
Published in 2021, so it’s very up-to-date.
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)
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)
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.
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.
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.
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.
Always the easiest path, defeat the implementation.