ROTFL
|
| Author | Content |
|---|---|
| jezuch Sep 02, 2008 2:05 AM EDT |
Quoting:The chief concern about this development, according to the NYT article, was the fact that it has made it more difficult for US intelligence agencies to spy on internet traffic. I laughed out loud when I read that. Thanks, USA!! ;) |
| gus3 Sep 02, 2008 2:20 AM EDT |
Like any script kiddie with tcpdump and Wireshark can't do the same thing... |
| Sander_Marechal Sep 02, 2008 2:28 AM EDT |
@gus: Most script kiddies don't have access to a backbone server where a large percentage of all internet traffic flows through. Anyway, this debacle points out again the need for secure protocols. I doubt the NSA has the computing power to decrypt SSL and SSH on-the-fly. |
| gus3 Sep 02, 2008 3:09 AM EDT |
@Sander: Regarding SSL: http://www.ietf.org/mail-archive/web/dnsop/current/msg06583.... Quoting:DJB is convinced that 1024bit RSA is crackable with a botnet. And if 1024 isn't crackable now, it probably will be shortly.The context is DNSSEC, but the broader point of cracking keys applies here, too. As computers penetrate society, and more of them get pwn3d secretly, the time needed to crack keys will drop. The NSA doesn't need to crack SSL on the fly. They can simply capture the traffic and analyze it off-line. Typically, in hours, more likely anywhere between minutes and days, they can crack the private key, then use it to monitor traffic between two points, in much closer to real-time. In the case of HTTPS traffic, the NSA doesn't even need to crack both keys; cracking one key will get them the HTTP request, cracking the other will get the HTTP response. Either one is "good enough" for snooping the conversation. As for a script kiddie with Wireshark, don't forget the recent debacle San Francisco endured over the security of the city network. |
| Scott_Ruecker Sep 02, 2008 3:20 AM EDT |
@Sander: I am no programmer but I would not be surprised if they can to some degree or other. Like you say, being given access to the real backbone servers all but unconditionally, has its advantages. If you had that much access and that much time, you or someone else is going to figure out something. What burns me is that all the major American backbone operators willingly let the Government start their ramp up of surveillance long before the Patriot Act was slammed through Congress like half a roll of toilet paper down a football stadium's toilet drain at halftime. Ok, that's about as political as I am going to get. Sorry. |
| Sander_Marechal Sep 02, 2008 4:35 AM EDT |
Every SSL connection has a new cypher. Even if the cypher can be cracked somehow by the NSA, there is no way to do it in real time. That makes mass spying impossible. The only thing that the NSA would be able to do is save a suspect SSL communication and crack that to see if there's anything in it. They'd have to cherry-pick. I.e. label a computer as "suspect" by listening to it's non-encrypted data. Capture the encrypted data and a few hours/days/weeks later see the unencrypted version. They cannot crack the millions of SSL cyphers created every second for every SSL connection and do mass surveillance like they do on non-encrypted traffic. |
| gus3 Sep 02, 2008 10:37 AM EDT |
Every SSL connection has a new cypher for the payload traffic, but establishing that cypher requires the transmission of at least one public key during the SSL hand-shaking. Once you figure out the private key that matches that public key, you can decrypt anything transmitted using that public key... including the cypher upon which both systems agreed for their general payload traffic. |
| Sander_Marechal Sep 02, 2008 12:51 PM EDT |
True, but those keys are asymmetric, not symmetric like the SSL cyphers. Also, the SSL handshake is very short so even large amounts of SSL handshakes only give you relatively little data to use to crack the private key that's used in the SSL handshake. Furthermore, it's trivially easy to update the certificate to 2048, 4096 or even more bits for use during the handshake, without incurring extra overhead in the actual SSL transmission (which could still be 1024 bit). I think SSL is quite safe for now. Not everything that applies to DNSSEC applies to SSL. |
| jezuch Sep 02, 2008 3:17 PM EDT |
Quoting:Furthermore, it's trivially easy to update the certificate to 2048, 4096 or even more bits for use during the handshake Or 32768 bits :) http://www.hermann-uwe.de/blog/creating-32768-bit-rsa-keys-f... |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!