Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

New RC4 Encryption Attacks Reduces Plaintext Recovery Time 44

msm1267 writes: Two Belgian security researchers from the University of Leuven have driven new nails into the coffin of the RC4 encryption algorithm. A published paper, expected to be delivered at the upcoming USENIX Security Symposium next month in Washington, D.C., describes new attacks against RC4 that allow an attacker to capture a victim's cookie and decrypt it in a much shorter amount of time than was previously possible. The paper "All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS," written by Mathy Vanhoef and Frank Piessens, explains the discovery of new biases in the algorithm that led to attacks breaking encryption on websites running TLS with RC4, as well as the WPA-TKIP, the Wi-Fi Protected Access Temporal Key Integrity Protocol.
This discussion has been archived. No new comments can be posted.

New RC4 Encryption Attacks Reduces Plaintext Recovery Time

Comments Filter:
  • Bwuhahahahahahaha

  • by thegarbz ( 1787294 ) on Friday July 17, 2015 @12:38AM (#50126101)

    Is there any further value in studying an encryption scheme that is widely considered completely and irreparably broken? At this point isn't it like discovering a house with a completely open front door can be broken into by smashing a window?

    RC4 is already not recommended as a cypher for many applications.

    • by suutar ( 1860506 ) on Friday July 17, 2015 @12:44AM (#50126117)

      The techniques used for this attack may be useful attacking other things, so it's good to make it known so new algorithms can be tested for susceptibility to this.

    • by hankwang ( 413283 ) on Friday July 17, 2015 @02:41AM (#50126355) Homepage

      studying an encryption scheme that is widely considered completely and irreparably broken?

      All known issues with RC4 have to do with statistical biases in the first bytes of the key stream, in particular the first 256 bytes (this paper also mentions a significant bias at byte 258). As far as we know, all issues with RC4 are avoided in protocols that simply discard the first kilobyte of key stream before starting to apply the key stream on the plaintext. SSH does this (discarding the first 1.5 kiB IIRC). For WPA I can imagine that this workaround would have an unacceptable performance penalty on small data packets. For some reason, this approach was never implemented for TLS/HTTPS or WPA.

      So why would one be interested in RC4? It's significantly faster than AES when run on processors that do not have hardware AES support. If I use scp and rsync-over-ssh to copy files to devices like a Raspberry Pi or my home server which runs on a low-power VIA processor, it's a big difference (aes versus arcfour), something like 4 MB/s versus 8 MB/s. Here are some benchmarks: openSSH cipher benchmarks [famzah.net].

      I keep my eyes open for papers like this, in particular I check whether they make statements on weaknesses after the first kilobyte of key stream.

    • by DarkOx ( 621550 )

      Yes because there are many many situations where the only mutually supported cipher between two end points is RC4 be it used for SSL/TLS or any other protocol. RC4 is also much faster when you are working with something that does not have hardware accelerated crypto. It does not matter much if we are talking some big SSL offload device but can matter a great deal when its some tiny MIPS or ARM chip in your industrial controller.

      Studying the possible attacks on RC4 make sense because there are lots of peop

  • by wvmarle ( 1070040 ) on Friday July 17, 2015 @12:42AM (#50126109)

    It's old, it's pretty much done for, and preceded by many better protocols (some of which have also been seriously damaged since, like RC5). It starts to sound a bit like kicking a dead horse.

  • by jonwil ( 467024 ) on Friday July 17, 2015 @12:48AM (#50126121)

    Why would any sane admin use RC4 for SSL/TLS instead of using a more secure algorithm like AES?

    • by nullchar ( 446050 ) on Friday July 17, 2015 @01:51AM (#50126247)

      Because it's in firmware that can't be [easily] upgraded?

      Hooray the Internet of Things! Billions of devices that will never be upgraded.

      • by dave420 ( 699308 ) on Friday July 17, 2015 @05:32AM (#50126679)
        We already have billions of devices which will never be updated, so I fail to see why an attack on the Internet of Things is at all pertinent.
        • by jp10558 ( 748604 )

          I'd say it's somewhat relevant - it's saying that 'we have a problem now - here's how the "internet of things" will make that problem worse. Maybe figure out mitigations before you buy into the "internet of things"' . . .

          However, here it's likely preaching to the choir. But for general consumption / random google search results, it seems like it's a good idea to point out that this could be an issue.

    • RC4 and TEA are the only algorithms I have memorized, everything else I have to look up because they are so complicated. For being trivial to implement (at least in software), RC4 lasted quite a while.

  • Meme fail (Score:4, Informative)

    by srussia ( 884021 ) on Friday July 17, 2015 @03:39AM (#50126459)
    "All Your Biases Are Belong To Us"

  • That's all I'm really interested in. Will it make cracking the neighbor's WiFi practical again? Nobody uses WEP anymore, and almost all the routers with WPS seem to have been upgraded to prevent the very nice Reaver attack which was so cool a few years ago.

    I used to get Internet access anywhere by simply cracking some nearby WiFi. Nowadays, I usually need to use my phone's data connection, which is painfully slow and not usable in other countries because of roaming charges. I keep an open WiFi at home for p

    • It's not good for random areas you are passing through, but AT&T DLS routers with WiFi use a 10 digit passcode which is a nice short key space to search if your using pyrit (https://code.google.com/p/pyrit/)

      Comcast defaults to I think a 12 character passcode, but even though it's alpha-numeric they inexplicably used all uppercase, way to screw up the better security decision and needlessly limit your key space as well...

      The short of the above is most people seem to leave the default settings, so grab a

  • Oddly, Google still uses RC4, according to Qualys test [ssllabs.com]. They also still allow SSLv3 and have not yet moved to SHA2 signed certificates.

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.