RSA The new RSA blessing scheme for clients ---------------------------------------------------------------------- From: rjones@itchy.dsd.es.com (Ray Jones - Perp) Newsgroups: rec.games.netrek Subject: Re: RSA-reserved.c Date: 5 Sep 92 19:09:39 GMT I'll try to make this as short as possible. It's based on Public Key encryption, of the RSA variety. Each client has two numbers associated with it, the public and private keys. The server sends the client a random string of characters. The client encodes it with its private key, sends back the encoded message, along with its public key. The keys for each client will be different, so the public key can be used to identify a client. The server checks two things. First, that the public key is on its "list" of accepted clients. Second, that the encoded message from the client decodes into the original, whenthe public key is applied to it. That's how Public key encryption works. In RSA, any message encrypted by the public key can be decrypted by running it through the exact same formula, with the private key in its place. And vice versa. So as long as the private key stays hidden, you can verify that a client is who it says it is. And if anyone discovers the key, you can just take it off the list. Did I miss anything? rjones@dsd.es.com ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: rec.games.netrek Subject: Re: RSA-reserved.c Date: 5 Sep 92 21:57:03 GMT >Did I miss anything? That's how the algorithm works; how the rest of it works is... - anybody who builds a client gets private/public keys. There will be different sets of keys for each client (Sun4, Dec3100, Amdahl mainframe, etc) - the clients will continue to be distributed as they are now, in binary form via anonymous FTP. - all servers will maintain a list of keys, hopefully in a separate config file. there will be one entry for every known client. - some sort of id will be added to the log file, so that if somebody is using a borg, the server admin can figure out which code was broken - if a blessed cyborg is identified, all clients using that key will be rejected on all servers (presumably they will communicate through r.g.n). (This would have allowed all the servers to unload that hoser with the blessed Beef borg who posted here a week ago.) If the code DB includes stuff like "client author e-mail address", a new client can be built with a new code and redistributed in a few days. - servers can have extra keys in their database, allowing special clients on their server (I'm thinking of the enhanced Calvin client). There may also be officially "blessed" cyborgs which would have a different set of codes, so that borg servers could enforce equal-footing rules during certain hours. The weak link is the client (as usual): if somebody can pry the private key out of the client code, they can add it to their borg. What makes this a big win is that having the server code doesn't do anything for you (so it can be distributed freely), and getting somebody's client code isn't that helpful anymore because the clients can be selectively deactivated and redistributed with far less impact on the Netrek community as a whole. Players in countries without generous export licenses will have to fend for themselves. One possibility is to have a "European authentication" scheme which will be tried if the RSA one fails. However, the server would have to verify the IP address somehow to make sure that the client was really in a different country. I would suggest leaving something like this (perhaps just the original reserved.c code) in the source code so that people in other countries don't have to reinvent the wheel if they just want to set up a local server. That's how I understand it. Correct me if I'm wrong. fadden@uts.amdahl.com (Andy McFadden) ------------------------------ Newsgroups: rec.games.netrek From: rjones@itchy.dsd.es.com (Ray Jones - Perp) Subject: RSA reserved.c (was Official INL 3.0 Binaries) Date: Tue, 29 Sep 92 23:04:37 GMT Every client has 3 numbers associated with it. A global, a private, and a public key. The global key is a product of two large primes (basically random), X and Y. The private key (call it S) is a prime larger than both X and Y, also basically random. You then choose P (the public key) such that (P * S) mod ((X - 1) * (Y - 1)) == 1 With these criteria, any number N has the following property: N mod G == N ^ (S * P) mod G That's the basis for RSA. This is how it is used for verification: The server send the client a random message. The client responds with: (global_key . public_key . (encode private_key)). The server checks that the global_key and public_key are on its list of accepted clients, and also that (encode (encode private_key) public_key) == Any questions? rjones@dsd.es.com ------------------------------ From: mcp@cs.umd.edu (Mike Polek) Newsgroups: rec.games.netrek Subject: The new RSA netrek is completed and ready for shipping! Date: 30 Oct 92 07:38:56 GMT Hi all, The time has come to upgrade servers to the new binary verification scheme. The following is for server gods and server god wannabe types. Ok, the new RSA netrek system is ready to go. I have uploaded sources to pittslug.sug.org, and they should be moved from the /incoming directory to the /pub/netrek/rsa directory shortly. The following files are necessary for the upgrade: rsa-netrek.tar.Z - If you are starting a new server, this is the full bronco vanilla system with the upgrade. The file is about .5M. res-rsa.tar.Z - If you're upgrading an existing system, this contains the necessary files and instructions for the upgrade. The file is about 33K. test.reserved.tar.Z - This file contains only two files. they are catalog and .reserved. The .reserved file contains most keys for currently built clients. It also includes the test key, which you should delete as soon as you're satisfied that your system is operational. The catalog file can be annotated with whatever discriptions of the keys/clients you deem necessary. Also on the ftp site are compiled clients for sun4, sgi, hp700, decstation, amdahl, and rt-aos systems. The RSA upgrade can be made compatible with the old blessing code by setting CONFIRM=2 in your .sysdef file. The default is CONFIRM=1 (RSA clients only). RSA clients are backward compatible. They will not crash old servers, and old clients will not crash new servers. If an old client connects to a new server and is unblessed or disallowed via CONFIRM, the user is informed that they need a new client. New clients may use the old blessing scheme if they are compiled with the blessed reserved.c by using the -o (for old or obsolete??) flag. Thus you don't need to keep your old blessed client around once you have an "old blessing" new client. The sun4 clients are doubly blessed, and I believe the decstation (bronco) clients and amdahl clients are too, but I'm not sure about the others. Please address problems, bugs, help requests, etc. to me, Mike Polek PS. Please feel free to redistribute the necessary files to other ftp sites and notify people. We don't want to hose pittslug with zillions of requests. Thanks. PPS. There is a test site with the test key installed. Test out your client on darmok.cs.umd.edu, standard port and all. Darmok has CONFIRM=2, so it will accept old or new blessing scheme. Read the motd for other installed keys. ------------------------------ From: fadden@uts.amdahl.com (Andy McFadden) Newsgroups: rec.games.netrek Subject: Re: NEW RSA SERVER!!!!! (Where to get clients) Date: 1 Nov 92 05:46:09 GMT bdhall@morrill.ecn.purdue.edu (Brian D Hall) writes: > What is the procedure for blessing my own RSA client? I like to make >small changes to the standard releases (cursor bitmaps and such). (1) get the client sources (2) make your modifications (3) generate a key (4) try to convince the various server deities to accept it. Probably the best approach is to post the uuencoded "keys.dat" to r.g.n, with a COMPLETE description of all of your modifications. DO NOT let anyone else see "keys.h"! If you've got a borg, it probably isn't worth doing. Servers which allow borgs should just set CONFIRM=0 like they always do. BTW, this came up a while back... uuencode format likes to have something like this: begin fubar 644 MSDF$#%%&FDsdkfjsdf3280sdDSFDF [...] MSDF$#%%&FDsdkfjsdf3280sdDSFDF end The trick is that the line before "end" is **NOT** blank; it's a line with one space in it. If you don't have the space there, you will get "short file" when you try to uudecode it. fadden@uts.amdahl.com (Andy McFadden) ------------------------------ From: mcp@cs.umd.edu (Mike Polek) Newsgroups: rec.games.netrek Subject: RSA SERVER/CLIENT v2.0 Date: 8 Nov 92 21:16:54 GMT My sincerest apologies to all those who have RSA up and running. I had to put in a patch regarding the way RSA packets are handled. I also put in version control. Basically, a v2.? server will accept any v2.? client, etc, etc, but not a v1.0 client. It will give a BAD CLIENT VERSION message. Yeah, I know... that means we have to recompile clients, but the good news is the old keys may be used, so you don't need to update any public key files. Client builders: kindly patch, compile, strip, and upload. I don't anticipate actually going to a v3 ever, and unless I hear of any other bugs, this could be the last release. (yeah!) The new clients/servers also tell you their version during verification, but if it flies by too quickly, you can always do a strings netrek | grep RSA and the version should come up. As usual, no clients/servers should cause each other to crash. The -o option is still operational as well. The updates are available from pittslug.sug.org. Check the /incoming directory first, as the code probably won't migrade to /pub/netrek/rsa until Monday sometime. The rsa_client.sun4 has been upgraded to RSA v2.0 (check /incoming first). cheers, Mike Polek ------------------------------ Newsgroups: rec.games.netrek From: tsang@cs.washington.edu (Donald Tsang) Subject: The RSA Netrek Encryption scheme explained Date: Fri, 4 Dec 92 21:03:40 GMT At Bert's prodding, I'll try to explain, to the best of my knowledge, and in fairly simple terms, how the RSA scheme works, and how it's incorporated into the Netrek RSA 2.0 clients/servers. RSA Encryption: In simple terms, RSA is a PKE (Public Key Encryption) stadard. All this really means that: (a) there is a single encrypt(message, key, shared-information) (b) there are two keys: public and private. The public one is "published" in an easily accessible area, i.e., everyone can know it. The private key should be kept very secret. (c) this is the crux: encrypt(encrypt(message, private, shared), public, shared) gets you the original message back, as does encrypt(encrypt(message, public, shared), private, shared) The actual encryption scheme used is quite easy to understand: B encrypt(A,B,C) just computes (A ) mod C There are many ways to use a public-key cryptosystem. Ours most closely resembles "signature verification". For more information on RSA and Public-Key Cryptosystems, read one or more of the following newsgroups: sci.crypt : general cryptography. the best reference sci.math : if sci.crypt doesn't explain the math, these guys can comp.theory: if you don't think it's secure, these eggheads will at least convince you that a bunch of eggheads haven't been able to break these things REALLY efficiently yet. How Netrek uses RSA The idea is simple: The server has a list of clients and associated public and global keys. It wants to find out that the client has the private key. If it does, it's "obviously" the right client (*) method summary: 1. server sends standard (old) reserved packet to client 2. client sends "RSA 2.0 client" instead of an encrypted reserved packet. 3. server notices the "RSA 2.0" and switches modes to the RSA method 4. server generates a random number X 5. server creates a packet with X, and the server's internet address. 6. server sends packet to client 7. client replaces "server's internet address" part of the packet with what IT thinks it's connecting to. 8. client calls encrypt(modified-packet, private-key, global-key) 9. client sends the encrypted packet back to the server, along with the PUBLIC KEY and the GLOBAL KEY. 10. The server takes the public and global keys, and searches in a table of "allowed" clients for a perfect match. If it doesn't find one, it rejects the client 11. the server decrypts the client's packet, by calling encrypt(private-encrypted-packet, public-key, global-key). If it decrypts to X and the server's address, the server accepts. If X is different, something's just plain wrong. reject. If the server address is different, someone's probably trying to use a "trojan borg" (apologies to USC students, etc). reject. That's it. Very simple. Maybe there's some minor technical details missing or plain wrong, but in general, that's the scheme. The US Patent office needs to learn a bit about computers. First they allow a patent for "the microchip", then one for "the video game"(?), then one for the most obvious PKE system around... sigh... But sofar as we've been able to determine, the embedded RSA scheme is okay to distribute outside the US/Canada (in fact, we want to hide the code / key as much as Public Key Partners wants us to) in non-human- readable form. And PGP works the same, and it is similarly okay (I think) to distribute binaries INSIDE the US/Canada. So development on both sides of the pond(s) seems to be No Problem. ------------------------------ From: trown@ecst.csuchico.edu (Nick Trown) Newsgroups: rec.games.netrek Subject: RSA key changes (server admins / client builders README) Date: 8 Nov 1993 22:04:22 GMT There have been a couple of changes to the metaserver's keylist. First of all, all of the BRM 2.99 and before keys have been deleted from the list. The reasoning behind this is that all the clients that have been compiled with these keys are expiring/expired and they are no longer being used for BRM development. The BRM team is now using new COW client keys for this. This will help make the list smaller and remove any possibly comprimised keys, if they exist. If you're making BRM3 clients and still using the old keys then please mkkey a new one and email it to me and I'll add it to the list. If you're using an older BRM client (pre 3.0) then it is time to upgrade to a more stable version of the client. You can find them at ftp.cd.chalmers.se. The second change has been added to help the server admins be more selective. A while ago there was talk on r.g.n. about client classifications. In essence what we thought might be helpful is to be able to classify clients in a more descriptive manner. For example, being able to classify a client as accepted by the inl would be very useful for INL servers. Tedd Hadley made the necessary changes to the keycomp utilites to allow only clients with the classes the admins ask for to be included. They have also been modified to be able to tell which client classes you do not wish to have. For example the new key description looks like: key.brm3.hp700:ct=BerkRick Moo:cr=trown@ecst.csuchico.edu:\ :cd=October 1993:ar=HP9000/700 series / HPUX 8.0: :cl=inl,standard:\ :cm=reserved.c blessed. Located at ftp.cd.chalmers.se:\ :gk=0356d500765d16813d8857f4574b46b384c4c4606353c4dc4c598ee9fbcb8402:\ :pk=dd1650e6b8528fd154cf29f4822257afe48d887de478f97b05de4ccbc3244402: # Notice on the second line the cl field. This is the class field. In this case this client has been accepted by the inl and also is a standard client accepted by pick-up servers. Any number of different class names can be made. The current ones are standard, inl, info, paradise. All the standard and inl clients have been ok'ed by various server admins and the inlc respectively. The vanilla server source's next release will have the new keycomp utilites included with it as well as the updated program's changes to take advantage of being able to specify classes. Nick ------------------------------ From: trown@ecst.csuchico.edu (Nick Trown) Newsgroups: rec.games.netrek Subject: Re: A question Date: 12 Dec 1993 00:18:55 GMT In article , Jeffrey N. Woodford wrote: >Where exactly is the "RSA distribution"? I need to get a copy of mkkey.c. The RSA distribution is a tar file found at ftp.ecst.csuchico.edu that contains all the RSA files for the clients and servers. Note, you will need to get the crypt key for it if you don't have it yet... Email server@ecst.csuchico.edu for it and state that you're a US or Canadian citizen.. Nick ------------------------------ End of RSA **********