Any non-trivial system can be exploited if you are allowing user input. A paramount principle of computer security is that once a user has access to the code and physical access to the machine, preventing them from hacking a client side system is impossible because you have no way of knowing the state of the client side system. Even Microsoft discovered this with Paladium. At best you can minimize exploits, but any complex system has complex interactions and the combinatorial explosion of possibilities means that exploits are just waiting to be discovered.
[quote]Any non-trivial system can be exploited if you are allowing user input. A paramount principle of computer security is that once a user has access to the code and physical access to the machine, preventing them from hacking a client side system is impossible because you have no way of knowing the state of the client side system. Even Microsoft discovered this with Paladium. At best you can minimize exploits, but any complex system has complex interactions and the combinatorial explosion of possibilities means that exploits are just waiting to be discovered.
[/quote]
I completely agree.
The approaches used in MANETs assumes all this, and asks the question, how do you make with the assumption that not only can people cheat, but that some number of users will cheat? Many of the approaches make the assumption that while you can’t trust any one user not to cheat, if you assume that a simple majority of users aren’t cheating, there are ways to make the network secure. There are costs, of course, and they may be prohibitive for gaming, but it can be done. If you can’t trust the majority of users you have other, more significant, problems. 
[quote]
I havent read everything in the thread because its way too long, but Im facing basically the same problem with a turn based strategy game, and would appreciate comments on my solution.
The problem is to generate dice on a client and a server in such a way that neither side needs to trust the other.
Im using an algorithm like this, A is the server and B the client.
A generates a secret key, dice
A encrypts the dice with secret key
A encrypts a common known value (0xCAFEBABE in this case) with the secret key.
A sends the encrypted dice and the encrypted known value to B.
B recieves A’s encrypted values
B generates secret key, dice
B encrypts the dice with secret key
B encrypts a common known value (0xCAFEBABE as well)
B sends its encrypted values to A
A receives Bs encrypted values, sends B its Secret key
B recieves A’s secret key,
B decrypts A’s encrypted known value to ensure the key is correct, then decrypts A’s dice. The dice are now the xor of A and Bs dice.
B sends A its secret key
A recieves Bs secret key.
A uses Bs key to decrypt B’s encrypted known to ensure the key is valid. The dice are then the xor of A’s and B’s dice
The encryption method Im using is DES.
Can anyone comment on how easy this is to crack. Its not foolproof in that the server can still cheat. But the client can check that the dice are correct, and can verify the game (even if it is a labour intensive process).
The code is written for triplea, (triplea.sourceforge.net).
You can view the source through cvs, the relevant packages are
games.strategy.engine.vault.*
and
games.strategy.engine.random.CryptoRandomSource
games.strategy.engine.random.RemoteRandom
Damn, I wish I found out about this post a earlier! Would have saved me a lot of brain teasers / unsolvable situations to come to the conclusion this subject is real crap… uhhh I mean is a challenging subject! 
What i’ve done is a combination of client sided obfuscation and server sided cross checks… make it as difficult as possible for hackers by:
1.) mangling all client sided logic, have the important score variables etc split into various “blocks” to prevent people using a runtime debugger from changing them as much as possible.
2.) inserting an checksum object into the client after initialisation. Client only knows the interface, object’s implementation is only known on server (and differs / is initialized random every gamesession). Hackers would need to decompile / extract right values from this object for every play they want to hack.
3.) server sided checks, global game logic that defines max scores, play times per elapsed time. keep record of keepalives with which we send referential temp scores and other data
I’ve put some efford in the security as some of the games can be played for prizes.
[quote]I havent read everything in the thread because its way too long, but Im facing basically the same problem with a turn based strategy game, and would appreciate comments on my solution.
[/quote]
Im not sure if I missed something from your story, but why not trust the server in your case? Is it another player, if so, you could apply the technique JohnMunsch outlined in his post…
I read the thread and there is a slightly simpler solution a few pages back, but its basically the same idea.
In my case the server is playing the game as well, and the server has access to the source code (TripleA is gpl’d) so obfuscation is not an option.
If u are not cheatin ur not trying
``
[quote]If u are not cheatin ur not trying
``
[/quote]