Well said. However, all it takes is a luser to brute force the private key. Using a packet capture tool, the luser can catch a full session, compare it against what he did, and then generate some conclusions about it. then he can do it again, and again and again, until he gets some correlation. then we're back to square one. make a community effort, and add an extra menu to HLDM/CS/TFC: 'report cheater'. give admins the ability to report a wonid to sierra/valve. enough complaints, a warning wonid ban. step two is a full revocation of their won ID. make them pay to cheat. </rant>
> 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
