Supose you opened up a socket on the local machine. And that you ran your usual telnet to connect to it. The program listening on the local socket would be responsible for running one end of a 'LINK' like secure protocol. It would connect to either the remote telnet socket, or a special purpose socket at the remote end. There either you can use a pipe to a pty (standard telnet -> login shell -> LINK -> pty), or in a special socket through LINK out the telnet socket. (There is an obvious extention with multiple hops through LINK-socket programs which should provide the same kind of anonymity that is provided by the CP remailers.) In this way, the data passing over the (presumed unsecure) net connection (which might well be slip) is encrypted. I am presuming that both the local and remote kernels are 'secure' enough that you would want to use them. The upside is that you get to use 'comercial grade' telnet==comm programs. Of course this stratagy is no use for folks who don't have sockets on both ends of the channel. It is also likely to be obsoleted as soon as secure-ip gets out. Some ambitious sole might want to try the analogous stratagy where a local pseudo-serial-device is created in software, thus again getting 'comercial grade' comm==telnet programs. I sugest this stratagy, because it is one I am concidereing under MS Windows. I have a telnet which is acceptable, I have slip, and I have the source to LINK, so... (local-telnet) --kernel--> (local-LINK-SOCKET) ----unsecure-network---+ | (remote-telnet) <--kernel-- (remote-LINK-SOCKET) <--+ | (remote-pty) <--kernel-- (remote-LINK) <--kernel-- (remote-telnet) <--+ Infact it would be nice to see some socket (perhaps 32?) become the standard for the secure telnet service. Meanwhile, I did peruse the LINK source and am a little unhappy with the actual protocol used in setting up the secure channel. It is only authenticated in one direction, rather than both (as I understand it). I would like to see two way authentication, and (perhaps) Diffe-Helman key exchange. j'