Take the 2-minute tour ×

In cryptography, the Fluhrer, Mantin and Shamir attack is a particular stream cipher attack, a dedicated form of cryptanalysis for attacking the widely-used stream cipher RC4. The attack allows an attacker to recover the key in an RC4 encrypted stream from a large number of messages in that stream. The Fluhrer, Mantin and Shamir attack applies to specific key derivation methods, but does not apply to RC4-based SSL (TLS), since SSL generates the encryption keys it uses for RC4 by hashing, meaning that different SSL sessions have unrelated keys.

From here. Does it mean that RC4 is not so secure as we want? And which stream cipher can we replace the RC4 in the SSL?

share|improve this question
Context? Future extensions in SSL? Or as a server operator who's limited to existing implementations? –  CodesInChaos Oct 11 '13 at 7:55
AES-CTR and Salsa20/ChaCha are the most popular stream ciphers in my experience. –  CodesInChaos Oct 11 '13 at 7:56
Can we use AES-CTR and Salsa20/ChaCha in the TLS? Can we choose it as cipher suit? –  NiceTheo Oct 11 '13 at 8:29
There is AES-GCM (which is based on AES-CTR) in TLS 1.2, and AGL at google works on a ChaCha-Poly1305 suite. But there are no widely implemented streamciphers in TLS for now. –  CodesInChaos Oct 11 '13 at 8:31
It would be a good idea to do that. –  NiceTheo Oct 11 '13 at 8:35

2 Answers 2

up vote 7 down vote accepted

There are several ways to answer your question:

  1. You cannot "replace" RC4 in SSL. SSL is a standard protocol in which any algorithm may be used only if both client and server support it and agree to use it. Thus, in practice, you do not get to replace algorithms as you wish, unless you control both client and server code; and even then, it would not longer be "the standard SSL (actually known as TLS)" but a custom variant.

  2. If we want to define a TLS variant, then we can define new cipher suites which use a stream cipher distinct from RC4. There are some good candidates for the job, in particular the eSTREAM portfolio: these algorithms did get a fair share of analysis, and "seem strong". There is no known detectable bias in them, contrary to RC4. They also happen to be substantially faster.

  3. Standard TLS now defines cipher suites with GCM. GCM is a block cipher mode of operation which builds on a block cipher with 128-bit blocks (usually AES); the block cipher is used in CTR mode, which actually turns it into a stream cipher. So we can say that using GCM-based cipher suites really is replacing RC4 with another "stream cipher".

Note that SSL/TLS ensures not only confidentiality but also integrity; thus, there must be a MAC somewhere. When using RC4 for the stream cipher, the MAC is HMAC with a hash function (MD5 or SHA-1). If you replace RC4 with a super-fast stream cipher which does only encryption, then the HMAC may become the bottleneck. GCM uses the block cipher for both encryption and the MAC, so a fast block cipher actually speeds up the whole thing. On modern x86 processors, there is hardware support for AES which includes an opcode specially suited for GCM. On smaller architectures, where performance issues are actually much more probable to matter, GCM is not necessarily a good choice ("fast" implementations of the binary field multiplication in GCM use big tables which are not that fast on CPU with a small L1 cache).

share|improve this answer

As far as I understand, RC4 is not as secure as we would love it to be and considered to be a temporary fallback solution against BEAST attacks on TLS 1.0.

I know Google uses RC4 for most of its services, and this is the reason one shouldn't keep gmail opened all the time ;-)

I believe it must be replaced with AES-128-256. And TLS 1.1 supports such modes, we just need to wait until more and more servers/browsers will start to support it.

I would like to see ECDH-RSA2K-AES256-GCM in the near future used widely.

share|improve this answer

Your Answer


