[MUD-Dev] Trusting the client, encrypting data

[Sean Middleditch]

On Tue, 2003-12-16 at 07:19, Ola Fosheim Grøstad wrote:
> Jessica Mulligan <jessica at mm3d.com> writes:

>> one person has a method down, everyone will know it.  I remember
>> once on UO we spent several weeks rewriting the encryption; it
>> was pretty damn good, too.  It was broken in less than three
>> days, sending something like a man-month of engineering time down
>> in flames.  I'm sure we can all repeat stories similar stories.

> I don't have any course on crypto, but I can't see how the
> encryption itself could fail provided that you design for it. If
> common headers are a problem, then avoid them. For instance
> huffman-encode them and put them in a dictionary, which is a good
> idea anyway, (make every single bit count) and send the packets in
> random order making predictions about content useless. (or
> possibly prefix with a random length string of noise)

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.

If the data exists on the local machine, it will be found.  If the
keys exist for decrypting the data on the local machine, they will
be found. If you don't want the user to get that data, you have to
never even send it to their machine, because once it's there, they
can get it. Encryption will stop the people between the server and
the user from seeing it, but that's it.  And that's not worth a
whole lot.  Even when you *do* have a reason (such as Sony trying to
stop ShowEQ), the users have all the information they need to break
any and every encryption mechanism you can possibly create, so it's
pointless.

This exercise has been proved over and over again, both in games and
in other industries.

>> If you do come up with a method that works reliably and stays
>> unbroken, you'll be a very rich and sought-after man and American
>> women will want to have your babies.

> Unbroken is relative though. If it takes 1 year to break the key
> on one PC then you pretty much have what you want.

It isn't necessary to break any keys.  The key and decryption method
are sitting right on the user's hard-disk, in the game binary.  And
all the data is stored unencrypted somewhere (be it on disk or in
memory) since it has to actually be used.

You're only real hope is something like the TCPA mixed with
Microsoft's Palladium, where you can tell users they aren't allowed
to access their own machine's data.  Your game probably wouldn't
sell very well if you abused costumers' own property like that, tho.
Other companies' attempts at Digital Rights Abuse^wManagement have
been met with very fierce customer reaction.  (Many such products
have official patches removing this abuse of technology.)

--
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev