Ack.
But still I think that given the will and the power there are far
better mechanisms to obtain information than cracking encryption (like
bribery or extortion).
On 8/10/07, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
>
> 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 <jeff.morriss.ws@xxxxxxxxx> 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@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-users
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
Propertarianism joined to capitalist vigor destroyed meaningful
commercial competition, but when it came to making good software,
anarchism won.
-- Eben Moglen
