[MUD-Dev] Re: Unix is a mud (Re: Ugh, IS Diablo a mud?)

[Jon Leonard]

On Sat, Sep 26, 1998 at 06:06:51PM -0500, Koster, Raph wrote:
[stuff not about data validation and encryption snipped] 

> > I don't know much more about EC Habitat than what you can find on
> their
> > website. I am not allowed to participate in their Beta as I am
> nonamerican
> > (damn racists :). Anyway, the idea is that a server-client model is
> > expensive and inefficient for millions of simultaneous users. 
> > A peer model seems to fit their grand vision (JM Jarre??). I believe
> they 
> > solve hacking by global keys and encryption, which could explain their
> blatant
> > discrimination of us poor Europeans (as if the suffering from 
> > trans-atlantic lag isn't enough).
> 
> Hmm. I've been thinking a lot about encryption and its use for this sort
> of thing, including distributed systems like what it appears Habitat is
> going to use. Mind you, I speak as someone inexpert in these matters...
> but it seems the stumbling block is that you can encrypt transmissions
> all you want, but if the machine you're on decrypts it, then it's in the
> clear in memory and you can get at it all you want and even use the
> client's built-in encryption capabilities to "legitimize" your changes
> to the client's memory. UO has already had a piece of software released
> by a pair of hackers that does exactly this in order to send spoof
> packets to the server...
>
> Anyone savvier than I who can shed light on this issue?

That would probably be me.

There's nothing that cryptography can do to keep the client software from
returning bogus packets.  A hostile user can always run the client under
a debugger and make very small changes. 

All cryptography can do for this is make it easier to detect tampering.
It can make it a lot easier, but you still have to do verification on
the server.  For a MUD it's probably a lot cheaper to verify that the
MUD-related data is possible than to veryify the cryptography, and that
gives you what you want instead of something close to what you want.

There are some more esoteric protocols that might help.  Some examples:

Bit commitment: Send a message to be revealed later.
Fair coin flips: Generate a random number so that no one can control it.
Zero-knowledge proofs: Demonstrate that you know something without saying it.
Secure multiparty computation: Calculate functions without anyone knowing all
	of the input variables.
Digital cash:  Make untraceable anonymous payments.

None of the above are useful if you're willing to reveal all secrets to
the server, and do (or at least check) all computations there.

Anyone really interested in this sort of thing should get a copy of
"Applied Cryptography" by Bruce Schneier.  Those less interested are
welcome to discuss things things with me in email.  (On list preferred
for things that are MUD-relevant, of course.)

Jon Leonard