From: rjones@itchy.dsd.es.com (Ray Jones - Perp)
Subject: Re: RSA
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Sat, 21 Nov 92 10:29:21 GMT

In article <By1qHG.3yG.1@cs.cmu.edu> hde+@cs.cmu.edu (Herbert Enderton) writes:
>In article <1992Nov20.190452.5446@dsd.es.com> rjones@dsd.es.com writes:
>>	      [...] The reason a PKE method was chosen is because
>>*anyone* can bless a server now.  No more problems withh trying to
>>find the reserved.c.  If a server god doesn't want borgs on his
>>server, all he needs is the Public Keys file.  Which is trivial to
>>get.  *That* is the main reason I suggested and pursued RSA as a
>>verification scheme.  It is not "overkill."  It's not that much
>>stronger than the current scheme.  
>
>Correct, it is not much stronger than the current scheme.  So it
>is not worth all this effort.  It is overkill not in the sense
>that it will do a good job, but in the sense that it's a cumbersome
>and overly general technique for what is really a trivial problem.

It's cumbersome now, because it's still new.  The kinks are still
being worked out.  But they'll soon be gone, and the slight amount of
discomfort is worth experiencing to reap the rewards:

1 - If a binary doesn't exist for the architecture you want to use,
then just generate a key and compile it yourself.  Post the key to
r.g.n, and voila, a blessed binary for that architecture.
2 - If the key gets cracked out, take it off the list.  
3 - If you want to set up a server, and want it to be blessed it's
trivial.  If you want to distinguish between info-borgs and
attack-borgs, that's easy enough, too.  

>>Yes, it does strengthen the defense against borgs on non-borg servers.
>>It makes it easier for server gods to keep borgs out, as is their
>>right.  It also makes it possible to lock out a key that has been
>>cracked out of the binary.  A new key can be generated, and the old
>>one thrown away.
>
>Is _that_ the justification for all of this?  That it will be easier
>to change keys?  

No, there are other justifications, like the ones I listed above.  In
the first two sentences of the paragraph ("Yes, ...") I'm saying that
it is easier to lock out borgs (bless a server) as well as take care
of blessed borgs.

>I thought it was because you didn't trust server gods
>not to make blessed borgs (or to publish reserved.c, as you did in
>with an early INL release).  

Excuse me?  When was this alleged incident?  I have *never* even had a
copy of reserved.c.  Perhaps you are thinking of someone else.

>Maybe if you went through and wrote down
>all your security assumptions and all the mechanisms that you see
>using for adding clients, servers, throwing out keys, etc, then you
>can explain what all of this is good for.  I don't see that throwing
>out an RSA key and getting a new one is really any easier than throwing
>out a private reserved.c-type key and getting a new one.  In either case
>the client needs to be recompiled, yes?

Yes, but only one client, instead of all the clients.  And all the
servers, for that matter.  If you just get a new reserved.c, like the
current one, then you recompile all the clients and servers in the
world.  Then what do you do if that reserved.c gets compromised?  Do
it all again?  Why not just recompile one set of clients, and edit one
file?  One recompile instead of hundreds.  And most of the clients
don't even know that anythign has changed.

>
>>Right now RSA may be causing a little pain.  But in the long run it
>>will be better.  Be patient.  Things will get better.
>
>I think they will get worse.  Because at some point, foolish server
>gods are going to require RSA keys (i.e. not allow the old reserved.c
>keys), and then a lot of people are going to squawk that they can't
>get in.

Everyone has had plenty of time to get the new clients.  Not even the
international players will be locked out, soon, since the binaries
don't have to be crypted anymore, and the source is available, except
for one line that they'll have to take care of themselves.

>When I started playing netrek, there were only two servers, and Terence
>was the man with the reserved.c.  I remember him saying we should probably
>change the key at some point, but that it was too much hassle to get
>a new client release to everybody.  I think he was right.  What you're
>planning is a thousand times as much hassle.  Thanks, but no thanks.
>Just change the key when the NBR comes out, that's all we need.

Buh?  Could you explain that to me a little better?  I don't see how
that can be true.

If we were to change it at NBR, then everyone still has to recompile,
get new binaries, etc. etc.  And what happens if the new reserved.c
gets out again?  You recompile *everything* again.  Cool.  Still no
way to distinguish levels of borgishness (which was a topic some time
back as a proposed NBR feature (?))

Or, we use RSA.  Everyone has to recompile, or get new binaries.  Same
as the other option.  But if the key gest out for one client, you jsut
have to make *one* recompile, and a small subset of the players have
to get a new client.  The server gods don't have to do anything but
run the key manager and add one key while removing another.  And you
get nice side effects, such as the levels of borgishness.

I'm afraid I just don't understand your complaints.  The cost of using
RSA is the same as using a new reserved.c (maybe a little more, due to
the screwy export restrictions, which have been dealt with), but is
better in several ways.  Maybe I'm just seeing more in it than is
really there.  But I sincerely doubt it.

>  -- Bert
--
                                          rjones@dsd.es.com
Newsgroups: rec.games.netrek