Re: Strategies for getting encryption in widespread use QUICKLY

[Bryan Ford <baford@schirf.cs.utah.edu>]

>Hmm...  Well, having a program that will auto install segments only if
>they are signed by trusted public keys is a good one...  but then again,
>most of the non-techies just want to have a program that works and that
>they're happy with.  Many people would rather just keep a stable,
>working, but older version instead of going to the trouble of trying to
>always have the latest.

That's actually another reason such a system could be valuable.  If
multiple signatures could be attached to a particular version of a program,
different versions of a program could be distributed simultaneously,
each at a different "stability level".  New versions would start with
only the signature of the author, indicating that the author "thinks it
works."  Then as the alpha testers test the version, they sign it if they
consider it stable.  If "enough" signatures are attached to a particular
alpha test version, it becomes a beta version and released to the much
broaded beta test audience, who then similarly sign it only if they
think it's stable, and finally it might become a release version.

A particular user might configure the downloading/installation system
to accept new versions of the software only after a certain number of
signatures are attached to it.  In addition, the user would probably
specify some number of specific signatures that must be present -
the author's, presumably, possibly other well-known beta testers,
the maintainer of the primary FTP site it's being distributed from,
etc.  Essentially, the "specific signatures" check would be for
security, while the "number of signatures" check would be only to
keep track of the stability of the software.

On the author's (distributor's) side, there might have to be some
additional security provisions to ensure, as much as possible, a
"one tester, one signature" rule, so tons of bogus signatures don't
get accepted and added to the main distribution.  But only the
author/distributor should need to worry about this; normal users/
receivers of the software shouldn't need to be concerned.

>I would be wary of an auto-update system because of possible bugs in the
>software.  Even if you only allowed updates from completely trusted
>public keys, even the best of us make mistakes and screw something up...

The same goes for PGP, anonymous mailers, etc.  Any software system
like this can only command trust as more and more people scrutinize it
and test it and decide it's OK for them.

>Perhaps we just need something that would make using encryption easier. 
>Tell me what you all think of this as a project for cypherpunks:
>
>Does anyone want to develop an encrypted term program?  On-the-fly
>encryption over a modem.

This is another good application, but I think it suffers from the same
problem as encrypted E-mail messages: as long as it's even a little
less convenient than no encryption, most people just won't care enough
to use it.  The motivation for my suggestion was not so much to
present a neat new idea (in fact, I'm sure the idea is not new at all),
as to present a _strategy_ for achieving other social and political goals.
The strategy I'm proposing is to find a way to make encryption an
_enabling_technology_, not just a mostly-unnecessary inconvenience in
the eyes of ordinary people.

However, with that in consideration, don't let me discourage you from
doing some kind of encrypted terminal program.  In fact, one common
denominator between it and any automated downloading/installation
system would be the necessity of interfacing with existing encryption
systems, probably more than one.  A useful sub-project, whatever the
bigger project(s) turn out to be, might be an easy-to-use, standardized
"encryption interface library" that could be used in other programs
to interface with other encyrption programs and modules.

				Bryan