Books like this scare the hell out of me. People can't even seem to use tried-and-true crypto libraries without screwing something up most of the time. Now you want them to write their own? This sounds like an absolute disaster waiting to happen.
Same difference. Golang provides cryptographic primitives but few fully-implemented constructions; for instance, if you use Golang's CBC, you have to implement your own padding.
Any Golang program that implements crypto will also need to implement an incomplete and poorly-specified version of NaCl.
(That's true of virtually every other programming language as well.)
I agree to some extent, but I wanted to make clear that this book is not about implementing AES or SHA algorithms. It's about using them (the author actually makes that very clear, the algorithms are treated as black boxes).
Yes you can still use them wrong, and you're not much more advanced. But the original comment seemed to suggest it was about implementing the low-level algorithms.
There's an important distinction here that most people miss, namely the difference between a 'cryptographer' and a 'cryptography engineer'. A cryptographer builds schemes and protocols and proves their security. (Phil Rogaway is a cryptographer. Bellare, Boneh, Rivest, etc.) A cryptography engineer writes code that implements schemes developed by cryptographers. To be a good cryptography engineer you really need to learn how to break systems. In contrast, some of the best and most important cryptographers never even touch a keyboard except to typeset research papers.
I don't understand - are you contesting that this distinction exists at all? Here are some counterexamples: Shaffi Goldwasser, Oded Goldreich, Matt Franklin, Craig Gentry, Chris Peikert.
Breaking crypto systems isn't the same as breaking "into" systems.
The history of cryptography can basically be described as a series of assumptions which turn out to be invalid. This is either because they were never valid to begin with (and it just took time for problems to be discovered and shaken out), or because the facts on the ground change, making them invalid.
I'm not a cryptographer. I also don't really call myself a hacker anymore (because the loaded assumptions around that word make it useless as a descriptor, you wind up having to explain it in so much detail that it's just easier to start out with a different word), but I do know some cryptographers. They have all described the process in a similar way, which is you start by learning about the pitfalls of everything that's come before you.
Much like if you were learning to build bridges, you'd spend time learning about past bridges that didn't hold up.
So you start with the oldest crypto systems, and learn why those fell out of fashion. One nice benefit to this approach is that it makes it fairly apparent how brittle these constructions are. I don't think I've ever met a cryptographer who isn't suitably hesitant about designing cryptographic systems. Also, a good portion of the time spent as a cryptographer (maybe most of it? I'd love to hear a dissenting view from an actual cryptographer), is in breaking cryptographic systems (initially other people's, and than later, your own).
Cryptography isn't like web frameworks in the sense that everyone is making their own. New crypto systems (at least ones that come from cryptographers) don't spring up out of the ether every week.
One problem that seems to come up in cryptography is that cryptographers themselves "seem" to be mostly only concerned with the primitives. They leave implementation as "an exercise to the reader". This is a problem because I'd say that the overwhelming majority of actual security problems that stem from cryptography aren't problems with the primitives. They're problems with the construction necessary to do anything useful with those primitives. That's why when people heed advice like "Use AES" they're probably screwed.
You're pretty much on point. When designing a scheme, whether a low-level cipher or a higher-level protocol, only a small fraction of the time is spent on the initial design itself. That is not to say that a scheme is designed and promptly finalized; analysis results feed back into the design process, of course. But the analysis is generally by far the most time-consuming task.
Additionally, sane people do not use building blocks that they don't trust. If you need a block cipher you use AES (which is partially backed by security proofs) instead of designing your own (unless you have very specific requirements). This saves immense time in both design and analysis. Same with modes (Feistel structure, Sponges, HMAC, etc). Proofs play a big role here, although it is important to understand what they say, instead of blindingly assume they mean whatever you use them for is secure.
You are right that implementation is generally left as an afterthought. This is slowly changing, and primitives are increasingly being designed for implementation and side-channel friendliness.
The intent of the book, as stated by the author, is:
It assumes that you aren't looking for cryptographic
theories, but practical ways to use cryptography in your
projects.
If you want to build a cryptographic library for other developers to consume, it's imperative that you understand the theory behind crypto principles. The author is telling you that this isn't the book for that.
