Slashdot Mirror
Cryptographers Break Commonly Used RC4 Cipher
Sparrowvsrevolution writes "At the Fast Software Encryption conference in Singapore earlier this week, University of Illinois at Chicago Professor Dan Bernstein presented a method for breaking TLS and SSL web encryption when it's combined with the popular stream cipher RC4 invented by Ron Rivest in 1987. Bernstein demonstrated that when the same message is encrypted enough times--about a billion--comparing the ciphertext can allow the message to be deciphered. While that sounds impractical, Bernstein argued it can be achieved with a compromised website, a malicious ad or a hijacked router." RC4 may be long in the tooth, but it remains very widely used.
This is the cipher known as 'arcfour' in SSH. I use it regularly when speed is more important than security, which is frequently. I'm not sending a billion of the same files anywhere, so I will continue to use it.
Give me Classic Slashdot or give me death!
I always change my message after the 999,999,999th time I send it with the same encryption key.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
If I understood the article, the reported RC4 weakness is known since so long ago there is a RFC about it (rfc4345) that TLS implementation just ignores. SSH also uses RC4 in a non-vulnerable way, and that's why it's not broken, and it's perfectly possible to have a secure RC4 algorithm by simply discarding the first N bytes, where N>1000.
Yup. RC4 is really fast in software and so can scale really easily without needing any real change in server capacity.
Also, most browsers support Elliptic-Curve Diffie-Hellman key exchange with RC4 which provides perfect forward secrecy with substantially less computing overhead as using the standard DH key exchange protocols.
Hmm. Now to change some settings. Whee.
Anyone know what Cipher Suite configuration is the "safest" now? :)
You're screwed. You have the PCI people who are freaked out over CBC ciphers because of BEAST, you have lots of LTS distros not offering TLS 1.2, and you have people under FIPS who are your customers, so you wind up having to offer RC4 as a cipher to meet all of the above requirements. And even if you assume FIPS-managed clients will be controlling their ciphers to meet their internal requirements, you have to explain this to the PCI scanner vendor every. single. time.
If the LTS vendors could backport TLS 1.2, that would solve many headaches.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
If one pass of RC4 is too weak, just run it through again to make it ultra encrypted! :)
I run tests on RC4 years ago, run it thru a plain text file full of the same char repeated and then run through RC4, guess what? Oh the password is showing every 256 chars, hence the "weak" key. I developed a newer version of RC4 called RC64, uses a 64K (65536 or 256 ^ 2) key. The randomisation process is very complex and the algo was only just slightly slower than RC4, which is very fast anyway. A graphical representation of the 64K key visualized pure white-noise when the key was viewed in grey-scale. They need to start using mine me thinks :) Oh, and in a 50MB file full of the same repeated char, the password was not even hinted at and no 4 bytes were the same.
Just like my double-ROT13 encryption on this message!
TLS 1.1 support is enabled by default in Chrome. Read about that here.
If you want TLS 1.2 in chrome, please star this bug.
As for Firefox, TLS 1.1 and 1.2 support are still not ready. If you want to help, vote for this bug, this bug, this bug, and this bug.
The bugs to get TLS 1.2 support into Firefox are this one and this one.
Both Opera and IE support TLS 1.1 and 1.2. If you want to see this in Firefox and Chrome, vote for the bugs above. But, please don't comment on the bugs. That won't help.
Actually, a HTML document starts with something like
followed by a bunch of other headers, before you get to the DOCTYPE and such.
Knowing that the document begins with "HTTP/1.1 200 OK" isn't very helpful, because as I understand it, this isn't a known-plaintext attack, but rather a constant-plaintext attack: RC4 as used by SSL/TLS doesn't produce the same cyphertext from a given plaintext every time. Ideally, there wouldn't be any correlation between cyphertexts of the given plaintext, but flaws in the cypher mean there are, and the attack uses these flaws to figure out what the plaintext is, given a sufficient number of encrypted versions of the same plaintext.
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Many browsers still don't support TLS 1.2 (which I feel should be treated as a serious bug, not a feature enhancement that some of those browsers treat it as). And those that do almost universally don't enable it by default.
So you'd still have to support RC4, for the moment.
RC4 was useful as a workaround for BEAST. Now we need to throw out RC4, we need another workaround for BEAST
The Right Way would be to use TLS 1.1 or TLS 1.2, but they re not supported by some browsers (e.g.: Mozilla).
What about working around the problem in the web server? BEAST relies on session cookies being at a fixed offset. If I add a random length cookie that is changed on each server reply, I understand I break BEAST assumption. Am I right? Writing an Apache module to do that would be quite straightforward. Perhaps it already exists?