[gojomo]

How will people learn if they don't try?

The problem is not creating and releasing such applications; the problem is overclaiming their security, or putting early confidence in them.

Crypto is hard, we get it. Beginners and non-experts are going to mess it up, we get it. Even experts almost always mess it up, we get it.

Still, a good programmer of crypto software (or even just, "wise user of battle-tested crypto libraries in the proper ways") will almost always start out as a bad programmer of crypto software... who got started, and learned by failing.

To borrow an aphorism from other project/product wisdom: if your first version's crypto isn't obviously and embarassingly broken, you waited too long to release.

[superuser2]

Broken social networking websites and YouTube clones are relatively harmless, so that philosophy makes sense.

Broken cryptography can cause loss of money, infrastructure, and life. Imagine if a group of dissidents where to start using this program, the crypto implementation was subtly wrong somewhere, and they were disappeared by their government early one morning. Imagine if some transmitted a password through what they thought was a secure chat, and that password led to an industrial control system for, say, a subway, water treatment plant, foundry furnace, or explosive chemical storage tank. Software doesn't just move Tweets. There are massive, hot, high-voltage, fast-moving objects controlled by software also. Letting people believe information is safe when it isn't can have very real consequences.

Unless it is obviously written all over your software that "THIS IS A TOY AND YOU SHOULD NOT EXPECT IT TO ACTUALLY KEEP ANYTHING SECRET," your obviously and embarrassingly broken crypto (to a crypto expert) might look just fine to a nontechnical user with dollars and/or lives riding on your product.

[_b8r0]

Crypto experts are not beautiful or unique snowflakes, armchair or otherwise.

[gojomo]

Yes, so the message should be: "add disclaimers, avoid promoting where rigorous security is required, educate yourself on best practices".

Not, "stop releasing hobby projects".

The reckless non-technical user who grabs any project that mentions a slight sheen of crypto-sparkles, and then trusts that software with their life or savings, is doomed anyway. The existence of one more hobby project with amateurish crypto isn't going to kill or bankrupt him twice over.

[jdiez17]

I'm okay with hobby projects that use cryptography if every time the user tries to do anything in which security can be expected they flash a message that makes the user type "I understand my data may be read by an adversary."

[lelandbatey]

Yeah, my question is what is anyone supposed to do? What if we want something to be secure? Are we supposed to just say "well, I'm never supposed write anything involving crypto"? How do we do things right? Seriously.

[jdiez17]

No. You learn to do cryptography. You get a book, you sit down and you read it. Understand what are cryptography primitives. Understand how they can be used together to create cryptographic systems. Understand every part of that system. Then learn what are the common errors, learn how misuse of cryptographic primitives can lead to disaster. Be able to talk for hours about why WEP encryption can be easily cracked by a low-powered netbook.

When you've done all of that, you'll know that you are abysmally incompetent at cryptography. When you know that, you can start learning how to become good at cryptography. Some people divide learning in four steps: unconscious incompetence (you don't know that you're bad), conscious incompetence, conscious competence and unconscious competence.

Even when you're competent, you will make mistakes, because cryptography is very hard. We've seen how MD5 is now broken, yet still people use it as message authentication ciphers even when it's trivial to perform a length extension attack. But MD5 wasn't always broken. I'm sure it was designed by competent people, but they can't foresee all flaws.

That is why someone who is incompetent at cryptography should not do it.

[zimpenfish]

(I'm very much not any kind of expert on Crypto but...)

Probably when you understand "Applied Cryptography", front to back, maths included, then you can think about writing cryptographic software.

Or win a fist fight with Schneier.