[gambit-list] Gambit-C 4.0 beta 13

[Eric Merritt]

On 5/13/05, Guillaume Germain <germaing at 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
>