4 ms·

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

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-week-rc4-is-kind-of-broken-in.html http://blog.cryptographyengineering.com/2013/03/attack-of-we... http://www.isg.rhul.ac.uk/tls/ http://www.isg.rhul.ac.uk/tls/ http://link.springer.com/chapter/10.1007%2F978-3-642-19574-7_5 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.

tptacek 12y ago
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.
- atoponce 12y ago
  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.
  - sdevlin 12y ago
    Those connections needn't be concurrent.
    - atoponce 12y ago
      And if not concurrent connections, it's not feasible given time constraints.
      - tptacek 12y ago
        Could you be more specific? I don't know what you're trying to say here.
- kstrauser 12y ago
  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.
  - tptacek 12y ago
    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.

tptacek 12y ago

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.

atoponce 12y ago
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.
- sdevlin 12y ago
  Those connections needn't be concurrent.
  - atoponce 12y ago
    And if not concurrent connections, it's not feasible given time constraints.
    - tptacek 12y ago
      Could you be more specific? I don't know what you're trying to say here.
kstrauser 12y ago
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.
- tptacek 12y ago
  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.