[MUD-Dev] strong encryption for authentication

[Caliban Tiresias Darklock]

On Wed, 11 Jul 2001 09:35:39 -0400, Edward Glowacki <glowack2 at msu.edu>
wrote:

> Quoted from Caliban Tiresias Darklock on Tue, Jul 10, 2001 at
> 08:16:52PM -0700:


>> Why the hell would you want to encrypt it?

>  1. Cheating
>  2. Spying

So... you don't consider these perfectly legitimate applications of
player ingenuity?

I do. I won't say I *like* them, because I don't, but let's face it:
that takes some effort and some thought. I like effort and
thought. When a player comes up with a good little exploit that
doesn't actively ruin the game for other people, I think that's
great. In your two examples, the cheater is finding a wounded player
in a PK area -- which is a known and accepted risk taken by that
player -- and the spy is delivering a desired item to someone who
desires it. I don't think either of those has particularly
far-reaching consequences. I couldn't think of any good reason why
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?

>>  Basically, I started thinking about all the people this would
>>  lock out of the game. People who didn't have the right
>>  encryption. People who didn't understand encryption. People who
>>  didn't like encryption.

> I'll give you "people who didn't have the right encryption", that
> one's a very real concern.  But you don't have to understand
> encryption to benefit from it or even use it.

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.

> There are reasons to dislike *applications* of encryption, that I
> 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.

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
my mail messages in Eudora. It was just a plain old pain in the
ass. Didn't want it or need it. There was just no point. The public
key infrastructure never materialised, so PGP was essentially the
province of a few geeks and paranoiacs. It would have been nice, but
nobody really cared enough to encrypt everything.

Why? Because there was no compelling reason to do so. And there
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?

> Look at a game like EQ or UO where the GAME is spawning real-world
> transactions, people selling characters and equipment online, etc.

Then the people who engage in real-world transactions should apply
what they consider an appropriate level of security. But the game
itself is... well, a GAME. It's not a business transaction. Should
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.

> And it's really not just a game, it's also a social gathering
> place.

Which is, essentially, a CHAT ROOM. Is this rocket science or
something?  Why don't chat rooms encrypt? Well, because there's no
good reason for it. Which is pretty much what I've already said.

> You mentioned business conferences, which could be something you
> are able to have within one of these virtual environments.

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?

> Why *not* just start encrypting everything?

Because there's no good reason for it.

>>  So I'd pose this question, to which I would honestly like to
>>  hear the answer: what *possible* reason have you identified as a
>>  compelling justification for encryption? Because I really
>>  couldn't think of anything. Did I miss something?

> There are lots of good reasons to encrypt, see above.

No there aren't. ;)

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. 

Now, you would like to deal with this yourself, by encrypting data
streams. But why? All of the problems are trivial. The only real
*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.

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
chance that one out of a thousand players *might* be spied on by one
in out of a hundred thousand players.

Wouldn't you agree that this is a boundary condition?

> Encryption should at least be an option, if not the default.  For
> a game where you're in control of the client (EQ, UO, etc.) it
> should be integrated so the user won't ever even *know* they are
> sending their data encrypted.

That would work. It would still serve no useful purpose, but it
would work.

Don't get me wrong on this; I'm doing a lot of devil's advocacy
here. My primary goal is to get all the various bits and pieces
hammered out.  I've written a lot of code in my day that I really
wish someone would have said "what the HELL are you thinking?" about
*before* I wrote it.  I'm not violently opposed to the idea of
encryption in MUDs, but I *am* violently opposed to the idea of
adding features to software that serve no good purpose.

Let's look at what we have.

  1. Encryption would be a Good Thing. Why?

  2. Because it is a Desirable Feature. Why?

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

  4. Well, This and That and The Other. Are these real problems?

  5. Um, no, not really, but they could be. What's the frequency,
  Kenneth?

  6. Ummmmm about ummmm once in a coon's age. What's the resource
  cost?

  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%)

  8. Ummmm not with those problems. Doesn't a 25% speed increase
  benefit all the players all the time?

  9. Ummmm yes but ummm what about those problems? Do all players
  have them all the time?

  10. Ummmm... no. Doesn't that pretty much make your decision for
  you?

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. ;)

> For more traditional MUDs that let the user pick their favorite
> MUD client, then the story changes a bit, but if you get a big
> game or two to start supporting SSL connections, then MUD client
> authors will start getting requests for the feature (if they don't
> find out first themselves) and soon MUD clients will start
> supporting SSL connections.

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

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