views:

637

answers:

4

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)?

+2  A: 

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.

Daniel
Yes, if the data is important enough to encrypt it is best to use code that is well tested. There are plenty of free and commercial options out there.
Dana Holt
I'm not sure why you respond like this. I'm not reinventing my own crypto algorithms or implementations; instead, I'm using OpenSSL's crypto functions. Or maybe you're referring to the fact that I'm writing software that uses encryption. I'm writing this because there's no similar software.
Hongli
Hongli, I'm not deriding you or anything like that. I'm offering what I consider to be the best advice I can give. If you haven't read the links I posted -- particularly the last one -- you are foregoing useful information. Also, you say there is no similar software. Have you asked here on StackOverflow if there is a library for the purposes you need? If so, put the link in this question, as it will help others advise you on this. If not, that would be a better question.
Daniel
I'm writing an encrypted cookie session store for Rails. The only one that seems to exist is abandoned, so I'm writing my own. The links you sent are very informative, and it looks like they cover topics like block cipher mode, insecurity of the hashing algorithm used for generating the password and message authentication. I don't use ECB, I don't apply any hashing algorithms on the encryption key, and the unencrypted data is protected by an HMAC. But I'll ask a separate Stack Overflow question just to be sure.
Hongli
+1  A: 

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".

oggy
A: 

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.

Inshallah
A: 

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.