I want to use AES to encrypt some data of arbitrary length, and I'm wondering what block cipher mode I should use. http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html recommends AES in CTR mode. I'm writing a Ruby on Rails plugin, and unfortunately OpenSSL (which Ruby has standard bindings for) doesn't support CTR. I want my code to work out of the box for everybody without requiring them to install a third-party crypto library, so for now I'm using CFB. Is CFB acceptable? How does it compare to CTR or other modes (with the exception of ECB, which I know is insecure)?
Do not do your own criptography. If you have to ask such a question, you are very unlikely to do it right. Use a library, please.
Refer, for instance to this post, and then this follow up, and, particularly, the blog it is referring to.
For example, ECB is not any more insecure than CFB. They are used for different purposes, and choosing one over the other for the wrong purpose will be just as insecure.
AFAIK, CFB is as secure as any other mode. Advantages of stream modes are in other areas (parallelization, random access, etc).
The other poster is correct in as so much that encryption by itself doesn't have to mean anything. There's a ton of details, and you're likely to miss some.
On the other hand, I disagree with the ECB/CFB comment. ECB can expose patterns in your data, and can make weak schemes even weaker. I wouldn't be too reluctant to write it off as "insecure".
As an alternative to using a mode that combines to make a stream cipher, you can approach the problem with a technique called cipher text stealing (CTS) together with a mode like CBC, but that will only work for data sizes 16 bytes and up.
CFB is as secure as CTR in the context of a stream cipher.. CTR can be parallelised whereas CFB cannot. Heed the warnings that implementing your own cryptographic stream cipher will probably leave yourself with security holes. Your best bet would be to do C bindings from Ruby to OpenSSL if possible.