[MUD-Dev] Trusting the client, encrypting data

[Peter Harkins]

On Tue, Dec 16, 2003 at 11:23:13AM -0500, Sean Middleditch wrote:

> The problem is, encrypting is pointless.  Encryption stops the
> data from being read/modify by someone between the two trusted
> parties.  If you're running the client on the user's machine, tho,
> then that machine is one of the trusted parties - but you're
> trying to stop the user of that machine from reading the data;
> i.e., you're automatically assuming that the person you're trying
> to stop from getting the data is a trusted party.

This discussion has veered a bit into reiterating the old "don't
trust the client", which the original poster never suggested.

The deal is: if you don't trust the client, can you send any data
for things that the player shouldn't know about yet but probably
should soon -- like what's on the other side of a door. The solution
proposed is: symmetrically encrypt the data, and send it to
them. Then when they need to know the data you can just send the key
(hopefully small) instead of the data (a larger amount of data),
reducing some delays.

Never was it suggested that the client have the key beforehand,
which is obviously a dumb move. This idea may sound superficially
similar, but a careful reading shows it to be significantly
different.

It struck me as an interesting scheme, and probably quite viable in
many fast-paced games. Whether the server has the spare CPU for it
is probably the most important question, but the encryption doesn't
really have to be especially good. If it takes the client an hour to
brute force data that's really only useful in the next minute,
there's no problem (tuning for the game's particular needs, of
course).
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev