Hacker News Reader

Comment by marklgr | Hacker News Reader

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.

View on HN

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.

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.

> 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.

Reply on news.ycombinator.com