[MUD-Dev] strong encryption for authentication

[Caliban Tiresias Darklock]

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.

>>  In other words, if you're not using some sort of encryption, you
>>  cannot have a cookie-based OTP scheme in the first place.
 
> You most certainly can.

Provided, of course, you only accept sufficiently restrictive
definitions of "encryption". But if it is "encryption" when I take a
value and mangle it into a consistently reproducible value, even if
I *can't* unmangle it into the original value, then it is not
possible to have a one-time-password scheme without encryption.

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

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

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

I was saying "there is nothing wrong with implementing a marginally
useful feature if it is easy". I don't think we would disagree that
the ability to post a bulletin board message to a single player is
of marginal utility, would we? Would you put that very high on your
feature list? "New on BumbleMUD: you can post messages to players!" 
-- I don't think we're going to be seeing any full-page ads about
that anywhere.  But if it is easily accomplished, it *is* another
penny in the jar: sure, it doesn't mean much on its own... but they
add up.

Encryption is of marginal utility. 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. 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.  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.

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

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*. I wouldn't have
private rooms, for example, because building a room in interstellar
space would be pretty stupid. I do, however, have plans in the works
for radio channels...  which, when properly implemented, can serve
the same purpose.

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

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?

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.

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