7
$\begingroup$

According to many sources, the first few (n) bytes of the RC4 keystream are strongly biased, and therefore should be discarded before using the keystream to encrypt anything; this precaution is commonly called RC4-drop-n.

There are variants of RC4 available in SSH that do exactly that (arcfour128 and arcfour256).

I've not been able to find any hint on whether the SSL/TLS specifications take that into account. The RFC don't include any specification of the RC4 algorithm itself, just a reference to a source that is not available online.

So are they using RC4-drop-n, and if so, what is their value for n?

| improve this question | |
$\endgroup$
  • $\begingroup$ Very similar to this question. The summary is that these attacks do not really matter in the context of TLS/SSL (aka, when the key is randomized, there are no related keys, etc). Read RSA's own words here. $\endgroup$ – B-Con Jul 31 '12 at 18:56
  • $\begingroup$ @B-Con, none of the answers to that question actually answer this question. $\endgroup$ – D.W. Aug 1 '12 at 5:42
  • $\begingroup$ @D.W.: This is obviously not a duplicate of the question I linked to, but once you know the answer to that other question the answer to this one is a natural result. Since the RC4 weaknesses here are not relevant in the TLS context there is little motivation to use RC4-drop-n, and it isn't used. $\endgroup$ – B-Con Aug 1 '12 at 15:09
  • 1
    $\begingroup$ "not relevant in the TLS context" might be a bit optimistic: blog.cryptographyengineering.com/2013/03/… $\endgroup$ – armb Mar 13 '13 at 13:44
4
$\begingroup$

Well, no, there's no defined TLS ciphersuite that does the RC4 algorithm with a discard of the original stream.

I'm not a designer of TLS, nor am I a member of the IETF working group that controls it; I suspect that they'd prefer for people to transition to ciphersuites that use AES (or some other newer cipher), and so there's little incentive for them to add variant RC4 ciphersuites.

As for the problems that the know biases that the start of the RC4 stream can cause, well, those biases actually come in two flavors:

  • There are known biases in the keystream bytes themselves; for example, the second byte of the keystream is 0 with probability 1/128 (rather than the expected 1/256). What this means is if you have a few thousand TLS sessions keyed with RC4, and you know that their plaintexts have the first few bytes in common, you might be able to deduce the values of the second plaintext byte; with more keystreams, you might be able to deduce the values of the first and third plaintext bytes. Obviously, this is a security failure, and this may be of real concern if (for example) you're sending a password through the TLS session as the very first thing.

  • There are known correlations between the keystream bytes and the RC4 key itself. These correlations aren't strong, and so you'd need thousands of keystreams from related keys to get much information about the key. This is exactly the problem that WEP ran into; however, with TLS, they derive the RC4 key from a real key derivation function; that means that there are no known corrections between the keys from different connections, and so this observation is of no use.

The bottom line: if the first few bytes of the TLS stream are high-value, you probably shouldn't be using an RC4 ciphersuite.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks, that pretty much answers my question. Just to make sure, regarding the second issue: There is no (known) way to derive the RC4 key from a single keystream alone, right? So even when the very first thing that is sent in a RC4 encrypted connection is gigabytes of known plaintext (zeroes, for example), the key cannot be easily recovered? (Assuming that the initial key has never been used before, even partially - unlike WEP etc.) $\endgroup$ – lxgr Jul 31 '12 at 20:39
  • 2
    $\begingroup$ @Ixgr: as far as is known, the easiest known way to reconstruct the key no larger than 256 bits from a single keystream is brute-force. Now, given gigabytes of keystream, we can determine whether it came from RC4 or a random source (the statistics of an RC4 stream are subtly different), but that still doesn't give us a clue as to the original key. $\endgroup$ – poncho Jul 31 '12 at 21:17
  • $\begingroup$ Now it makes sense, thanks again. I was confused by RFC 4345 mentioning the possibility of recovering the key from the first keystream output bytes, but now I think they probably just want to be on the safe side and are not referring to actual attacks in that paragraph. $\endgroup$ – lxgr Jul 31 '12 at 22:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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