It's very good that the author is trying to get the word out, but it would help tremendously if he tried to at least give some indication (or links to further material), of why certain modes are insecure.
The people who already know this information don't need this blog posts, and the ones that don't get no information that helps them to understand the problem. I think stating what can go wrong with, for example, ECB, would make it much easier for people to remember which mode is good and which is bad. As it is at the moment one would have to remember a few cryptic acronyms as "good" and others as "bad", without any context. (Or go look it up somewhere, but the people looking these things up are not the ones in need of being alerted...)
If you have to explain to someone why they shouldn't be using ECB, it's hopeless. Instead, you need to be educating them as to why they should be using someone else's whole cryptosystem, like NACL or Keyczar or PGP.
Crypto is a place where a little knowledge is often harmful. You tell someone not to use ECB, so they use CBC instead. Now they're vulnerable to a bunch of new practical attacks. You list those off, and they switch to CTR, and their stuff is as trivially decryptable as simple XOR encryption.
What's the point? It's better to give people the (honest, accurate) impression that they don't know anything resembling enough to build a cryptosystem so they won't try, fail, and screw over their users.
You're interpreting these posts all wrong. There are plenty of things within the field of CS that are sufficiently complex and difficult to get right that your average Joe Coder shouldn't be attempting to write them in production code. There isn't some shroud of difficulty around crypto in particular. For instance, in just about any project, getting ANY security right, not even considering crypto, is typically an overwhelming task.
The point is that when people read this blog on the front-page of HN, they expect to learn something. 99.99% of us aren't writing our own crypto. But this is a way of learning. I've been told from basically everyone in the industry since a young age that you shouldn't write your own crypto. As a result, I educated myself to understand how I might get it wrong so I can understand when things are wrong, and so that I could understand crypto news. Similarly, as a web dev, I educated myself heavily on common vulnerabilities. The end result is that no, I can't say that everything I make is 100% secure, but it's certainly a lot better than if I didn't do those things. At least now I can actually see when myself and others might be causing a vulnerability.
You seem to be hand-waving things and telling people "STAY AWAY." Maybe, just maybe, instead of treating people like they're all idiots, enlightening them might work a little better. You've put a warning on the label, the blog post is NOT a guide on how to make crypto, but a guide in how you'll probably get it wrong. Now proceed with the juicy details. Maybe I don't know why I shouldn't be using ECB because I don't know what it is because I don't do crypto. Maybe I'm not implementing my own block cipher, or maybe I'm just curious about the different modes of block ciphers and which are good/bad and why. Maybe with a better understanding I can even explain it to other people rather than just telling them "you shouldn't do your own crypto," and look like an idiot when I have nothing to say when they ask "why?"
Applying your reasoning to computer science -- some people end up as negative productive engineers. They create more bugs and problems than they solve. Obviously, we should just STOP TEACHING CS to anyone because such people exist, right?
Tony's post is prescriptive. "Do this, not that". It's not "let's explore all the intricacies of this problem".
I am interested in giving people the right advice to build systems that won't blow their hands off in production a year from now. I am at the moment less interested in handholding them through a guided tour of the last 10 years of crypto vulnerabilities.
You'd see the same phenomena occurring in message board threads about DIY nuclear reactors. Except that it's hard to build a DIY nuclear reactor, and very few people do it, so we don't need those threads very often, and we don't need to sort through the "LET"S JUST NOBODY LEARN ABOUT NUCLEAR POWER THEN HUH?" comments.
Unfortunately, it is very easy to build new crypto applications, and people do it, and then a year or two later we see threads from dissident groups in South America where people have been interrogated by police organizations that have full decrypts from those tools, and then a few more weeks later we find out that the tools were doing comically stupid things with their crypto building blocks.
I think educating people about some pitfalls and then recommending them a "full package" solution will stick better.
For example, for ECB it's trivial to explain, that it allows reordering of encrypted blocks, an attack that someone not familiar with cryptography has probably never thought about. Of course they won't gain a full understanding of cryptography in this way, but they will hopefully start to appreciate how difficult it is to get right, and how many attacks there are that they have never thought about. This hopefully includes an understanding that possibly other modes that they think would be safe might also have problems that they have never considered, and that they should really use a full package solution.
I think this will drive the point home better than, say, listing three opaque possibilities on how to use a MAC and then saying "no 1 is the right one", without any explanation whatsoever.
The old "interview screenplay"[1] post on the Matasano blog
had a particularly compelling image of Why ECB Sucks. Sadly, it doesn't seem to have survived the 3 years of blog herd migrations.
the argument you're replying to doesn't require that the explanation be correct, does it?
what they seem to be saying is: feeding someone a little extra information that is entertaining somehow helps make the recommendation to use a 3rd party library more convincing.
and i think there's something to that argument, even though i've presented it poorly above. people don't like to be simply told to do something. they like to be indulged a little.
i realise that goes somewhat against your personal style, but it's not obviously wrong...
I get what you are saying but the idea that people should not try to learn is ridiculous. If someone is truly interested they need to be told to go ahead. Encourage caution, but not ignorance. When someone asks why ECB is bad then tell them, or tell them to go read up on it.
No. I've never seen anyone criticize someone for working with and asking about questions about developing attacks on crypto. It's only when people "Show HN" their latest tool for protecting dissidents from foreign governments, or protecting financial transactions, that people catch flack for going the DIY route.
The people who already know this information don't need this blog posts, and the ones that don't get no information that helps them to understand the problem. I think stating what can go wrong with, for example, ECB, would make it much easier for people to remember which mode is good and which is bad. As it is at the moment one would have to remember a few cryptic acronyms as "good" and others as "bad", without any context. (Or go look it up somewhere, but the people looking these things up are not the ones in need of being alerted...)