The keys they used were only 128 bits, whereas RC4 actually supports up to 2048 bits. I wonder how much that affects their results. (AFAIK the 128 bits is an export restriction thing, upgraded from the previous trivially-breakable 40 bits.) Also, 16 characters seems awfully short for a cookie, especially one meant for authentication purposes.
Practical attack against TLS/SSL and RC4
41–45 of 45 posts
Re: Practical attack against TLS/SSL and RC4
#42It's fairly likely that rumors of the NSA's ability to 'decrypt SSL' refers to RC4 vulnerabilities.
Are you sure about that? This attack requires a js exec in browser to generate lots of traffic containing the cookie. It's a little impractical to use in a SIGINT capacity. My bet is still on precalculated DH like logjam attack. Still the quote from @ioerror is: "RC4 is broken in real time" so that's either hyperbole or there is an attack better than 75 hours still out there.
Re: Practical attack against TLS/SSL and RC4
#43Re: Practical attack against TLS/SSL and RC4
#44Earlier quoted context omitted.
> As for energy/CPU consumption, I don't think that'd be a big concern. What if this attack targeted a phone or laptop? Battery would die faster, device would get warmer, and fans spin up.
If your last line of defense in encryption/network security is noticing that the fan spins up more often then you already lost the game. Why even bring it up?
Re: Practical attack against TLS/SSL and RC4
#45Earlier quoted context omitted.
If your last line of defense in encryption/network security is noticing that the fan spins up more often then you already lost the game. Why even bring it up?
It's not a line of defense. I'm thinking about less computer literate people. Do you know a friend or family member that would call you and say "My laptop's really hot, loud, and slow, but it's not doing anything!" and ask for advice?
Do you really think this scenario is realistic and worthy of consideration at all?