Strategies for getting encryption in widespread use QUICKLY

I recently sent a version of this message to Stanton McCandlish in
response to EFF's call for support on the Cantwell bill; he said you
people would probably be most interested in the idea.  I was planning
to sit quietly for a few weeks, watch the list, and make sure it's
not just old news here before opening my big mouth.  But seeing the
volume of the list I may not last that long, so I'll post now. :-)

---

It seems like the most effective way to fight Clipper would be to ensure
that by the time the government has a chance to impose any effective controls,
strong public encryption is in wide enough use to make such controls
completely unenforceable.

While encouraging people to always encrypt their E-mail might seem the most
straightforward way to do this, most people just aren't interested enough and
don't see a threat in leaving their mail open, and encryption is still
inconvenient.  An approach introducing encryption into some other aspect
of information transfer, where it is more immediately and obviously useful,
might be more successful in the short term.

One of the most popular uses of the Internet is for distribution of free
software, both in binary and source form.  It would make the lives of many
people much easier if the downloading and installation process could be made
more automatic.  Right now if I want to always have the latest version of GCC
on my Linux box at home, I have to watch the right newsgroup for announcements,
FTP to the right site, download the new version, unzip, untar, and install it
(not to mention compiling it if I get a source code distribution).  This is
not too bad by itself, but it gets inconvenient on a "real" system containing
hundreds of packages to be kept up-to-date, a new version of one coming out
every day or two.

It shouldn't be too difficult to automate this monitoring, downloading, and
installation process, especially for binary distributions that require no
complicated configuration or build sequence.  But suggest this to most anyone,
and they'll immediately get jittery with fear about trojan horses, viruses,
and every other attach known.  This is where encryption technology (specifically,
public-key-based signatures) could come in.  Unlike with E-mail privacy,
where most people don't get a really tangible benefit, in this case encryption
could be a real enabling technology: it would allow people to do what they
couldn't (or wouldn't dare) do before.  If it was done right, in a way that
people can trust, people _would_ use it because it would make their lives
easier, not more complicated.

Before I get into any more detail, I want to hear what you all think
about the general idea, so I'll leave it at that for now.

Thanks!

				Bryan Ford
---
Bryan Ford	baford@cs.utah.edu	University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.

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.  But perhaps we could have a system such that
only authenticated program upgrades could be installed, to combat
against trojan horses, virii, bombs, etc.

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...
 but public-key protection against viruses and trojan horses would be a
good thing.

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 would allow everyone to encrypt very
easily.  It could support plug-in modules (with signatures) to support
automatic pgp signing/verification, additional cipher modules (ie DES,
IDEA, MPJ2).  When logging on to you favorite BBS, instead of typing
your password in, you enter your account, and then set your encryption
on your terminal to your password, and if it's right, then you can
decode the transmission and you are logged on.  That way nobody could
steal your password (or anything else) by tapping your transmission.

Encrypting two way modem transmissions would be a problem, but it could
probably be solved by packaging the data into manageable packets with an
error-correction protocol and then encrypting those.  Error-correction
would be vital, as line noise can wreak havok on encrypted data. 
(Although you could reduce the impact of the errors by weakening the
cipher somewhat.)  I do have several ideas as to how to do this...

What do you think?  Anyone want to take this on as a project?
If I'm going to do it, it would be for MS-DOS systems, tho if there's
enuff interest, it might be possible to develop multi-platform support
concurrently.
Let me know...

"mjg" == Matthew J Ghio <mg5n+@andrew.cmu.edu> writes:

[ auto-install comments deleted...]

mjg> Does anyone want to develop an encrypted term program?  On-the-fly
mjg> encryption over a modem.  This would allow everyone to encrypt very
mjg> easily.  It could support plug-in modules (with signatures) to support
mjg> automatic pgp signing/verification, additional cipher modules (ie DES,
mjg> IDEA, MPJ2).  When logging on to you favorite BBS, instead of typing
mjg> your password in, you enter your account, and then set your encryption
mjg> on your terminal to your password, and if it's right, then you can
mjg> decode the transmission and you are logged on.  That way nobody could
mjg> steal your password (or anything else) by tapping your transmission.

  If the machines to which you want to connect are in a kerberos realm
and you can run TCP/IP (ala PPP or SLIP) on your end, then kerberized
telnet will offer you the ability to

	a) connect to a host without sending your password over the
        connection using a standard kerberos ticket-granting ticket.

	b) encrypt the connection (DES using the session key), so that
	you can, among other things, klog on the remote host without
	the password being sent in the clear.

It should be possible to add other encryption options into ktelnet.

  One might be able to adapt this for BBS use either by modifying
kerberos or by using something like s/key. There's no need for
cleartext passwords to be flying across the wire.

michael

I'm currently developing a Mac BBS.  (I don't know when I'll finish it
but I've been working on it for the last 3 years!)  I can put
patches in to connect to whatever crypto terms will be out there,
however, on the Mac, it's far easier to simply build a CommToolbox
connection tool which ANY Mac BBS or Mac terminal could interface
itself with.

The BBS would have to specifically know about the encryption tool
as it would need to link some key to a user...  But other than
that, the ability is already there.

If we come up with a standard for encoded TCP/IP and serial
communications and adapt existing programs to use them....
The serial communications would be much easier I suspect as most
unix machines can simply have device drivers written for them that
map an existing port to/from an encryption pipe and on to a
virtual device.   Ie: for every /dev/tty* you could have /dev/etty*

It'll be harder for DOS, but not impossible.  If anyone has the
sources to a fossil driver, there are plenty of BBS software that
use the fossils... Perhaps there would be some term programs that
do this too?

On Amiga????

(BTW: I've put off the Mac BBS for a while as I just stumbled on
something far more important: a crypto-stacker for the Mac!!!  I
hope to get something up in beta in the next few months.  I won't
do the actual encryption routines, but will provide plenty of hooks
for adding your own. I'm going to have it actually compress/decompress
and have some hooks...)

rarachel@prism.poly.edu (Arsen Ray Arachelian):

>On Amiga????

Should be reasonably easy to implement depending on at what point.
A drop in replacement for serial.device (most all term programs and 
BBS's would most likely support this) wouldn't be healthy as at
the handshaking would have to be done unencrypted until a session-key
was established.  Perhaps if the serial.device were written to use
the normal serial.device and except a certain escape sequence that
could be sent to the serial.device as normal output that would
be intercepted as a key of some sort.  

Other options include a shared library that an application would have
to look for and use.  (This would of course involve a rewrite of
all the term soft, etc.)  

In any case, a sorta standard using pgp to exchange session keys
seems like a good idea.  Something worth noting though, the internet
is a packet network and most bbs via modem just stream things don't they?
I suppose you might have to use a stream cipher or just have the 
BBS/Term soft wait until you have an IDEA blocks worth, or a certain
time limit then crypt and send.

>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

> probably be solved by packaging the data into manageable packets with an
> error-correction protocol and then encrypting those.  Error-correction
> would be vital, as line noise can wreak havok on encrypted data. 
> (Although you could reduce the impact of the errors by weakening the
> cipher somewhat.)  I do have several ideas as to how to do this...

Look at the code for Layers and Multisession(??) they both have sources
for the unix end.  If you base your code on that it should be fairly
stable as we know the above products work.  (Beware of Layers though,
on the Unix end, it supposedly leaves opened ports after you log out
which could be used to hack in, or look like they were used to hack in.
I got my account pulled one day for running it, because some hackers were
breaking in and leaving open ports as part of their footprints....)

 
> What do you think?  Anyone want to take this on as a project?
> If I'm going to do it, it would be for MS-DOS systems, tho if there's
> enuff interest, it might be possible to develop multi-platform support
> concurrently.
> Let me know...

If you're going to do this, try to write some VERY generic code. Don't
assume the size of a char, int, long, etc.  Instead, use stuff like:

#define CHAR char
#define INT int

etc.  That way, if an int happens to be 32 bits on some weirdo machine,
it can be redefined on that machine by simply modifying the headers...
(better yet, use typedef, not #define.)

Another thing, don't use any dos i/o functions to actually send the
packets across, instead, do everything you can without calling on DOS
or whatever C language library/compiler calls directly.  Call the DOS
functions to read/write to the serial port from one single place so
that they can be easily modified.

You really don't have to do too much for the packets and stuff...
Basicallly each packet is composed of a header, data, and some
sort of check.  There are CRC codes out there already.  Pull the
32 bit version out of some Zmodem program and use that...

Your header should contain some packet id#, the size of the packet
(no need to send 1024 bytes if the user just pressed one key :-),
the CRC for the packet, and the packet itself...  A good thing might
also be to include a couple of special bytes at the begining and end
of the packet so that the receiver can try to resynch itself if it
gets hit by line noise...  Say, 0x55,0x55,0xAA,0xAA, packetid#,
packetsize, packetcrc, packet, 0x00,0x00,0xff,0xff for example.
(while this is longer, the other side can look for 2 zeroes, followed
by two 255's, followed by possibly some time before it sends a
request to resend the packet.

Or if you want to make things simpler, do as Xmodem (yuck!) send
a small tiny header, the packet, and wait for an ACK from the other
side before proceeding to send the next packet.  That ACK would be
after/before a packet that the other side sends of course... :-)

Better yet, maybe you can just hack some source code for SLIP or
UUCP or something...

I'm new to the list, but after reading the article in Wired I felt I
needed to hear all this, Nazi flames aside.

I run linux myself and I'd like to see your idea take root.

The Kind