RC4 crypto: Get RID of it already, say boffins

Re: Are we ever likely to have

Your DVs seem a little unfair. That's a fair point you make on the face of it. However RSA, for example, is named after its inventors, via their initials. They get a little kudos every time it is mentioned.

Re: WPA or WPA2?

Sounds like another scare story. While any encryption can be broken given enough time and sample data, the question really is: is it good enough to get the job done to an adequate level of security ?. For example, network stumbler here reports 20 to 30 ap's within range, most running wpa2, probably many hundreds just on this estate. To crack even one of those would take a very determined and knowledgeable hacker a considerable amount of time and for what gain ?. Streamed Coronation Street doesn't cut it. For any hacker with malicious intent, the balance is always how valuable is the data, or, gain vs effort. For most, other than as an intellectual exercise, it's really not worth the effort.

Only government agencies have the resources to do this and there are probably millions of wifi setups across the uk, so it's a big haystack and they would need good reason to want to do it in the first place. Afaics, they are welcome :-)...

Chris

Re: WPA or WPA2?

"Basically, you probably have only one option left on your wifi access point (AP) that provides even a modicum of security. It is WPA2 with a pre-shared key or PSK and AES for encryption. The 2 is important and the AES is important. Turn off the rest."

While WPA2 with AES is safe at the moment, I can only recommend that solution for very small companies and homes. For the rest the only reasonable solution is to use WPA2 Enterprise (Radius authentication).

With PSK you mostly need to hand the key to the end-user, and they have access to the WLAN even after they have left the company. Changing the PSK on each device is fine for a handful of devices but with say 50 users it's already getting difficult to reach all people and safely distribute the key. With Radius the user just uses the user name and password on AD/LDAP, and if the said user leaves the company the deactication of that account automatically removes the WLAN rights.

Re: The Security Design Flaw, commonly known as "Web Browser".

Umm, not quite.

To begin with, 9*2^27 is the TOTAL number of requests estimated to allow recovery of the original plaintext using this method with a 94% probability of success. Having had a look at the actual paper, the actual RATE observed by the researchers was on average 4450 requests per second - still more than what an ordinary user would generate but not inconceivable, plus overall a considerably smaller number than 1.2 billion. By the way, Richard's article is unfortunately slighly imprecise in that it mentions both 52 and 75 hours as attack time, without explaining the former number (it is how long the specific test ran by the researchers took, a better-than-average result according to their own statistical estimates).

Secondly and most importantly, I doubt implementing such limits in the browser (admittedly, from what a quick search has told me is that they do not currently exist) would considerably deter attackers. All other considerations aside, the JavaScript part of the attack serves only to accelerate the process of ciphertext generation, the actual data acquisition and number crunching being done by a dedicated tool. It seems to me that for most remote attacks the easiest way to let said tool see client traffic would be to have it deployed one way or another on the client machine itself - in which case it would be trivial to throw in a custom Web client which would heed no restrictions whatsoever. In fact, having just looked at the paper again the tool already includes such a client, which is currently used to brute-force the cookie based on the candidate list obtained by HTTPS monitoring and which can test up to 20,000 cookies per second. No, enforcing security of a Web application is the SERVER'S job. Possibly coupled with an IDS somewhere on the way to attempt to detect anomalous network traffic.

By the way, IMHO this still isn't a viable attack for your average blackhat (and I would argue that with the resources they have at their disposal, for the NSA and buddies RC4 posed no significant obstacle even before this attack was announced). I mean, just generating ciphertext requires transmitting data at 2.2 MB/s (and that's under the highly optimistic assumption each sample consists of nothing but the 512-byte encrypted HTTP request) for many consecutive hours - and you still have to brute-force the candidates somewhere. Surely someone is bound to notice, assuming of course the outgoing connection has enough capacity to begin with? Moreover, if I already had good enough access to the client to plant the necessary tool I could come up with something much more efficient to deploy instead. Last but not least, note that the actual injection of known plaintext is handled by yet another component, in case of the described set-up employing a man-in-the-middle attack. No, the point here is that the current state-of-the-art attack against RC4-encrypted HTTP has decreased the required time by another order of magnitude, confirming - as aptly mentioned in both the text and the title by the earlier paper also mentioned in the article - the truism that attacks against known vulnerabilities get better with time.