From: mcp@cs.umd.edu (Mike Polek)
Newsgroups: rec.games.netrek
Subject: Re: RSA stuff
Date: 16 Oct 92 20:16:13 GMT
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742


In article <1992Oct16.013309.10523@cs.ucla.edu> jsin@oahu.cs.ucla.edu (Jonghoon Sin) writes:
In article <1bl0dsINN98b@usenet.INS.CWRU.Edu> mcn@b62103.student.cwru.edu writes:

>
>I have not tried the GNU MP library yet.  I suspect I'll need it for other
>architectures I plan to compile it on - thanks for the warning.
>

Ok, here's the scoop... a lot of people have been having trouble with the
mp or gmp libraries. If you want to know if things are mostly ok, use
the "ray jones" rsa_util.c. If that doesn't work on darmok with the test
key, send me mail at the above address.

-Other comments:
-1) It's a pretty good idea, but what happens if you want to invalidate a key?  
-You have the .reserved file which is essentially nonsense binary. If, for  
-example, I want to remove the sun4 key, how would I do that? 
>
>What I plan to do is save a copy of each public key (as in pubkey.sun4, 
>pubkey.sun4.jsin, pubkey.sun4.hadley, pubkey.sun3, pubkey.ibmrt, 
>pubkey.dec3100, etc), and rebuild the .reserved file each time I want to 
>invalidate a key.
>

Yup, I plan on posting by client... all architectures for a particular client
in one file. Andy McFadden has suggested that we probably need a better
form of key management, and I agree. I just don't have time to write it
at the moment. Perhaps soon....

-2) How would I know for example, that Mr. Borg (R2) is using the Sun4 key? I  
-mean, invalidating a key would be great if it gets out, but how do we know  
-which key any given player is using?
>
>Good question.  
>
I have considered this, and I believe that what would be necessary would
be to write the key id (required a mod to .reserved) to the logfile. 
In other words... Joining so and so using key #7. In conjunction with 
a key manager, you could deselect key #7. When we get a key manager,
it should keep in mind that this patch will probably be forthcoming.

-3) Fallback to reserved.c would be pretty nice, at least until it takes off...
-Maybe setting the CONFIRM flag to 0 for nothing, 1 for RSA/reserved.c, 2 for  
-RSA only... That way it could slowly be phased in...
>
>I don't think current RSA server can accept the standard reserved.c w/o
>(sizable?) modification to the client/server code. (But then what do I
>know :-).
>
The RSA scheme uses a different sized RESERVED packet. The scheme is
incompatible with the old one. One way it kicks you out, the other way
it hangs, and I don't remember which is which offhand... It is annoying,
and I wish the new server had been able to accomodate the old system
when necessary, but Ray wanted to make as few changes as possible...
so that's what we've got. If there is enough clamoring for backward
compatibility, I'll consider working on it. 

>Which brings me to the question: when you try to get in to the server with
>the bronco reserved.c client, it doesn't kick you out and says you need a 
>blessed client (which does happen if you use a client with invalid key) - 
>what happens is that your client will see a bunch of invalid packet types 
>and then will not respond to any commands.  Your windows won't update,
>etc, so you will end up killing it manually thinking that network connection 
>got hosed somewhere, rather than thinking that you need a blessed client.
>This should be fixed, methinks.
>
Um, yeah... what I said above...

>Also, it seems that the test server darmok.cs.umd.edu does *not* accept the
>default (test?) keys.dat shipped with the server source tar file.  Is this
>correct?  Mike?
>
Try compiling with the rsa_util.c (not mp or gmp) and let me know if it
works. If you're on a sun4, try one of the binaries on pittslug.sug.org
under pub/netrek/rsa... the static one should work... Let me know what
is and what isn't working for you. The  more info I have, the better
I can serve the needs of the netrek community. (I should be in politics)
>Maybe I'll go compile mp library for the HP9000s, SGI Indigo, and RS6000...
>Later...
>-- 
>John Sin       <jsin@janet.ucla.edu>  ...!uunet,ucbvax)!seas.ucla.edu!jsin
>UCLA EE Dept.  53-109 Engineering IV, Los Angeles, CA 90024  (213)206-7983

Mike Polek
<mcp@cs.umd.edu>
<Zen Ogger>
<keeper of the code>
<keeper of the keys, for now>