The arrogance and elitism is wild. I never said people shouldn't use libsodium.

It isn't arrogant or elitist to suggest that no one person should be rolling their own crypto, even if they have taken a grad level cryptography class.

For instance, you don't expect an aviation engineer to build a brand new plane on their own. They would be missing decades of cumulative knowledge, battle testing, perspectives and knowledge outside of their own. These systems are complex, to the point where taking a grad course is not enough.

I have worked with actual experts on cryptography throughout my big tech career - people that have actually written parts of common crypto libraries suggested in this thread - and even they themselves are not interested in writing crypto code. It is an incredibly involved group effort between experienced experts and your first iteration will almost certainly be broken. There is almost never a reason to do this.

If you are so confident in your ability to do so, you may simply be a crypto prodigy, and I apologize. You should post your DHE implementation here. If it's secure and useful, there shouldn't be an issue, and surely the community would benefit from it.

Again you're mistaking my point. I know enough to know what I don't know and the risk involved in doing any serious crypto work, that I can't solo build libraries to protect financial transactions or whatever willy-nilly. It's obviously a ton of work to get right.

What I'd advocate for instead of "never roll your own crypto" is more like "never use your own crypto in prod". People are better off knowing more than less and getting their hands a little dirty. I think the former, common message is more like "don't even try to understand it," which is a joke.

The "in prod" is implicit, no one is trying to stop you from learning things.

It makes more sense if you understand that gatekeeping like this also provides job security for security consultants telling you to buy their services instead.

No, instead you said you learned about how to understand "known plaintext attacks", counting on the average reader of this thread not to know that's a content-free claim. One time, in a "graduate level" cryptography class, you even built a protocol using Diffie-Hellman on top of TLS. OK!

That project wasn't for school.

You provided it as a proof-point of some sort, but I've led lab exercises of freshmen CS students doing the same exercise, so I'm unclear what it's proof of.

Proof that you don't need to be super-human to build something useful, also demonstrated by your freshman CS student anecdote.

Anybody can build a Diffie-Hellman protocol. You can practically do with a calculator; in fact, we did that as an exercise at a talk, with a big audience, using frisbees to "exchange" the keys. But: the talk was about how, as a pentester, to trivially break these systems, because making a system that uses a DH key exchange safely, as opposed to one that simply appears correct in unit tests, is treacherously hard.

I'm still curious about what you could have possibly meant by learning about "weaknesses" like "known-plaintext attacks". Can you say more?

It's been years, but I recall that, for example, when you know every piece of plaintext starts with "https://www", or perhaps know the full contents of particular messages, it may become some degree easier to brute force your way to a key. I don't think it's a concern for standards in broad use, more like something you would worry about if you were cooking up your own cipher.