New RC4 Encryption Attacks Reduces Plaintext Recovery Time

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.

Comments

Re:Answer me this... apk

[marcansoft]

The answer is that it varies - GPUs are anywhere from mediocre to useless at "normal" crypto.

It depends on whether the particular encryption algorithm/mode in use is parallelizable or not. For example, CBC is not parallelizable - you have to encrypt each block of data serially. GPUs are useless at CBC mode encryption. More modern modes like GCM and XTS are parallelizable to an extent, as you can encrypt multiple blocks at once, but there is still a serial dependency in the process (there is no real way of completely getting rid of all dependencies while keeping the algorithm usefully secure), so you still need to do some pre or post-processing of the data in a serial fashion. And even then, you're limited by bandwidth in/out of the GPU.

Public-key crypto (RSA, DSA, and ECDSA) isn't really parallelizable either as it only deals with small data sizes. And typical hash algorithms like SHA-1 and SHA-256 are also not parallelizable in their construction.

Thing is, CPUs these days have hardware AES encryption acceleration, making this mostly a moot point. GPUs are good at doing the same thing many times in parallel, which is what breaking encryption requires, but not regular usage.

Is there any value in studying this?

[thegarbz]

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.

Re:Is there any value in studying this?

[suutar]

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.

Re:Is there any value in studying this?

[hankwang]

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.

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.

Re:Is there any value in studying this?

[DarkOx]

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 people who may be faced with a decision requiring large investments of time and money replacing hardware or software that is otherwise still meeting their needs. You need to have some understanding of just how risky RC4 might be to make that decision. Its easy in a security role to just say "RC4 == bad must fix", but that isn't providing great service. Understanding the value of what you are protecting and the potential consequences if the encryption is broken are critical the next part is understanding how easy it is to break.

If a successful attack requires 10's of thousands of known plain texts that you can't imagine the likely attackers have any way of getting, and will take months of key space searching with 100's of GPUs and special purpose build software, vs some guy with a couple Radeons and a stock copy of Kali can do it in hour with handfull of plain texts it might change the decision.

Why still bothering with RC4?

[wvmarle]

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.

Why are we still using RC4?

[jonwil]

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

Re:Why are we still using RC4?

[nullchar]

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

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

Re:Why are we still using RC4?

[OrangeTide]

I shouldn't be writing compilers either, but I do that too.

Re:Why are we still using RC4?

[dave420]

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.

Re:Why are we still using RC4?

[jp10558]

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.

Meme fail

[srussia]

"All Your Biases Are Belong To Us"

FTFY

Re:Will it help cracking WiFi?

[phoenix_V]

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 few modern GPU's and have a party, backup wifi will be yours in no time. Just be sure to have a good disk on the server storing all the results, they can get large.