[MUD-Dev] strong encryption for authentication

[Caliban Tiresias Darklock]

On Fri, 20 Jul 2001 13:01:50 +1000, "Ben Tolputt" <bjt at pmp.com.au>
wrote:
> Caliban Tiresias Darklock quoted on Sunday, July 15, 2001

>> I think the failure in most PvP games is their assumption that
>> people will play fair, and their insistence upon trying to FORCE
>> them to play fair. Assume your players will cheat, and design
>> around it. Those who don't cheat will be at a disadvantage, but
>> they know that going in.

> I agree assuming how players intend to play the game (be it fairly
> or cheating) is not the best way to design a game. In my case
> though, I'm not assuming that all players can cheat - and as such
> I want to 'try' and level the playing field.

Remember, you can level in either direction. You can bulldoze the
hill, of course, but you can also fill in the area around it.

> the client needs to know about what types (and 'possibly' the
> position) of avatars/monsters are in a zone so that it can load
> the appropriate graphics.

> It is cases like this where I think that encryption is a good
> idea...

But it is cases like this where encryption won't help. Sure, I can't
see what the protocol is requesting, but I can certainly see what
the client is loading. Encrypting that data provides absolutely no
security. Anyone who can scan and filter packets on the network can
also scan and filter local API calls from the client.

>> There are in-game facilities for that, too. Chances are this will
>> significantly cut down on the number of "private" discussions
>> that get held in the first place.

> Why should people not be allowed to conduct 'private' discussions
> online?

I don't want to *forbid* private discussions, just discourage
them. I would rather have my players interacting with the whole
playerbase, instead of just getting together with their friends and
ignoring everyone else.

Of course, people will want to gather in little distinct groups, so
I need to permit some variety of private conversation. One of the
concepts I'm thinking of is a sort of CB-radio functionality. Every
ship would have a radio with 40 channels. Anyone can transmit on any
channel. If you transmit on a channel, anyone tuned to that channel
will hear you.  You can only tune to one channel at a time. The
radio may be turned off.

An encryption device can be purchased and attached to the
radio. This device accepts a password. Once you enter a password
into the encryption device and turn it on, only people who are tuned
to the same channel *and* have entered the same password will be
able to receive your transmissions. Unencrypted transmissions may
optionally be ignored.

This is all done entirely by the game server, and does not reflect
any actual encryption; it simply iterates through online players:

	If 	
		the radio is on 
		and tuned to the same channel,
		then if 
			the message is unencrypted 
			and unencrypted reception is allowed
			*or*
			the message is encrypted 
			and has the same password

			Deliver the message to this recipient.


There is no internal facility for secure password
exchange. Distributing and protecting the password is your problem.

The purpose of this construction is to design a "private" message
functionality that is on the one hand convenient, and on the other
hand inherently insecure -- if you want convenience, it's useful,
but if you want security, it's a BAD (Broken As Designed)
mechanism. It is also, in many cases, decidedly INCONVENIENT:
multiple channel monitoring is not supported, multiple password
management is not supported, and there's no way to be sure your
intended recipient is actually listening. Channels do not have a
distinct purpose or topic, and there is no facility for defining or
enforcing such a purpose or topic. You cannot kick someone off the
radio because they're annoying you; you just have to change the
channel. Of course, so can they.

But ideally, this will end up adding value to the game, because the
players can define all the specifics themselves. The system's
limitations are also *liberations* in a sense; a group of people can
agree to use channel 13 with the password "bumblebee", for example,
and there's no red tape to prevent this. They just have to fire up
the encryptor and type the password. Compared to the normal process
of haggling with the administrators over whether you deserve a
channel and which channel you can use and what the name of it will
be and who will be in charge of managing it, this is a positively
intoxicating degree of freedom.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev