Hacker News new | past | comments | ask | show | jobs | submit login

That is a really poor analysis. RC4 is not "secure". RC4 is terribly broken, it's just not broken in a way that's likely to be relevant to Youtube. You should probably get your crypto analysis from Crypto Stack Exchange, not from Wikipedia.

The last widely publicized attacks on RC4 used browsers and session cookies as targets. The attacks are practical --- in fact, they're among the simplest of the low-level cryptanalytic attacks (the flaws are statistical, and statistically trivial). Our implementations of the attacks clock in at hundreds, not thousands, of lines of code.

RC4 isn't a hair-on-fire problem and I wouldn't really worry too much about it at Youtube. But if you were operating a bank or a payment processor, I would tell you to make sure you weren't using RC4.

MD5 is broken in that you can generate collisions for it. But HMAC-MD5 is not broken; there is no theoretical attack on MD5 that breaks HMAC-MD5. It takes more than a simple collision to break HMAC.

The risk that systems that use HMAC-MD5 (and things like it) are taking is different from the risk that systems that use RC4 are taking. MD5 is broken, but HMAC-MD5 is actually (to the best of our knowledge, and with a very low margin) secure. RC4 is not actually secure in any scenario. But the cost/benefit of exploiting RC4 to recover the plaintext of a publicly-available streaming video is not great.

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




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.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact