Is CVE-2013-2566 a practical attack against RC4 or still conceptual?

Question

Is CVE-2013-2566 a practical attack against RC4 or still conceptual and does it only apply to WPA/TKIP?

Answer 1

As Matthew Green puts it, the attack "is just on the edge of feasibility". It conceptually applies to any protocol that uses RC4, although some are more vulnerable than others.

The weakness of RC4 is a bias in the first bytes of output. From the key, RC4 generates a long stream of pseudorandom bytes, and encryption is just a byte-per-byte XOR of the data to encrypt with that stream. Thus, when the same data is encrypted multiple times (with a distinct key each time), the bias in RC4 output translates to a recovery of the secret data. For instance, suppose that the 17th byte of output has value 0x42 more often than the 255 other possible byte values (a fictional illustrative number). As the same message is repeatedly encrypted, its 17th byte (let's call it x) will be XORed with the 17th byte of RC4 output. The attacker, observing all the encrypted messages, may notice that the 17th byte of output is, say, more often 0x7C than any other value. The attacker will then infer that the observed value 0x7C corresponds to cases where the 17th byte of RC4 output is 0x42. He will then conclude that x XOR 0x42 = 0x7C, i.e. that x = 0x3E. The attacker just recovered one byte of plaintext.

The important point is that only the first bytes of RC4 output have biases which can be exploited in a "reasonable" time. The biases are still slight; it takes millions of observed encryptions, all with the same secret data, to reliably observe such biases.

In a Web setup (with HTTPS), the attack would look like this:

• The victim's browser knows a cookie that unlocks a session on some site (let's call it www.example.com. The attacker wants that cookie.
• The attacker controls the victim's network context. Realistically, the attacker runs a WiFi access point in a public place, and the victim connected to it, believing that AP to be provided by the restaurant or library he has decided to spend a few hours.
• The attacker injects some hostile Javascript in the answer to an HTTP (not HTTPS) request from the browser to some site (not www.example.com). That Javascript will repeatedly trigger an HTTP GET call to https://www.example.com, e.g. by creating a hidden <img> tag in the Web page.
• Each call triggered by the evil Javascript implies an SSL/TLS connection, with the cookie in it, at a predictable place. The attacker furthermore injects in the connection a RST packet just after the call, to force a connection close and thus a new connection with a new handshake and a new RC4 key each time.

Realistically, the attacker cannot really hope for more than, say, ten connections per second or so, so a million call will take more than a full day and night. Also, all these connections hit the target site (www.example.com), which may raise some alerts. If the attacker can pursue the attack at full speed for 30 hours or so, then he will be able to guess one or a few cookie bytes (the bytes which appear in the stream at a position where the RC4 biases are most important).

The conclusion is that the attack is, indeed, on the edge of feasibility: it can be demonstrated in lab conditions, but has not been spotted in the wild. Yet.

For WPA/TKIP, the same principles can be applied, but is more practical because in that protocol, each individual packet has its own RC4 stream, started anew with a packet-specific key. Collecting one million packets is sure easier than observing one million TCP connections with a TLS handshake. However, the weakness is in no way restricted to that single protocol; it is consubstantial to RC4 and will follow it into any protocol that uses RC4.

It may be noted that when SSH uses RC4, it usually does it under the name "arcfour128" or "arcfour256"; in both cases, this is RC4, but with the first 1536 bytes of output dropped. These are bytes with the biggest biases. Thus, these RC4 variants are quite stronger than the plain RC4 (known as "arcfour" in SSH terminology).

For new protocol designs, don't use RC4. If you really need to go beyond some "normal" AES/GCM, consider the stream ciphers from the eSTREAM portfolio: they are both safer and faster than RC4. But remember that protocol design is hard.