-----BEGIN PGP SIGNED MESSAGE-----
Let's talk less and do more. :)
How about adding encryption to kermit and iScreen so that they may
talk to each other in a secure manner? I am proposing these two
programs because they are widely portable. kermit works on most
Unix and MSDOS systems. iScreen works on most Unix systems.
(Note that this would solve the network/modem eavesdropping problem,
but not the untrusted remote system problem. The latter has no
solution in my opinion. You just have to trust the sysadmin.)
I propose writing a link encryption library which could be usable
in other comm and BBS programs.
Any takers?
BTW, watch for an encrypted Unix talk program coming to a ftp site
near you.
- --
Miron Cuperman
Miron Cuperman says:
Let's talk less and do more. :)
How about adding encryption to kermit and iScreen so that they may talk to each other in a secure manner? I am proposing these two programs because they are widely portable. kermit works on most Unix and MSDOS systems. iScreen works on most Unix systems.
(Note that this would solve the network/modem eavesdropping problem, but not the untrusted remote system problem. The latter has no solution in my opinion. You just have to trust the sysadmin.)
I propose writing a link encryption library which could be usable in other comm and BBS programs.
A good idea, but getting the protocol right is hard -- you don't want to put any real overhead on the line, but you also want to do error detection and resychronization so that your cypher will run properly. Discussing a proposal for a line protocol that has these features would, of course, be germane to the list. Perry
Perry: I may have missed something, but I don't see where synchronization is a concern. The whole of idea of Kermit is to provide a "binary" path between two computers. It is Kermit's responsibility to ensure the data is received in the same order as sent (sychronization is part of the Kermit protocol, no?). If we have a data stream coming from a keyboard or whatever, which we run through an invertable encryption algorithm, and then pipe it into Kermit which makes sure it gets to the other side, Kermit need not know where the data is coming from. The other side of course has to know the protocol and the key... I believe that Kermit allows variable sized packets per file transferred, but does it allow the packet size to vary during the transfer? I'd have to go find my Kermit protocol reference on that one. You would want this, as well as a relaxed timing on the protocol, if its to come from the keyboard, as a user does not (and/or cannot) normally type as a consistant rate... --- Nick MacDonald | NMD on IRC i6t4@jupiter.sun.csd.unb.ca | PGP 2.1 Public key available via finger On Mon, 12 Apr 1993, Perry E. Metzger wrote:
A good idea, but getting the protocol right is hard -- you don't want to put any real overhead on the line, but you also want to do error detection and resychronization so that your cypher will run properly. Discussing a proposal for a line protocol that has these features would, of course, be germane to the list.
Nickey MacDonald says:
I may have missed something, but I don't see where synchronization is a concern. The whole of idea of Kermit is to provide a "binary" path between two computers. It is Kermit's responsibility to ensure the data is received in the same order as sent (sychronization is part of the Kermit protocol, no?).
I don't belive people were talking about Kermit the Protocol. They were talking about Kermit the PD terminal emulation software, which contains Kermit the Protocol. Obviously the protocol can handle error correction -- but that does nothing for you if you want to log in to a machine and do arbitrary things. Perry
participants (4)
-
miron＠extropia.wimsey.com -
Nickey MacDonald -
Perry E. Metzger -
Perry E. Metzger