Update on user-level hack to do telnet encryption posted recently

Perry doesn't like Graham's hack for telnet style encryption.  Graham
doesn't like Perry's attitude.  Such a _small_ teapot.

For the forseeable future, there will be the need for link encryption
where one is connecting to a site where the far end doesn't have
encrypted telnet available, _for_whatever_reason_at_all.  There are
lots of reasons, e.g. site managers are busy and the user did not plan
in advance.  It doesn't really matter.  If you can't alter the remote
end except by a user process, that's what you use.

Perry is absolutely correct that this hack is very bad as a long-term
solution, but it is labelled a hack, after all.  Nevertheless, there
is need for a short term solution.  Graham seems to have provided one
part of that.  Great.  Just because you shouldn't need to be using it
in two years is no reason to say it shouldn't be written.

Eric

Eric Hughes says:
> For the forseeable future, there will be the need for link encryption
> where one is connecting to a site where the far end doesn't have
> encrypted telnet available, _for_whatever_reason_at_all.  There are
> lots of reasons, e.g. site managers are busy and the user did not plan
> in advance.  It doesn't really matter.  If you can't alter the remote
> end except by a user process, that's what you use.

I strongly disagree. If you truly insist, run your own telnetd on the
remote machine. Don't run a hack. However, the right solution is to
get the site manager to replace their telnet, a process that takes
minutes and which, given the current epidemic of line tapping, is of
obvious necessity even to the brain damaged. As I've noted, however,
its trivial to run your own telnetd on another port if you absolutely
insist.

Perry

>From: "Perry E. Metzger" <pmetzger@lehman.com>
>Sender: owner-cypherpunks@toad.com
>... As I've noted, however,
>its trivial to run your own telnetd on another port if you absolutely
>insist.
>
>Perry

How do you do that?