[MUD-Dev] strong encryption for authentication

Fred Clift fclift at verio.net
Fri Jul 13 11:56:59 New Zealand Standard Time 2001

<warning - this is long>

On Wed, 11 Jul 2001, Caliban Tiresias Darklock wrote:

> it should be disallowed, either. Players *should* hack the game,
> reverse-engineer the protocol, and know every byte their client
> sends and receives. If they intercept someone else's information,
> I think they have every right to inspect it.

> Now, ALTERING it, I have a problem with. But I tend to think
> that's going to be a minor problem, if it ever crops up at all.

> That aside, let's stop and think: has this ever actually HAPPENED?

Have you seen the 'auto-aiming' proxies for FPS games?  they alter
the trajectory of your ammunition as you shoot it to make it
'always' hit your opponent, even when you're doing back-flips down a
corridor and your opponent is partially obscured...  So, I'd say
"YES" it has happened.

> You do at this writing. Whatever encryption scheme you decide
> upon, the player has to acquire a compatible client. At first,
> that will be...  your client. Period. And you will NEVER really
> free the user to choose his *own* client. I don't like that. That
> means I have to develop TWO products, instead of just one.

Or you allow non-encrypted access with whatever client they want, or
technical information, and at least one supported client so that
_if_ they want, they can connect using encryption.  It could be as
simple as telnet option support and then waiting for the client
writers to play catchup, while providing 'hard to use' but possible
access for those with skill who care.

> > can understand with things like DVD's, music, etc., but to
> dislike > encryption itself doesn't make sense.

> I think encryption is a pain in the ass. If I can avoid it, I
> will. If I don't think it's necessary, I don't want it. I need a
> *real* reason to use encryption, and it better be a good one.

Just remember that beauty is in the eye of the beholder.  Several
people have provided compelling reasons to allow encrypted
connections to their creations.  Just because you find it to be a
pain in the ass doesn't mean that others dont desperately want it.

> And until that situation changes, this will remain the case. I
> didn't like PGP even when I could right-click to encrypt and/or
> sign

PGP is useful only in a few cirucumstances -- dont care if someone
snoops my mother's chicken casserole recipie, but if I need to send
an important password to someone I can't easily call on the phone,
then having previously exchanged and verified fingerprints on pgp
keys, mailing pgp encrypted stuff is a great way to do this.  The
people that I have to exchange pgp encrypted stuff with, I've
probably seen at least one time in real life, so I (could) have
exchanged keys physically with them.

> province of a few geeks and paranoiacs. It would have been nice,
> but nobody really cared enough to encrypt everything.

You talk like noone uses pgp - like it is 'dead and gone' - you are
very wrong.

> still isn't. My credit card information has been sent in the clear
> across the net dozens, if not hundreds, of times. I have never had
> a single problem. Now, if I can happily send my credit card info
> spiraling off through who knows how many routers, SMTP servers,
> and gateways without a problem... don't you think the average
> player can pretty much do the same with his gaming?

Looks like you've been foolish and lucky -- my credit card _has not_
been sent in the clear over the internet hundreds of times - perhaps
only a few times, and yet, shortly after one of those transactions,
mysterious purchases in mexico city started showing up.  I didn't
loose much money on the deal, but now I have a 'low limit' card for
internet purchases.  And, if access to the game provides potential
shell access to my server, well, I get cranky.

> my MUD support credit card transactions and escrow arrangements
> with shipping calculations because someone may want to buy someone
> else's character? I don't think so. That's not part of the game.

Why not?  It can be a good revenue stream for the owners of the
game.  The trick is to make it easier to use your tools (for which
you get a cut of the cash) than to use tools external to the game
(ie ebay).

> Which is, essentially, a CHAT ROOM. Is this rocket science or
> something?  Why don't chat rooms encrypt? Well, because there's no

Some _do_ encrypt :).  Because people want to chat with more
likleyhood of not being overheard.

> And which are already supported by very nice business-oriented
> applications which are compatible with any number of encryption
> standards. What self-respecting business would conduct a sensitive
> meeting on a public server anyway?

Half of our marketing staff uses AIM to communicate important
confidential business information to each other.  It makes me queasy
thinking about it.  AIM was blocked on our firewall, and a VP of the
company got all over the operations staff for hurting an existing
business practice. If AIM supported some kind of encryption, then
I'd have less fear.

> So far, you've pegged three potential problems.

>   1. People could be spied on.
>   2. People will want privacy.
>   3. People may engage in RL commerce.

> My response to these three situations is:

>   1. The game is a public environment. Deal with it. 
>   2. The game is a public environment. Deal with it. 
>   3. The game is a public environment. Deal with it. 

The way I deal with it is by trying to provide secure mechanisms to
do these things when it is feasible.

> *problem* is that someone with a high degree of specialised
> knowledge and skill may produce an application that allows people
> to spy on one another given an appropriate real-world opportunity.

> Now, what percentage of people will do this? Well, maybe 0.001%,
> at the outside. Who will it affect? Oh, maybe 0.1% of players, at
> the outside.

lets do some math:

50000 players of some online game, yields .5 person who will figure
out a way to snoop/crack - he writes a program that makes it so a
14-yr old with

>   3. Because it prevents Undesirable Results. What are they?

no training can do the same, then your .001% rises to 3% or 4% which
is 1500 people, which will affect thousands of players rather than
the 50 you suggest.

> The other 99.989% of your players don't give a shit. But you're
> going to make them do it anyway. All the time. Just on the off

Never said I was going to force my players to use encryption -- just
something I'd _allow_ them to turn on if they wanted it, like I want

> Let's look at what we have.

>   1. Encryption would be a Good Thing. Why?

>   2. Because it is a Desirable Feature. Why?

In my case, add secuirty to the server box, keep anyone with root
access to a box in the same co-lo facility from being able to
impersonate or abuse users, log in as one of the imps and drive
people from the game, etc.  Others want to do secure financial
tranactions, or want to procted their players from their draconian
network providers - there were other reasons suggested too.

>   7. Ummmm about 20% of the CPU power used by the game. Wouldn't a
>   25% speed increase be better? (current speed == 80%, new speed
>   == 100%, 100/80 == 1.25 == 125%)

20% of an otherwize idle cpu is still not hurting me any.  My mud is
all IO bound anyway.  The second CPU is there for fast mud builds
and for pissing contests with my friends.

> If you'd like me to continue this line of reasoning through
> hardware encryption accelerators and convincing ISVs to add
> encryption to their clients, I could, but the results aren't
> pretty. ;)

Yeah they wouldn't be pretty because they would continue to use
fallacious reasoning, misinterpret probability, mathematics and
human nature.

> Only a very few of them. The rest will go on not even properly
> supporting the telnet standard. :P

I care about the ones I use.  And after that, if my users care they
can pester the maker of their favorite mud client to add the
features, or they can even do it themselves.


Fred Clift - fclift at verio.net -- Remember: If brute 
force doesn't work, you're just not using enough.

MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list