Hello, I've created this simple little program that allows for encrypted telnet sessions (between unix hosts) without any modification to the system telnetd or telnet programs. The system consists of a pair of programs: 1 running on the target machine (Host B) and 1 running on the machine being telneted from (Host A). (These daemons require no special permissions -- they run as normal user processes. Also, both daemons are really the same program; each is started with a different switch to let it know which hat to wear...) Instead of telneting directly to Host B, the user telnets to a special port on his own machine ("telnet HostA 10000"). This connects him to the encryption daemon. Upon makeing this connection, this Host A encryption deamon opens a TCP connection to the peer encryption daemon on Host B. This Host B deamon then opens a connection to port 23 (the normal telnet port) on it's own machine. Thus, all data from the user is passed to the encryption daemon on its local machine where it is encrypted and sent over the net to the peer daemon on the target machine. There the data is decrypted before being passed to the local telnetd process. Data flowing in the reverse direction undergoes a similar process. All of this is transparent to the user and telnet processes. What I need now is a strong stream cypher to drop into these daemons. Can anyone supply references to apropriate algorithms or code? A good cypher should be resistant to known plaintext attacks, since telnet sessions start out with lots of known plaintext (telnet options, login banner, motd, user id, etc...). If there is interest, I'll look into releasing this when it's complete. Thanks, Bill Kish kish+@cmu.edu
Bill.. There are a couple of problems with your scheme. 1) You have to have this daemon already running on host B. I.e., you still need to have had (at one time) access to run this daemon. Basically, this means that you (or someone) has to have had root access to BOTH hosts A and B to set this up. Unless this becomes supported software, you can't guarantee that.... 2) How do you do key distribution? If you use Kerberos, then you need to have root access on host B. Otherwise, you need some way to securely get the encryption key from A to B.... 3) How do you deal with multiple encryptions? If you have more than one client who wants to use this program, you have to trust a single process (unless you run out of inetd, which requires #1) with all the different keys for all the different users! Basically, you're better off using ktelnet/ktelnetd to do this. In either case you have the same problem with modifying the workstation. Please, don't let this discourage you, but I think you might want to think this through a little more before you jump the gun! Have a Nice Day!!! :-) -derek PGP 2 key available upon request on the key-server: pgp-public-keys@toxicwaste.mit.edu -- Derek Atkins, MIT '93, Electrical Engineering and Computer Science Secretary, MIT Student Information Processing Board (SIPB) MIT Media Laboratory, Speech Research Group warlord@MIT.EDU PP-ASEL N1NWH
Excerpts from mail: 23-Apr-93 Re: encrypted telnet Derek Atkins@Athena.MIT. (1442)
Bill.. There are a couple of problems with your scheme.
1) You have to have this daemon already running on host B. I.e., you still need to have had (at one time) access to run this daemon. Basically, this means that you (or someone) has to have had root access to BOTH hosts A and B to set this up. Unless this becomes supported software, you can't guarantee that....
Well, you really don't need root to run this daemon. You can simply telnet (normally) to machine B, start the daemon in the background, log off, start the daemon in the background on machine A, and go from there. There is only a problem if machine B kills off your process when you log out... To be completely safe, you should change your login password once you are on the encrypted link since the initial telnet to set up the daemon was in the clear... 2) How do you do key distribution? One possible solution is to use PGP to encrypt this telnet key and mail it to your account on B. Your private key on B can then decrypt the telnet key. (If B is a multi-user system, you do have the problems associated with root having access to your private key... But if root is evil, he can get around any sort of encrypted telnet scheme if he really wants...)
3) How do you deal with multiple encryptions? If you have more than one client who wants to use this program, you have to trust a single process (unless you run out of inetd, which requires #1) with all the different keys for all the different users!
Currently, everyone would be responsible for their own encryption process. This really isn't meant to be a complete standard, just an ad-hoc solution until telnet's and telnetd's that support encryption become commonplace.
Basically, you're better off using ktelnet/ktelnetd to do this. In either case you have the same problem with modifying the workstation.
Kerberos requires a large amount of support by a site's system admins. Most sites don't yet support kerberos. (Also, kerberos has some problems of its own...) My solution is one that the average person can use without special system software. Thanks for the comments, Bill
2) How do you do key distribution?
Derek asks this, and suggests using Kerberos. WSK responds by saying that you could encrypt a session key with PGP and send it. WSK replies properly that kerberos is a lot of overhead to get running, but his proposed solution is missing forward secrecy. If the PGP key is ever compromised, then all recorded prior traffic will be available to read. The solution is to use Diffie-Hellman key exchange. I'm not going to explain the details of the algorithm right here, right now, but I'll tell you it's salient properties. Each party makes a random number, applies a one-way function with very special properties, and sends it to the other. Then each party takes their secret number, combines it with the number they were sent, and makes a new (arbitrary) number which will be the same on both sides. This number cannot be derived from the publicly transmitted data. (The very special function is exponentiation in a finite field; those with sufficient math background may consider figuring out the details "a problem left to the reader.") Encrypting session keys with PGP is suggested often enough that this qualifies as a legitimate FAQ. I'll write up a description of this protocol next week if no one has one already written. As a design principle, every live end-to-end session should use D-H to make session keys. Only when you don't have interactivity should session keys be encrypted with a public key. Eric
Please check out IDEA contained within PGP2.2 source code... also look at diffie hellman for session key exchange... cheers kelly -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.2 mQCNAiqua1sAAAEEAMhfx9J4HPDUZReVFsxS1EZh1jArbIKYtFsL8qit1xCDU8xk Sg/MyOVg37CXv/zKGhjrYt1/F4zntHewIDMm3LkH/G/do74zq1R1NrukD5PUbU8/ aeOvsFmjI3HGJGQNpPXXd8eegxHeggOpQPqLNbsl+VSFY5qka/gXinP2G6VzAAUR tB9rZWxseSA8cGxlaWt1IWtlbGx5QG5ldGNvbS5jb20+tBFzbmFrZUBjYWRlbmNl LmNvbbQdS2VsbHkgR29lbiA8a2VsbHlAbmV0Y29tLmNvbT6JAJUCBRAq0+Yk4nXe Dv9n9wsBAUbXA/9nPYjlRcak+JHZzrU8IHwqvSi/eA8IxKfviB0aaOgEkJOgoSrD FzGl0wq9usgqywl1cG05pHhy9dE5YisPrhQUq7Vo3piOxsrhAxdX3OP14wEfqpIU g23lgq55DKKHVf5ea+/F84mdTO7l3Ef4BzfwdKa7YfsFzLOcjWthwnQa84kAlQIF ECq1XovhoOw8SgKpbwEB8bgD/RkyuGei5GZFmXACvF5tBJ2UsCOmmv1c4y4gFQ6U /YO+lO22kVbW497tKJYZyJIMqCj9AnlhqPePiYrj76n951tF3R5AkmTaBIC1SAB6 2oB7xgOSnrt0LxZJml6cLROM6ZpFYIvOVp5GHGlVWu9vxP7BKo+z4LnzFlQzu83O Et4U =PfOI -----END PGP PUBLIC KEY BLOCK-----
participants (4)
-
$HOME/.sig -
Derek Atkins -
Eric Hughes -
William Stephen Kish