Re: Game idea....

[Christoph Reichenbach <creichen@rhein-main.netsurf.de>]

Hi,

> > Hmm, an improvement (though not a solution) for this problem might be to send
> > the lookahead data encrypted. The key will still have to be sent, but, since
> > it's usually considerably smaller, the server will be able to wait much longer
> > before starting the transfer, while actually transmitting more and better
> > lookahead data. (This might also help performance). Since even very weak
> > encryption (RSA with 128 bits or something like that) is quite hard to break
> > with conventional means, the client data is "almost safe"; updating it (with a
> > new key) regularly will make it "practically safe".
> But, since the player have access to the source code, he can -still-
> modify the client. Or, as many of my objections focus on; he can use the
> client code to write a proxy that enable him to cheat in a wide varity of
> ways.

And just how should that work if he doesn't have the key?

> With binary distributed code only, encryption (where the keys are updated
> frequently) can help solve a lot of the problems. With source available,
> I cant really see a solution.

I'm talking about /encryption/ here, not /obfuscation/. If you encrypt
something with one of the usual algorithms, you can only decrypt it with the
correct pair of prime numbers (or near-prime numbers). Finding them with your
average Alpha cluster takes a few hours, for small keys.
Having the source code won't help you there. Most of those algorithms are well
documented, so anyone who knows how something is encrypted can decrypt it-
provided that he has the correct key.

llap,
 Christoph