[MUD-Dev] Re: MUD-Dev request rejected

[Patrick Dughi]

Eli Stevens <wickedgrey at wickedgrey.com> wrote :

> Of course, if you can devise a system to do this without using a true name,
> then this would not be a problem, but...  I don't really see any way to do
> so (anyone care to enlighten?).  To me it seems elementary: identifying
> something positively is impossible unless you have a unique identifier.
> Unless you could devise a system that identified each player uniquely both
> with respect to the identified player AND the identifying player (my key for
> Buffy and Boffo's key for Buffy are different)...  Or would that put you
> back where this question started: storing the info on the server...
>
 	Sure.  Two players, Alex and Bob.  Both have unique identifier,
 and both have a unique key.  Now, Alex wants to know who bob is (he typed
 'look' in the room).  So, lets resolve Bob as he appears to Alex
 internally.  We take Alex's key and use it to encrypt Bob's Idnum.  Then,
 we encrypt that with Bob's key.  In the end, we get something specific to
 Bob as seen through Alex's eyes.  Alex cannot decrypt it, as it's
 encrypted with bob's key.  Bob can decrypt one level, but because his ID
 was encrypted with Alex's key, he cannot unencrypt that, nor does he have
 the ability to generate a new message to alex which shows him as someone
 else - since he does not have alex's key.  Now, what happens if both of
 them work together?  Well, if they share keys, they can - of course -
 decode their own encrypted ids, and then parade around as each other, but
 no one else.  
 
 	One issue here though is that this is a scheme to authenticate an
 individual claiming to be someone.  That is, if someone claims they're
 Bob, you can prove decisively whether they are or not. However, if someone
 claims they're Tex, you cannot prove one way or another if that person is
 really Bob in disguise.  This is because if bob changes any piece of
 information (like personal key, personal id (duh), or makes a random
 change to any sequence in the output from either encryption) he will look
 like a new person altogether.  Simply put, he will look like anybody
 except Bob. This is !Bob. :) This may be great for disguises, but it
 points out a large problem;
 
 	How does my client reference someone when all I have is an alias
 and a potentially one way twice encrypted string that was last encrypted
 using the other person's key? 
 
 	Either I can nab every player's key, perform the entire encryption
 sequence, and check for a match, or I can change the way the system works.
 
 	I can't just send them something encrypted with a 'server string'
 - then all players could share it.  If I encrypt it with the victim's key,
 then I'll still need the victim, and must perform the entire encryption
 validiation sequence for each player till the correct one is found.  What
 you'll have to do, and this is not so very difficult, is to eschew some
 parts of security, and assume the player will never, ever, be able to
 view, or alter their key.  Then, it would be safe to pass each player a
 singly encrypted string, of the victim ID crypted with their own key. 
 
 	Disguises are now a lot more difficult; you'll have to use a new
 victim ID each time the victim assumes a unique identity.  That also means
 storing virtual-id to real-id lookup tables on the victim whether they
 were/are disguised at that point in time: 
 
 	Mary disguises herself as Sue. (and gets a new id num)
 	Sue meets, greets people.
 	Later, she reverts back to Mary.
 	3 days later, Joe says Sue was spamming him with offensive
 material, and you need to talk with her about it.
 	Joe can only give the name 'sue' and his encrypted string, which
 resolves to an id num of a player no longer in existance.
 	
 	This applies to other situations too; many muds have a mail system
 based on idnum; it's against the point of a disguise if you can attempt to
 mail them and they don't exist.  Any id-match function will have to
 reference an id table with all matches made.  This is probably going to be
 a pain - though you could use a special-case string for the id.  As a
 matter of fact, this will work fine. If someone was id number 32, when
 they switched to whatever, they'd have an id string like "32:1", where the
 colon acts as a seperator and '1' is the unique id for that disguise (if
 someone dreses up the same way 2x, and you've only seen them like that,
 you'll associate that as the same person, not two different ones).  It's
 easily doable.
 
 	As for encryption algorithms, I think it goes without saying that
 you'll have to use one that's reversable, if you expect to have real-time
 lookups in situations where the intended party may be your entire player
 base (online or everyone, case dependant).
 
 	So, end result, the client gets the victim id num encrypted with
 the client's key.  A server will modify the victim id if the victim is
 disguised so they'll appear as a new person.  No one ever sees their own,
 or others keys, and keys are stored on the server.  The server than has
 the ability to decode any given string coming from a player, but the
 player does not.
 
 Of course, I may be wrong.  I could easily be bs'ing you inadvertantly.
 
 						PjD




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