NACL and Keyczar are two viable alternatives to DIY crypto. I'd use NACL before I considered trying to DIY an AEAD secure transport; there are more things to get wrong than properly authenticating your data!
You are always better off not working directly with crypto at all. For that, consider using PGP/GPG for data-at-rest (if you're in a JVM language, you can use Bouncycastle to get access to PGP) and SSL/TLS for data-in-motion.
In our practice, password reset tokens and encrypted session cookies continue to be the top source of exploitable crypto vulnerabilities in web applications. You don't need encryption to build either of these features; send 128 bit random numbers that key a database row instead.
If you use Go, instead of hacking together things with AES from the standard library to encrypt something, just `go get code.google.com/p/go.crypto/nacl/secretbox` and call secretbox.Seal with unique [randomly generated is okay] nonce and your key to get the encrypted and authenticated "box". secretbox.Open with the same key and nonce will open it.
Bonus: on amd64 it's extremely fast (portions are written in assembly, and even pure Go versions for other platforms are hand-optimized), faster than what you can get from any non-hardware AES implementation (let alone authenticated with HMAC), and provides better security margin.
We ( http://bu.mp/company/ ) used NACL client and server side when we built our new app ( https://theflockapp.com/ ). It's a pretty great library--a shame it's not more widely used.
In our practice, password reset tokens and encrypted
session cookies continue to be the top source of
exploitable crypto vulnerabilities in web applications.
You don't need encryption to build either of these
features; send 128 bit random numbers that key a database
row instead.
If I'm not mistaken (and haven't read up on this stuff in years, so probably), the majority of encryption modes rely on XORing the stream of bits from the cipher with your plain text.
In that way, both sender and receiver need only generate the same cipher bits and apply XOR to encrypt and decrypt (meaning encryption and decryption are actually identical operations!). A side effect of XOR is that a single bit flip in the ciphertext corresponds exactly to a single bit flip in the cleartext. An attacker with knowledge of your cleartext can therefore modify it without ever needing to know the cipher parameters.
Imagine a session cookie that contains a single 32bit integer, the user ID. Now attacker knows his user ID, so he merely needs to XOR the cookie with his ID, then XOR it again with his desired ID and voila admin privileges. Wrapping the cookie in a MAC prevents this kind of manipulation.
I'm not sure I totally follow this (you seem to be talking about an attack on CBC mode, but the mode you're describing sounds more like CTR mode), but a good rule of thumb is, without explicit authentication, attackers can alter and often rewrite messages even though all they can see is ciphertext.
But there are even more problems than that with unauthenticated encryption. If you don't authenticate there is a good chance attackers will be able to decrypt your messages wholesale.
If they can get your system to tell them if a message is valid somehow, perhaps by making thousands of attempts to pass a message and noting where it says 'login failed' or '404' instead of invalid message (for instance) then there are all sorts of things that can be done to recover messages and keys.
I highly recommend Dan Boneh's crypto 101 on coursera for anyone that has the time.
The CBC padding oracle is one such attack. There are a bunch of similar ones. They're "chosen ciphertext" attacks.
Again, even if you get this part right, there are other things that go wrong. TLS is authenticated, and it fell to two adaptive chosen plaintext attacks because of two different implementation details they messed up. And no public cryptosystem in the world has been as thoroughly tested and analyzed as TLS.
For some mind-boggling reason, the designers of the XML Encryption standard decided to make authentication optional, so an attacker can simply avoid sending an incorrect MAC.
The simplest way to think about it is during the receiving process: checking the MAC before decrypting catches and rejects evil messages earlier so there are fewer things that can (and will) go wrong. Even if you tell the world that the message wasn't invalid, you don't reveal any new information to the attacker.
OTOH, if the receiver must decrypt before checking the MAC, any information leaked to the attacker (success or failure, timing, etc) is very likely to give the attacker a systematic method to decrypt some or all of your secret plaintext.
Missing from this blog post, but made clear here (http://blog.cryptographyengineering.com/2012/05/how-to-choos...) is that you need to USE TWO DIFFERENT KEYS, one for the cipher, the other for the MAC. This makes it practically impossible to forge a valid message, since even if someone forged an apparently valid cipher section they'd be unable generate the corresponding MAC (unless they already had your keys, in which case you're already toast).
Not to mention: if you're doing it right, you really don't have to think about whether you have two keys; you just naturally kind of do. It's the systems where you consciously have to handle two different keys that you have to worry about, because they're probably not keying themselves safely to begin with.
You are always better off not working directly with crypto at all. For that, consider using PGP/GPG for data-at-rest (if you're in a JVM language, you can use Bouncycastle to get access to PGP) and SSL/TLS for data-in-motion.
In our practice, password reset tokens and encrypted session cookies continue to be the top source of exploitable crypto vulnerabilities in web applications. You don't need encryption to build either of these features; send 128 bit random numbers that key a database row instead.