[MUD-Dev] strong encryption for authentication

[J C Lawrence]

On Fri, 13 Jul 2001 11:34:25 +1000 
Ben Tolputt <bjt at pmp.com.au> wrote:
> Quoted from Caliban Tiresias Darklock (Thursday, July 12, 2001
> 01:29 PM)

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

> No, I don't - I think that they're applications of hacker
> ingenuity.

> The general player (of my MUD) does not have the technical
> expertise to hack the protocol, sniff packets from a router,
> etc. It is giving players an out of game advantage unrealated to
> their character - in my book a Bad Thing (tm).

In a GoP game arguably the only difference between the two is that
one set are finding the fastest route to the cheese along paths you
agree with, and the other are using paths you don't agree with (or
for which they many reasonably expect you don't, all arguments as to
mind reading aside).  Historically expecting players in a GoP game
to not take advantage of a known-faster route to the cheese (eg
ShowEQ, ping floods directed at opposing players, etc) has been a
statistically good bet across the player base en masse, but a poor
bet across any reasonably globbed sample set (eg all the players on
a game at any one time)

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

> Another thing I agree with. If the other end doesn't do it
> automatically and/or you must take extra step for every
> transaction, encryption is not worth the effort. However, if the
> encryption is transparent to you the user - how is it a pain?

My main use of PGP/GnuPG at this point is for digital signatures as
a guarantee of authorship of a given item.  Encrypted mail is
attractive for relatively few of my cases.  Ability to verify that a
given item was signed by me (Schneir's Secret's aside) is damned
useful.

  And yes, I religiously verify the digital signatures on most of
  the source balls I download, most especially kernels.  Happily, in
  the case of Linux kernels, there's the dlkern package to make that
  painless.

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

There are interesting corner cases where the participant is sourcing
from a network they don't trust, and for which exposure of their
activities would be unwelcome.  Playing games at work is the best
known case.  Various support groups, rehab, groups which offend
local more's (extremist case: adulterous tinysex in a country where
it is a capital offence) etc are more sympathetic cases.

> Great, but I would like to implement a game where the player can
> feel secure that they aren't being spied on, for whatever reason.
> Is this a bad thing? I don't think so.

There are two levels of guarantee there:

  Your certainty as provider.

  Their certainty as player.

I wouldn't give much for the former.  The latter is reasonable given
a capable end user.  Perhaps ironically the less capable end users,
who are the ones with the most to be concerned about typically don't
know enough to be worried, let alone knowing what to worry about.

Its a reasonably feel-good item tho.

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

> Well, you get what you pay for :-)

Few telnet clients, commercial or otherwise, fully support the
telnet RFC.

--
J C Lawrence                               ("`-''-/").___..--''"`-._         
---------(*)                                 `6_ 6  )   `-.  (     ).`-.__.`)
claw at kanga.nu                               (_Y_.)'  ._   )  `._ `. ``-..-'  
http://www.kanga.nu/~claw/                _..`--'_..-_/  /--'_.' ,'         
I never claimed I was human             (il),-''  (li),'  ((!.-'           
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev