[MUD-Dev] Re: MUD-Dev request rejected
dughi at imaxx.net
Fri Jul 14 12:35:56 New Zealand Standard Time 2000
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
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.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev