Fortunately for them (hum!) there are the rainbow tables ... compute
once, always crack
Regards,
Sebastien Tandel
On Aug 10, 2007, at 3:55 PM, Jeff Morriss wrote:
Full ack.
Luis EG Ontanon wrote:
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 <[EMAIL PROTECTED]> 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 <[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
Regards,
Sebastien Tandel
_______________________________________________
Wireshark-users mailing list
Wireshark-users@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-users
