I just skimmed the article, but I generally agree. I mean, I get it - I think it's actually pretty easy to make an argument "Secure crypto code is exceedingly d

I just skimmed the article, but I generally agree. I mean, I get it - I think it's actually pretty easy to make an argument "Secure crypto code is exceedingly difficult to get right, even for experts. And unlike lots of other areas of code, there is no 'halfway broken' - crackable crypto is 'game over' in a lot of situations, which is why it's so dangerous to roll your own." 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.