"Then the hook only need to listen on the network and it will get the key..."
It won't do any good to get hold of the public key. That's the beauty of the public key system. You need both the private key and the public key to decrypt the message. The private key is never sent over the network. Regarding the time required to encrypt a message, Quake2 used RSA to place an encrypted checksum on the player movement commands without any real time penalties. There is no need to use a 128 bit key since even small keys can take many hours to bust -- much longer than any player is going to wait around for. And if the keys are changed with each level, busting a key would be useless since by the time it was broken, a new key would already be in use. The problem of the DLL having access to all the info known by the client is a tough one which is why I was thinking of encrypting the player movement packet as processed by the mod. If the legitimate client DLL encrypted the movement packet before feeding it to the engine, the hack DLL would be SOL. The hack would be forced to try to decrypt the message, modify it, then re-encrypt using the keys known only by the client DLL and the server. The trick here is keeping an outside DLL from discovering the private key of the client DLL. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
