A new way to key sniff

[CRP]

Ok, this thread was brought up before, but it died last November.

We know (or can find) the clients private key, because it is sitting there in the eqgame.exe. We can intercept the public key when it is sent to the client (SEQ is intercepting the packets, and decompressing them, why cant we find the key in those packets?). We then have the public and private keys. We can now decode the data as it comes. Why cant we just pick up the new key as it is sent?

Security vulnerablities of this encryption scheme appear when the hacker has access to the client, and can get the private key. We have access to the private key, so this can be broken.

We have all the information the client has. The client can decode the zone key information. So, therefore, we can decode the zone key information.

I know it is a hard way of doing things, but if it is done, there is no way to detect this type of scanning.

Unless I misunderstood something, which is completely possible.

<dons his fireproof suit>

[quackrabbit]

The private key is maintaned ONLY at SoE and is never sent over the wire. Only the public key is. Having the public key is useless.

Please take a really good look at how SSL works for details as to why the attack you propose is not possible. The source code for SSL is even publicly available and it still has to be brute forced to find the payload.

[Cryonic]

The client uses the SERVERS public key to encrypt the session key that it has generated. We do not have access to the SERVERS private key and so can't decrypt the key that is sent over the wire..

[throx]

I think the misunderstanding is that the key being sniffed from the client is a private key of a pair. It isn't. It's the symmetric session key that's been negotiated using the public key from the server.