by phab on 12/18/23, 10:30 AM with 22 comments
by baby on 12/19/23, 7:04 AM
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...
by imjonse on 12/19/23, 8:03 AM
For a more theoretically backed approach Dan Boneh's book ( https://toc.cryptobook.us/ ) is a very good resource.
by rpicard on 12/19/23, 12:47 PM
Published in 2021, so it’s very up-to-date.
by NaOH on 12/19/23, 5:24 AM
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)
by k__ on 12/19/23, 7:36 AM
by pluto_modadic on 12/19/23, 6:39 AM
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)
by kazinator on 12/19/23, 7:36 AM
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.
by xpe on 12/19/23, 6:06 PM
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.
by User23 on 12/19/23, 5:25 PM
by cies on 12/19/23, 9:58 AM