Hacker News Reader

Comment by atoponce | Hacker News Reader

Funny. I'm getting the analysis from Daniel Bernstein and other cryptographers, not Wikipedia. I'm only showing Wikipedia, because it cites the references:

http://blog.cryptographyengineering.com/2013/03/attack-of-we...

http://www.isg.rhul.ac.uk/tls/

http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7...

RC4 is not practically broken. It requires too many connections (about 16 million, give or take), getting identical data with different keys, and it requires GB of data for analysis.

EDITED TO ADD: I agree we should move off it, but as I understand the current attacks, only small pieces of information can be retrieved from RC4 in a practical attack. With that said, the practicality of the attack is on the edge of feasibility, and it's only going to improve over time. So move, but don't lose any sleep over it.

View on HN

I don't know how to respond to this. 16 million connections is nothing. Gigabytes of data is nothing. Home Internet users incur gigabytes of bandwidth expense to get Torrented copies of movies they don't even end up watching.

I don't know how much clearer I can say this: RC4 is breakable with attacks that take mere hundreds of lines of code, and the attacks are bounded only by your ability to generate millions of connections and gigabytes of transferred bytes. It's 2014.

I'm getting some of my analysis from Bernstein and Patterson too, but more of it from the experience of having implemented some of the attacks, and working directly with people who have implemented the rest of them. You should take my word for this and stop using RC4. The attack is not "on the edge of feasibility". Yes, the attacks have been leveraged to recover "small pieces of data" from connection. That's because the data you care about in an HTTPS connection is small: you're trying to recover the session cookie.

With due respect, LOC seems like an awful metric to gauge protocol brokenness. I can write a one-liner that counts to 2^128, but that doesn't demonstrate that it's easy to count that high.

Which is why I didn't just cite LOC. There are attacks that requires many millions of ciphertexts and that are difficult to implement (for instance, they might speed up a brute-force search). That's not what the RC4 attacks are; they're a simple statistical process that directly reveals plaintext bytes.

My highly optimized Nginx web servers, behind a load balancer, can't handle tens of millions of connections. If it got anywhere near that point, Nagios would be alerting of load, HTTPS being unresponsive, RAM filled, swapping to disk, no pong reply due to a saturated network, and a whole load of other issues. My HA Nginx setup will die long before you reach tens of thousands of simultaneous connections, let alone tens of millions. I'm guessing I'm not the only one.

Practical attack against my server? Nope. You'll kill it before you get anywhere.

Those connections needn't be concurrent.

And if not concurrent connections, it's not feasible given time constraints.

Could you be more specific? I don't know what you're trying to say here.

Reply on news.ycombinator.com