breaking the private key

[chud]

Disclaimer: The following is an attempt at helping the developers by suggesting a thought that has been bugging me. I am by no means an expert on cryptography or the workings of EQ.


If the client is sending the session key back to the server using the server's public key, then it would seem feasible to break the server's private key. This assumes of course we know the payload well enough.

Once we have the private key it would seem possible to intercept the session keys by remote sniffing outgoing packets instead of local memory sniffing.

Of course if the key pair is changed frequently, the method to break the private key would need to be reasonably fast.

Where is this logic flawed?


Please hold off your responses unless you are confident you know what you are talking about. There are many threads here that you should read first regarding the encryption process.

[nvmy383z28]

You pretty much summed it all up in one sentance:

"There are many threads here that you should read first regarding the encryption process."

[jonseq]

Actually, knowing the payload is irrelevant since you can generate an infinite amount of known-text given the public key.

You can obtain the private part of an assymetric keypair from the public part, provided you are willing to wait years (possibly millenia) for a breakthrough in computing power or algorithms.

There are two reasons not to 'break the private key':

1) It's not feasible, period. If it becomes feasible, all SOE has to do is use more bits or a more secure algorithm for the next version.

2) Probably SOE doesn't have any secret/public key pair involved in the transaction, because they are concerned about malicious clients, not malicious servers. They don't care about authenticating, just obscuring information sent from SOE to the client. I'd guess (pure speculation) it works something like:

1. client chooses random asym. key-pair (C.sec,C.pub)
2. client->SOE: random public key C.pub
3. SOE chooses random S
4. SOE->client: C.pub(S)
5. client computes C.sec(C.pub(S)) to get S

Of course, it could be the other way around (client chooses random S, which is sent to SOE as SOE.pub(S), in which case *if* you could 'break the private key' you would force SOE to generate keypairs more often, which would annoy them and require a little more computing power)