encrypted telnet

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-----