Then can you please outline specifically what training would be required to accomplish... whatever it is you did claim that was, "relatively minimal"?
What classes? What books? What certifications or degrees?
What classes? What books? What certifications or degrees?
Actually implement cryptographic attacks before trying to design crypto.
That's not just my recommendation; it's also what Bruce Schneier has been writing for decades.
The problem with my suggestion is that most people who work their way from block cipher attacks through RSA error oracles are "scared straight", and lose the desire to plunk fancy crypto into their applications. Once you see how subtle some of the most devastating attacks are, you start to see why so few crypto engineers write chat apps.
I fail to see the problem...
I'm not saying that with minimal training you can write an OpenSSL equivalent, or even create a novel cryptosystem on top of OpenSSL, people writing software products generally shouldn't be creating novel cryptosystems in the first place (and I speak as someone that implements crypto-systems for a living, usually very well defined crypto-systems from banking standards).
The fact that you think it's that easy is a wonderful example of why there's such a disconnect between developers and crypto experts.
What they can do is use existing, secure constructions, which at least gives them a fighting chance. Inventing new stuff does not.
If that's not what you meant, then I understand.
The nearest I can see to that is where I said - "With fairly minimal training one can learn to use existing, secure constructions." - which I think I've qualified/explained now?
My reading of what you wrote is: it doesn't take much training to use Libsodium. To the extent that providing cryptographic security is important, you can solve the problem by delegating it to the Nacl designers and Sodium implementors. That's mostly true.
I did not see you making an argument about how simple the entire security problem was to solve.
Since when is learning a single crypto library the end-all solution to writing good crypto software?
You might have said that!
>> Since when is learning a single crypto library the end-all solution to writing good crypto software?
It's not, but it's a start, a start which all of these stories that hit HN and get torn to pieces are missing.
-- edit --
When I made my comment that you can learn to use existing things with minimal training I should have padded it out by telling you the reason I was saying that - learning to use well-understood crypto primitives, and (if you can) pre-provided crypto implementations is far from all you need to make secure software. But it's a start.
"Hey, come and look at our neat new crypto, it's awesome!" is a big red flag, and it's a red flag with a subtext that reads: We don't know what we're doing.
Software that does use good constructions and good implementations can still be done very badly, it's true.
To go back to your first comment, you say there's this gap between the way crypto people work and the way developers develop - that may well be so, but in most of the messaging apps we see here on HN the developer hasn't really even attempted to bridge that gap.
Think about it like cooking a meal - you're asking what it takes to become a top chef but in the case we're discussing they didn't even start their marinara sauce with tomatoes.
Writing secure software is hard and covers a lot more than your choice of ciphers, protocols etc. It's possible to make all the right choices and still make insecure software for so many reasons. OpenSSL was referenced up-thread - simple buffer overruns/lack of bounds checking is one way in which that failed (heartbleed).
In order to write secure software one needs first to define what we're aiming at, what does secure mean in the domain in which we operate? And that's non-trivial in itself.
But by choosing well-known constructions and (hopefully) well tested implementations we can minimise some classes of potential problems.