Nothing I've encrypted would be of interest, but if you're hiding from the all-seeing all-powerful NSA, maybe you'd care. [1,000 CPU years seems like a long time until you've got 10,000 CPUs working on the problem. 10,000 CPUs used to seem improbable but how many servers do they say Google has? And that's a company...]
Luis EG Ontanon wrote: > Is the following intelligent dominating species that's going to evolve > in our planet after we go extint will be interested in what you > encrypted? > > > On 8/10/07, Jeff Morriss <[EMAIL PROTECTED]> wrote: >> Well, remember, it's not *really* secure: Anybody with enough CPU time >> can break the encryption. And, what's worse, no one[1] can prove (or >> disprove) that the encryption is not breakable in much less time than is >> needed with brute force. >> >> [1] excepting those who purport that P=NP if P or N are 0 >> >> Derek Shinaberry wrote: >>> I've got it now. I knew I had to be missing something fundamental, >>> because if I wasn't, the whole foundation of SSL would be in jeopardy. >>> >>> The pages I read talked about the client key exchange message sending >>> the premaster secret from the client to the server, but neglected to >>> mention that the client encrypts it using the server's public key. >>> And once it's encrypted, the only way to get it back is using the >>> server's private key. My brain fart was that I stupidly thought the >>> premaster secret was sent in the clear. In hindsight, I suppose it >>> would be rather dumb to call it a secret if it were sent in the clear. >>> >>> Since you have to know the premaster secret to compute the master >>> secret, you'd either have to know the server's private key or somehow >>> obtain the premaster secret from the client before it encrypted it. >>> >>> Well, thank god I've confirmed for us all that SSL is really secure >>> after all. I'm sure you were all very worried about it. ;-) >>> >>> On Aug 10, 2007, at 4:03 PM, Jeff Morriss wrote: >>> >>>> Derek Shinaberry wrote: >>>>> Can someone help me understand why you must have the server's private >>>>> key in order to be able to decrypt the session between the client and >>>>> the server? It seems to me that if the server and client can conduct >>>>> the session without the client ever knowing the server's private key, >>>>> then a capture of the session on the client's side ought to be able >>>>> to decrypt the session using just what is in the SSL handshake >>>>> exchange. What don't I understand about the process that precludes >>>>> this behavior? >>>> You might want to read: >>>> >>>> http://en.wikipedia.org/wiki/Public_key_cryptography _______________________________________________ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
