1993-01-21 - PGP on BBS

Header Data

From: Eric Hughes <hughes@soda.berkeley.edu>
To: david.brooks@cutting.hou.tx.us
Message Hash: dc28b264419ea879cbfb3ddfc66cea66bff7e078fb5d9bf13ae176ab9e9cc3ea
Message ID: <9301211612.AA01687@soda.berkeley.edu>
Reply To: <10417.143.uupcb@cutting.hou.tx.us>
UTC Datetime: 1993-01-21 16:14:31 UTC
Raw Date: Thu, 21 Jan 93 08:14:31 PST

Raw message

From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Thu, 21 Jan 93 08:14:31 PST
To: david.brooks@cutting.hou.tx.us
Subject: PGP on BBS
In-Reply-To: <10417.143.uupcb@cutting.hou.tx.us>
Message-ID: <9301211612.AA01687@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain



The scenario David Brooks outlines is extremely common: one host
computer providing information services to another computer which acts
as a terminal.  This may be a BBS, Compuserve, Lexis, or any number of
other services.  If there exists an implementable mechanism which does
not require trust of the host, then it should be implemented.

In the case of cryptography, this means that secret information should
not be transmitted to the host.  Hence all operations which use secret
information must be performed on the terminal computer.  These
operations include session key generation and signing of messages.

The solution is cooperative processing systems, where both the host
and the terminal cooperate to perform some task.  Unfortunately, there
is precious little software infrastructure to support such a
development.  Terminal programs on PC's are still for the most part
acting as dumb terminals, with the notable exception of file transfer
protocols such as zmodem.

I believe that cooperative communication software will be necessary
for widespread use of cryptography--not just pleasant, but a
precondition to large scale deployment.

Although this topic is not directly related to cryptology, it is
certainly appropriate for discussion on this list.  It is the
cypherpunk goal for widespread use of crypto by the masses, and the
exact nature of the infrastructure necessary for that task should be
debated, then implemented, then deployed.

Onward.

Eric





Thread