From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
Date: Mon, 12 Apr 93 23:29:09 PDT
To: pmetzger@lehman.com
Subject: Re: Modem encryption proposal
In-Reply-To: <9304121904.AA01126@snark.shearson.com>
Message-ID: <Pine.3.05.9304130307.C27556-b100000@jupiter>
MIME-Version: 1.0
Content-Type: text/plain


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.