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?

  • $\begingroup$ Context? Future extensions in SSL? Or as a server operator who's limited to existing implementations? $\endgroup$ Commented Oct 11, 2013 at 7:55
  • 2
    $\begingroup$ AES-CTR and Salsa20/ChaCha are the most popular stream ciphers in my experience. $\endgroup$ Commented Oct 11, 2013 at 7:56
  • $\begingroup$ Can we use AES-CTR and Salsa20/ChaCha in the TLS? Can we choose it as cipher suit? $\endgroup$
    – NiceTheo
    Commented Oct 11, 2013 at 8:29
  • 1
    $\begingroup$ 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. $\endgroup$ Commented Oct 11, 2013 at 8:31
  • $\begingroup$ It would be a good idea to do that. $\endgroup$
    – NiceTheo
    Commented Oct 11, 2013 at 8:35

2 Answers 2


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.


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

  • $\begingroup$ So far there do not seem to be any commonly available implementations of eSTREAM ciphers. Why? $\endgroup$
    – wilx
    Commented Feb 23, 2018 at 15:26
  • $\begingroup$ as per Vulnerabilities tools RC4 should not be used where possible, wants to know how to fix this? $\endgroup$ Commented Oct 23, 2018 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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