Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

as RC4 is not secure and AES-CBC is same thing the only solution is using EAX mode for AES. but why mozilla NSS don't support EAX mod ? is there any secure EAX implementation ? and why wikipedia says "using CTR mode means the cipher need be implemented only for encryption" ?

share|improve this question
up vote 5 down vote accepted

Let's not get confused.

RC4 is not totally broken but the margin of safety has become uncomfortably small. We have known for years that RC4 ought to be replaced, but also that no actual SSL connection using RC4 has been broken "in the wild" yet because of the known shortcomings of RC4 (attacks were demonstrated in lab conditions which are on the verge of being realistic, but not quite there yet).

AES-CBC is not really broken. What has been attacked (with BEAST) is the way CBC mode is used in SSL/TLS. The actual attack does not work anymore. This still warrants switching to better modes, but there is no absolute requirement to enforce it within the next hour; rather, we should promote a transition path over the next few years.

The good modes which should be used are the nifty authenticated encryption modes which combine encryption and MAC in a safe way. Several such modes have been defined, a number of which being (unfortunately) covered by patents and other intellectual-property fuzziness which tends to make their usage delicate. The usual recommendations are EAX and GCM, which are both patent-free, and reasonably efficient (when given the choice, I usually prefer EAX because it performs better on very small architectures, but GCM is fine too, and is "approved by NIST"). EAX and GCM both internally use CTR mode, but that's only part of the story. There is a standard for GCM cipher suites in TLS, so that's the Way of the Future: if possible, try to use the GCM cipher suites in your SSL/TLS clients and servers. But if, for usability reasons (e.g. availability of implementations), you have to rely on AES-CBC or even RC4, don't get too stressed out about it: that's still reasonably good by today's standards (it is improbable that even RC4 would be the weakest point of your server).

The Wikipedia quote is about a technical feature of CTR-mode implementations: in CTR mode, the block cipher (the element which processes a block with a given key) is used always in so-called "encryption" mode, regardless of whether you use CTR to encrypt or decrypt a message. This is so because CTR mode is about generating a long key-dependent stream of bytes; actual data encryption is a XOR of this stream with the data to encrypt, and decryption is the exact same operation. So you always generate the stream, which exercises the block cipher always the same way. That's not a security thing; it is a feature which implementers usually find nice and convenient, especially on architectures with severe constraints on code size or silicon area.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.