Hell, even identifying which ‘cryptography expert’ actually knows what they’re talking about and which ones are windbags is often more trouble than it’s worth.
But there's a huge gulf between that message and "Hell Is Overconfident Developers..." And importantly, I don't think that "overconfident developers" is the biggest problem. If anything, even when I very much don't want to "roll my own" crypto, I've found it difficult to be sure I'm using crypto libraries correctly and securely. Sometimes libraries are too low-level with non-obvious footguns, or they're too "black box" restrictive. I think a great example is the NodeJS crypto library. I think it's a great library, but using it correctly requires people to know and understand a fair amount about crypto. Whenever I use node crypto I pretty much always end up writing some utility methods around it (e.g. "encrypt this string using a key to get cipherText" and "decrypt this ciphertext using this key"). I think it would be better if those standard utility wrappers (that do things like use recommended default encryption algorithms/strengths, etc.) were also included directly in the crypto library.
I think most developers are actually scared of rolling their own crypto, but cryptography experts don't make it easy to give them a plug-and-play solution.
If they look like they spent too much time in the sun you can't trust them. This criteria has yet to fail me.
It’s never worked to yell at my junior developers and tell them that ‘hell is them doing any kind of development’.
It works better when I just show them what they should do instead.
In other news, don't print yourself a motorcycle helmet on your 3d printer, don't make your own car tires, don't make your own break pads. I mean if you really know what you're doing maybe.
EDIT: I have some personal experience with screwing up some crypto code. I won't get into all the details but I was overconfident. And this was after taking graduate level cryptography courses and having spent considerable time keeping up to date. I didn't write anything from scratch but I used existing algorithms/implementations in a problematic way that left some vulnerability. This was a type of system where just using something off the shelf was not an option.
None condoned by your employer however. Those tickets need finished yesterday. Security is just a checkmark.
Can HN give some actionable advice on dos, not don’ts (I already know all the don’t like don’t use OpenSSL primitives, don’t use AES-CBC, blah blah)?
crypto is like many other things in which if you make ONE TINY mistake you are doomed. point taken. do your due diligence. but also don't trust randos. or the NSA and probably NIST. therefore most so-called experts.
if hell is "overconfident" developers, then what is "overconfident experts". or "overconfident furry apologists for crypto experts"? also hell.
crypto is hard. we get it. you're also no better than anyone else at it.
I see no problem with it if your work gets peer reviewed. The very last point they made though I kind of agree with. If you end up making a new algorithm from scratch that is dangerously novel and potential crack pot territory. I did like how they went to that trouble to make the hierarchy of what is meant by "rolling your own crypto."