On 5/13/05, Guillaume Germain germaing@iro.umontreal.ca wrote:
On Fri, 13 May 2005, Eric Merritt wrote:
Trusting data (much less code) to the client is just not safe. Theoretically you could encrypt the data and trust the returned data, but there are any number of places where that particular path could (and will if the target is attractive enough) will fail.
Could you give an example of a situation where you can't ensure the integrity of data you have encrypted yourself? Or rather, where do you see the places where "that path" will fail? I might be missing something obvious.
No encryption is perfect, lets take the most strait forward attack where the encryption scheme is broken and the attacker modifies the continuation in some arbitrary manner. You can bet that the protections you put in place will be circumvented, its just a matter of how, when and how much damage will be done.
This is a very common problem in client/server games. Game designers very often store quite a bit of player data on the client in the interest of efficiency. They implement some type of protection scheme to keep the user from modifying this game information directly. In almost every case, users quickly find a method around these protections and manipulate that data. This is a common cheat for those kind of games. The developers then go one of two ways. They move the state data to the server and remove the problem (the of course, then need to work out the performance issues) or they start a war of attrition with the cheaters. What I mean by this is that they change the protection scheme, increase it strength, change formats, etc. The cheaters, of course, quickly find a way to break the new scheme and the cycle continues.
Of course, this assumes if you have a sufficiently attractive target to warrant the effort.
Guillaume