Because if your ciphertext isn't authenticated attackers can modify it to launch adaptive attacks against you. Also, obviously, they can potentially rewrite messages.
This is one of those situations where if you have to ask why you'd use authenticated encryption or how you'd do it, you simply shouldn't be using cryptography primitives directly at all. Use PGP/GPG instead.
If that's what you think this post is about, stay away from crypto. I don't mean that offensively. Most developers should stay the hell away from crypto. They all know intuitively that they shouldn't be hacking together, say, kernel modules. But since crypto comes in library form, they assume it's safe to build with it. It isn't.
I wouldn't touch cryptography code in production with a long stick. Thing is the headline all crypto code you've written is broken is sensationalist and doesn't apply to 90% of developers, who "write crypto code" using third-party libraries.
No. The "third party libraries" you're talking about are, from my experience (my whole job is looking at random applications deployed in production for problems like this) things like OpenSSL and crypto++ and CryptoAPI and Common Crypto.
Tony isn't complaining that developers implement the AES cipher core themselves and screw it up, or even that they're implementing their own block cipher mode code. He's saying that even when you use third-party libraries, if you haven't chosen a library that is specifically designed to avoid mistakes, you are boned. And he's absolutely right about that.
Also, from experience: virtually nobody uses the good high-level libraries. What library did you use last time you built a feature, like a password reset token, that relied on crypto?
Also, from experience: virtually nobody uses the good high-level libraries. What library did you use last time you built a feature, like a password reset token, that relied on crypto?
What library _should_ I be using for sending out a password reset token?
(I realize that by asking I am proving your point. I would still like to know the answer.)
You shouldn't use crypto at all (for instance, for reset tokens, you can just use long random numbers as keys), but if you have to use a library, use PGP, NACL, or Keyczar.
Take CBC mode for instance. The CBC block cipher mode is a fine choice for bulk encryption. Low-level crypto libraries must provide it, because CBC is the most common block cipher mode used by preexisting cryptosystems (like TLS). And a generic implementation of the CBC block cipher mode must expose the CBC IV.
The library designer hasn't done anything "wrong" by providing a CBC module for use with cipher cores, but if you just pick up CBC mode and AES and go use them, you're likely to build a vulnerable cryptosystem, because the CBC IV must be unpredictable, it must not be possible to introduce controlled padding errors to the ciphertext, and because CBC ciphertexts can be bit-flip rewritten.
The problem is not with the CBC code; the problem is with exposing crypto at the "CBC mode" level of abstraction.
But what's the author of a low-level library to do? There isn't one simple solution to these problems. Some cryptosystems HMAC-SHA2 the CBC ciphertext. Some use cryptographically random IV's and tack them to the beginning of messages. It all depends on the system; the library designer can't predict all the different ways the code will be used, even though most of the way the code is used will end up being insecure.
This is why developers should use high-level libraries like Keyczar and NACL; by sacrificing low-level control and compatibility with legacy cryptosystems, they allow generalist developers to not have to worry about all the implementation attacks.
This is one of those situations where if you have to ask why you'd use authenticated encryption or how you'd do it, you simply shouldn't be using cryptography primitives directly at all. Use PGP/GPG instead.