1993-04-13 - Re: Modem encryption proposal

Header Data

From: Nickey MacDonald <i6t4@jupiter.sun.csd.unb.ca>
To: pmetzger@lehman.com
Message Hash: a491eeb6835463c5601decc74058c9fee315b2c9b43cc6556137ef9fdd0f0ce3
Message ID: <Pine.3.05.9304130307.C27556-b100000@jupiter>
Reply To: <9304121904.AA01126@snark.shearson.com>
UTC Datetime: 1993-04-13 06:29:09 UTC
Raw Date: Mon, 12 Apr 93 23:29:09 PDT

Raw message

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


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.