[MUD-Dev] strong encryption for authentication

[Travis Casey]

On Wednesday 18 July 2001 19:54, Caliban Tiresias Darklock wrote:
> On Sun, 15 Jul 2001 23:00:20 -0400, Travis Casey
> <efindel at earthlink.net> wrote:

>> Neither of these is a form of encryption.  They are forms of
>> access control, which is a different, albeit related, thing.

> So is a hash, actually. A hash is one-way. You cannot undo a
> hash. If a hash is encryption, then any number of other one-way
> encoding schemes are also encryption. Even the CRC in every TCP
> packet would be a form of encryption.

You are correct; I should have said in my original post, "without
some method of protecting the information being passed back and
forth to perform authentication being in use, this scheme provides
very little extra security against someone sniffing packets."  I was
lazy and used the term "encryption" loosely when I shouldn't have.

>> From what you initially stated, there was no evidence that this
>> would be necessary.

> The evidence was not intended to display the security of my
> system. It was intended to demonstrate that while I disapprove of
> encryption "across the board", this does not mean I disapprove of
> security or privacy. Where privacy and security make sense, they
> are desirable.  Everywhere else, they're completely optional. With
> it, without it, who cares? A secure game that sucks still sucks.

Your original statement was:

> I did have a distinct problem with *forcing* people to send
> passwords in the clear, so I devised an optional cookie-based OTP
> scheme for that.  But beyond that, I couldn't see any legitimate
> justification for wasting the CPU power necessary to encrypt
> EVERYTHING.

The way you stated it there, this didn't seem to me to be either
private or secure.  As I've already said, with the clarification
that the cookie is used to hash a password, it now makes sense.  All
I was trying to do was clarify *why* I made the statement I
originally made.

>>>  Public communication is essential to any game which forms the
>>>  basis for an ongoing community. Private communication, however,
>>>  is merely incidental. When it is cheap in terms of resources,
>>>  there is no reason not to support it. When it is expensive,
>>>  there is no reason to worry about it.

>> Communicating with other players about such real-world matters is
>> a major reason why many people play muds.

> I don't see the word "privately" up there.

It was implied in the "such real-world matters", which is referring
back to my original statement:

2 - People on muds can and do talk about private, personal matters
with others on the mud.  Arguably they shouldn't, but that's neither
here nor there.  The point is, encryption makes it more difficult
for others to intercept such chatting.

Again, I should have been clearer.

> Could you in good conscience *insert* it without significantly
> altering the truth of the statement? I don't think so. You might
> be able to weasel around with a technicality, but I think you know
> as well as I do that private communication is one of the *last*
> reasons people have for playing multiplayer games.

No, I don't know that as well as you do, apparently.  In my
experience, people on multiplayer games often go to private rooms in
those games to conspire, have mudsex, talk about their real-life
problems, and do other chatting that they would probably not like to
have other people overhearing; indeed, the fact that they don't want
others overhearing it is *why* they go to a private room.

It's possible that we have very different experiences of multiplayer
games -- but please do not presume to tell me what my experience is.

>> How is this any more private than two characters chatting in a
>> private room on the mud?  You haven't specified any encryption in
>> this system, so it's just as vulnerable to being sniffed.

> That was not the point of the example.

Let me quote what you wrote:

> Public communication is essential to any game which forms the
> basis for an ongoing community. Private communication, however, is
> merely incidental. When it is cheap in terms of resources, there
> is no reason not to support it. When it is expensive, there is no
> reason to worry about it.

> An example: assume you have a MUD which allows players to write
> bulletin board posts. [snip rest of example]

Since in the paragraph before the example, you were talking about
private communication, and you said nothing to indicate that your
example did not relate to it, I naturally believed that you were
making an example which related to private communication.  If that
was not your intent, perhaps you should have made that clearer, by
saying something like:

  An example of an easy feature to add would be if you had a MUD ...

Such a beginning would have given an indication that you were
talking about something else, rather than continuing to talk about
private communication.

In any case, though, with your having clarified your meaning, I
agree that there's nothing wrong with implementing a marginally
useful feature if it's easy.

> Encryption is of marginal utility.

I disagree.

> It protects the software developer from the need to write a slim,
> efficient protocol that sends only what it must, because he can
> rest assured that nobody will see it.

I would argue that it does not -- or at least, it only does if
*everyone* is using poor protocols.  The end user can still see the
amount of traffic going back and forth, even if he/she cannot *read*
that traffic.  Indeed, since encryption generally makes data larger,
it creates a *stronger* need to write an efficient protocol.

> It protects the end user from the need to consider his audience
> before speaking, because he can rest assured that his audience is
> hand-picked.

This depends on the way the game is set up.  If there are such
things as crystal balls, scrying spells, and the like, the player
may still need to consider his/her audience.  For that matter, even
when you are hand-picking an audience, you may wish to consider who
it is -- for example, when you're talking to Boffo and Buffy, you
may not want to talk about certain topics that you'd talk about if
Boffo were not there.

> It promotes a false sense of security on both sides of the
> fence. It has no, I repeat, NO positive outcome. Even in terms of
> packet sniffing: if something that essentially never happens
> doesn't happen, we have achieved essentially nothing.

Again, I disagree.  You're free to disagree with me, of course.  As
I said in my original response to your message: "different people
will disagree on what's 'compelling'."

>> So?  You didn't ask for "reasons that would make me want to do
>> encryption." You merely asked for "good reasons", without
>> specifying what the criteria for "good" was.

> Actually, I believe I asked for *compelling* reasons. That's
> rather different.

Sorry, my faulty memory -- but as I just mentioned, I said in my
first message that different people will disagree on what's
compelling.  To me, those reasons are compelling.  To you, they're
not.

> And remember, this is not a "right/wrong" battle. This is a
> "sensible here/sensible there" battle. What makes sense on *your*
> game doesn't necessarily make sense on *mine*.

And again... oh, skip it.  :-)

>> I consider the reasons I gave to be good reasons.  If you do not,
>> then, well, that's your problem (or your player's problem,
>> really), from my point of view.

> Generally speaking, the reasons I hear from people seem to revolve
> around the inherent assumption that the only way to make things
> "fair" is to force the aggressive people to *stop* being
> aggressive, or at least to waste their time if they insist upon
> it. What I'm challenging is the corresponding implicit statement
> that aggressive players are somehow bad. It's a lowest common
> denominator argument: many people are passive, so we must prevent
> the advantages normally associated with aggression.

None of the arguments I gave have anything to do with this, unless
you consider my statement that "you might want to make cheating
harder" to be a variation of that.  In any case, though, at least 3
of the 4 reasons I gave for using encryption of *at least some
traffic* (and note that I said that from my first message as well)
have nothing to do with that.

> But beyond this argument, lowest common denominator solutions are
> roundly castigated throughout the community. If I suggested EQ and
> AC run smaller and less capable worlds because they make things so
> much harder for the independent free MUD operators, I'd never hear
> the end of it. If I suggested that game developers produce games
> with less FMV because many people have slow CD-ROM drives, I'd
> never hear the end of it. Yet when people suggest we produce games
> that diminish the capabilities of the aggressive player to give
> the passive player a fighting chance, that's acceptable. Why *is*
> that?

Because different people want to play different games -- and in
particular, they want to play games *with* different people.  A
skilled chess player can beat a poor one every time, and I have no
problem with that.  On the other end of things, many children's
games are almost purely random luck, with no skill involved at all
-- and I also have no problem with that.

Is it acceptable for some games to give a more level playing field
than others?  Of course, I'd say!  If you don't like those games,
then simply don't play them.  There's no logical reason to castigate
the creators of, say, Parcheesi for creating a game that involves
almost no skill -- they did it deliberately, because they wanted to
make a game that parents could play with their children without the
parents having to "hold back".

Thus, I'd have to counter your question with another -- why
shouldn't it be acceptable?  Do all games have to be designed with
the same goals?

> And why are we so violently opposed to the idea of MUD==game, yet
> staunchly adamant that a MUD must have rules and those rules must
> be enforced? It's *not* just a game, we cry, but you have to play
> by the RULES. We strive to create games that *transcend* rules,
> that manage themselves and evolve over time, but we still have the
> same absurdly complex acceptable usage policies.

> This... is Chewbacca. Look at the monkey. Look at the silly
> monkey.

I've never violently opposed the idea that at least some muds are
games; I oppose the idea that *all* muds are games, since some are
used for other purposes, but that does not mean that you can't cheat
in a mud that *is* a game.  Thus, to me, saying that encryption can
help prevent cheating makes perfect sense.

Some people claim that "it's part of the game."  To them, I pose
these questions:

How would you feel about someone playing Monopoly who insisted that
the fact that their attempts to steal money from the bank were "part
of the game"?  How about someone who insisted that doing a
ping-flood on your machine to make you lag was "part of the game"?
How about a kid playing a card game with a sibling, who threatens to
tell their parents that the sibling has been stealing cookies unless
the sibling shows their cards?  What if one kid threatens to beat up
others unless they let him/her take an extra turn?

Many -- I'd dare say most -- people believe that using exterior
means to influence the play of a game is cheating.  Why should that
be any different just because the means used is technological?

And, before you start up with the "some people are always going to
be better than others" spiel: yes, I know that.  However, some
methods of "being better" are acceptable within the game, while
others are not.  Yes, this distinction is arbitrary.  But that does
not mean that it doesn't exist, nor that a mud's designers are wrong
to try to enforce it.

At any rate, I think I've said everything I need/want to say on this
topic: I've maintained from the start that reasonable people can
disagree on this matter.

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_) 

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