I don't think that's the point of the book. There is enormous benefit that can be gleaned from building a "workable" implementation from first principles, even if it's not actually production "workable". These types of books are rare and very challenging to write, will definitely be taking a look.

What's the alternative, lock all books related to cryptography lest someone might do something in production? Educating is fine, and people reading relatively advanced technical books like this one should be considered as responsible, I think.

Not only reasonable, but it is a must. I think the "don't roll your own crypto" phrase is widely misunderstood. A better phrase would be - learn as much about crypto as you possibly can, to clearly understand why it is a bad idea to roll your own in production. This also means that after you learn it, you will have a much better idea which library, cypher or mode to pick for a particular task, and not just think "oh, crypto is complicated, i will just wrap everything in TLS and won't bother to check the certs"

People who are wanting to get into complex cryptography today have to start somewhere. Showing working models, with huge disclaimers, in blog posts and on github is a great way to lean, if you invite others to show you flaws and break your implementation.

If you want to build complex cryptography, you must either obtain formal training, or learn how to break complex cryptography.

What you can't do is read a book or two about cryptography, the way you would a new programming language, and then bootstrap your own expertise from that. Cryptography is a lot trickier than most other topics in computer science.

> Cryptography is a lot trickier than most other topics in computer science.

Is that actually true? Or is it that most software development isn't really about topics in computer science. Like if you wanted to design your own distributed database wouldn't most of what you said above also apply?

Isn't this really a case where "hard topic is hard"?

I thought about that when I wrote that comment and my conclusion is, no: distributed systems protocols are notoriously hard, but they don't have adversaries. Crypto protocol flaws are marginally more complicated than distributed systems flaws, but also, a distributed system with a byzantine fault can be survivable, and a cryptosystem with a subtle flaw won't be.

I'd buy that having adversaries is what makes crypto different than other topics. Thats probably a better way to pitch your message as well.

There is enormous difference between rolling your own crypto primitives and using existing primitives to create a protocol.

No, there isn't. Most crypto vulnerabilities happen in the joinery between primitives. If you rolled your own block cipher, it's less likely that the cipher would be broken than that your protocol would be broken with a vulnerability that would apply equally well to AES.

Obviously, don't make your own block cipher, either.

I'm also against home-brew crypto, but the author clearly states that what he presents has only educational purpose. It's a bit like cryptopals - you also implement your own crypto in order to learn something.

So a book that teaches a programming language with a "toy" software project does more harm than good? This is industry standard stuff.

It's not "home-brew crypto" if it is a well established protocol.

Nonetheless, even an implementation of a well-established protocol could have problems like a timing attack or an oracle attack, so it's worth being extremely careful.