back to article RC4 crypto: Get RID of it already, say boffins

Remember how many times the crypto world has shouted that the RC4 crypto algorithm needs to be wiped from the face of the Earth? It just got even worse, with researchers demonstrating an attack that can be executed in 52 hours. Belgian researchers preparing for August's Usenix Security Symposium in Washington, DC, reckon they …

  1. Joe Montana

    Slow updates

    It's widely used because lots of companies are stuck with obsolete software that doesn't support anything else, or are forced to comply with some kind of standard or certification that hasn't been updated... There's various software out there that has a "FIPS mode" and i've seen a few cases where this basically meant turning off TLS 1.1 or higher.

  2. Anonymous Coward
    Anonymous Coward

    Are we ever likely to have

    *secure* encryption because it seems there are more stories about people breaking it than improving it.

    Seriously, the kudos associated with breaking a cypher is deemed bigger than the kudos from creating it. As soon as we create one, someone else starts picking it apart.

    1. gerdesj Silver badge

      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.

  3. gerdesj Silver badge
    Alien

    WPA or WPA2?

    I've actually read the paper (OK: glazed after a few pages and skimmed the rest) I think I am right in saying that if you believe "This is only about WPA and I use WPA2, so I'm OK", then think again.

    Wonder what I'm on about? Then read this:

    http://www.howtogeek.com/167783/htg-explains-the-difference-between-wep-wpa-and-wpa2-wireless-encryption-and-why-it-matters/

    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.

    If you can, then segregate device types via VLANs. Drayteks for example can do this without you having to fiddle with a switch. One SSID for your LAN, one for mobes and other loosely trusted stuff and a third for IoT, tellies, X boxen and the like.

    Finally, wrap yourself in tin foil 8)

    1. Tridac

      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

      1. phil dude
        Boffin

        Re: WPA or WPA2?

        @Tridac: While any encryption can be broken given enough time and sample data,...

        This statement is not true. Good encryption is effectively unbreakable no matter how much data you have. Flawed encryption is crackable some of the time, by those with resources. Bad encryption is just not considered encryption.

        With as many devices running this downgraded cipher, I suspect there will be a bounty for crims of all stripes for years to come...

        P.

        1. Tridac

          Re: WPA or WPA2?

          There may be unbreakable systems, but if you are resposible for the security of an organisation, the only safe assumption is that single point encryption can be broken. ie: the channel is assumed to be insecure facing an adversary with sufficient resources. . There are probably any number of ways to mitigate weak wifi encryption. ie: encrypting the data before it reaches the wifi router and at an access control level, doing things like mac address filtering and using radius server. Not foolpropf, but makes the task more difficult.

          Good security is not just about one aspect, but should be an integrated approach where as many of the possible holes are accounted for. Engineering applies: Speed, Security Cost. Pick any two :-)...

        2. Michael Wojcik Silver badge

          Re: WPA or WPA2?

          Good encryption is effectively unbreakable no matter how much data you have. Flawed encryption is crackable some of the time, by those with resources. Bad encryption is just not considered encryption.

          Terms like "good", "flawed", and "bad" are meaningless in this context, unless they're defined by a threat model.

          If my threat model is, say, that I might lose a device and some random idiot who finds it might browse through files looking for sensitive information, then RC4 covers that just fine. For this particular application, if my threat model is "teenager next door might hop on my WiFi and eat up bandwidth streaming porn", then WPA with RC4 covers that too. Hell, WEP covers it; it's trivially breakable for anyone who makes a bit of effort, but that pretty much excludes the neighborhood kids, because they have better things to do with their time, and because there are easier targets (i.e., unsecured networks) in the area.

          I know, I know - Reg readers and scribes1 are clearly incapable of understanding the basic concepts of information security, in particular the notion that security is always relative and only meaningful under a threat model. But I enjoy pointing this out in the comments of every story on cryptography, because I'm an annoying bastard.

          1Any security researcher saying "the RC4 crypto algorithm needs to be wiped from the face of the Earth" is being careless, or is simply incompetent. RC4 is fine for many applications under many threat models. The fact that it's inadequate - sometimes severely - for other applications and under other threat models means it has to be used cautiously. But hyperbole like this is simply foolishness, and encourages poor security thought and practice.

    2. Sandtitz Silver badge

      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.

      1. gerdesj Silver badge
        Alert

        Re: WPA or WPA2?

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

        SOHO is to whom I was addressing my comment.

        Personally speaking I have four VLANs and SSIDs at home and I have RADIUS for LAN - me and the wife's laptops, PSK for "things", PSK for our "other devices", and Captive Portal tickets for "guests" (in a bowl in the kitchen). That is with three D Link APs (with management on another VLAN) and a pfSense router to link it all up. Oh and a slack handful of smart switches. Actually the pfSense is a CARP cluster of two nodes.

        I have HA Proxy and Squid doing their stuff in both directions, Snort + probes and a whopping great logging system

        Enterprise? - Pah! My SOHO is tin foil lined 8)

  4. theblackhand

    Quick overview of WLAN security options

    So, we now have the following WLAN protocols that are unsuitable for WLAN connectivity where there is an expectation of security:

    Open

    WEP PSK

    WEP Enterprise

    WPA with TKIP and PSK

    Suitable for restricting access to a WLAN network and making decrypting captured information difficult in less than one month (maybe longer):

    WPA with TKIP Enterprise

    WPA with AES and PSK

    WPA2 (includes AES and CCMP) PSK

    Secure to the extent WLAN allows (assuming sensible key lifetimes):

    WPA with AES Enterprise - should still be OK, should strongly consider migrating to WPA2

    WPA2 (includes AES and CCMP) Enterprise

  5. Anonymous Coward
    Anonymous Coward

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

    For RC4-based TLS cipher suites, this is completely irrelevant.

    But a Web Browser that will obediently perform 2^26+ Requests and insert secrets into attacker-supplied requests at attacker specified positions, rather than aborting after a dozen failure and telling the user about it, *THAT* is a serious problem (called Web Browser design flaw).

    1. Anonymous Coward
      Anonymous Coward

      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.

  6. Anonymous Coward
    Anonymous Coward

    One at a time boys!

    So, there's like 20+ trusted ciphers out there - and in 20+ years of watching, I've never seen even one single cryptographer smart enough to figure out that we should be using all, or many, at once - but no - the whole damned lot always choose just one, and toss all their eggs in.

    No wonder it's on their face now.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019