[Sebastien Tandel <sebastien@xxxxxxxxx>]

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 <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

Regards,

Sebastien Tandel