I disagree vehemently. It is much better _not_ to create software that gives you the false impression of privacy, than to create it. If I am aware that my IM client is insecure, I'll behave differently than if I mistakenly think my IM client is secure. Specifically with crypto, I may be endangering myself if I mistakenly hold this belief.

In essentially everywhere else in CS, people are encouraged to go nuts and experiment. The barrier for entry is null. Anyone with access to a computer can make whatever he wants. Not here. In crypto, it becomes more serious, because people easily depend on it. If it is a toy, _clearly mark it as such_, and never give the false impression of security. Toys are fine. Endangering people is not.

Isn't the argument more that the people doing the software for end users shouldn't be implementing the cryptography for that software themselves and should instead built it on top of libraries that make all of the difficult decisions? Libraries like NACL are good for this, you don't specify cipher modes or anything like that you just say something closer to encrypt(data,key);

Of course you can still fuck up with just that, but it reduces the requirements for the programmer to understand deep cryptography and focus on designing their application for their users.

Also the advertised level of security will alter how the users use the software.

Say for example you have a bunch of confidential documents, you are currently storing them in a bomb proof safe and you never digitize them because you are concerned about security even though digital copies would be useful.

Along comes software that promises to be just as secure as your safe (or more secure). So you jump on it and start using it. Now if that software is not as secure as advertised then you are probably in a worse position security wise than you were before, and you don't even know until somebody steals your documents.

> Doing is always good.

Until the government cracks the crypto used for your messages and locks you up for life.