Re: Transparent Email

-----BEGIN PGP SIGNED MESSAGE-----


I think it's a bad idea to require signatures on the list, or even to 
penalize people who don't use them.  People aren't signing their posts 
because it's too much of a hassle to do it from a dial up, netcom style, 
account, not because they're insufficiently committed to the cause.

It seems to me that such a rule would stifle discussion and encourage 
people to store their keys on insecure accounts.

The real solution is to try to build tools which will make it so easy to 
use crypto that there's simply no reason not to do it.

And towards that end:

I think Eric's point about separating key distribution from encryption
finally sunk in.  It's encouraging for me, because I think we're very
close to being able to implement good transparent systems, at least if we
put key distribution on the back shelf.  I haven't totally thought it
through, but it seems to me that it's almost a matter of assembling a few
existing tools into a coherent system. 

I've just installed Raph Levien's premail as /usr/lib/sendmail on my 
system, and I'm happy to report that it's running well, despite the fact 
that my machine is a very puny linux box.

This means that I can keep a list of addresses that ought to be encrypted 
in my ~/.premailrc file, and outgoing email to those destinations will be 
automatically encrypted and signed, no matter what mail software I happen 
to be using.

This leaves the problem of passphrases for outgoing signatures and
automatically decrypting incoming mail, but I think that cfs will let me
kludge something together which will get around this.  

(My situation is a little unusual, because I'm running linux on a pc which
is connected to the net via a static slip account.  I don't think this
would work well in other situations.)

If, after I power on my machine, I mount an encrypted directory with cfs,
and then connect my slip, I think I can get away with keeping my key
unprotected with a passphrase as long as the keyring is stored in the
encrypted directory.  What's more, if my mail spool is stored in the
encrypted directory as well, a filter which automatically decrypts
incoming mail and deposits the plaintext in the spool would be feasible. 
A good filter would probably stick something in the text to let you know
that it had come with a good signature. 

It would be sort of ugly, but I think it would work.  I'm sort of new to
cfs, though, and I'm sure how it would deal with multiple users (root, my
main account, my cp account which recieves cypherpunk list traffic, etc.). 

But If it worked, I'd have a machine which:

o	talked to the rest of the email universe without difficulty, and
	which uses standard unix software

o	would automatically use crypto when sending mail to a list
	of email addresses, and which could automatically handle
	incoming crypto

o	would be reasonably secure when it was powered off


==
Alex Strasheim | finger astrashe@nyx.cs.du.edu
alex@omaha.com | for my PGP 2.6.1. public key


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLtrgPREpP7+baaPtAQHTlQP/RYcJi9u5iU0AY4SV1MqNGxAuQDfYwL2G
LcJC5sxYreFGkpwwpA87fRcLi7PreAtS6vFg5tsMXiUXaNS15v1mCDfxr54AwO7C
P3yyHWUTGg1I8CRbDUYlZqksrF3Bqzxy0pDRQGzPEFwP7k8ER72XXeVtIVc8K/zM
CBW+smDOY/w=
=43eM
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

> I think it's a bad idea to require signatures on the list, or even to 
> penalize people who don't use them.  People aren't signing their posts 
> because it's too much of a hassle to do it from a dial up, netcom style, 
> account, not because they're insufficiently committed to the cause.

Is it just me, or does this come up every few months?

> The real solution is to try to build tools which will make it so easy to 
> use crypto that there's simply no reason not to do it.

They are already there - in elm and pine, as well as many others.

> This leaves the problem of passphrases for outgoing signatures and
> automatically decrypting incoming mail, but I think that cfs will let me
> kludge something together which will get around this.  

No need to kludge anything.  Take a good look at the PGP docs - they will
let you do exactly what you want.

> (My situation is a little unusual, because I'm running linux on a pc which
> is connected to the net via a static slip account.  I don't think this
> would work well in other situations.)

I'm running Linux here, and have run it both as static/dynamic SLIP, and hung
(well!) off a T1 line.

> o	talked to the rest of the email universe without difficulty, and
> 	which uses standard unix software
> 
> o	would automatically use crypto when sending mail to a list
> 	of email addresses, and which could automatically handle
> 	incoming crypto
> 
> o	would be reasonably secure when it was powered off

This last one is really the only advantage to running cfs, IMO.

Here's the set of scripts I use here.  Others use more sophisticated ones, but
I'm not into shell programming ;}

pgpview will decrypt to the screen, vie will edit then encrypt, vis will edit
then sign.  They are intended to be used from within elm.

#! /bin/sh
#
# Created by shar, version 0.5 - 04/10/91
#
# This is a shell archive, meaning:
# 1. Remove everything about the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh to create:
#
#        length  name
#        ------  -------------------------------------
#            28  pgpview
#           379  vie
#           199  vis
#

#
# Archive number 1
# This archive created Tue Nov 29 05:04:46 1994
#

echo "shar: extracting pgpview - (28 characters)"
if test -f 'pgpview' ; then
   echo shar: will not over-write existing file pgpview
else
sed 's/^X//' << \SHAR_EOF > 'pgpview'
Xpgp +batchmode -m | less -c
SHAR_EOF
if test 28 -ne "`wc -c < 'pgpview'`" ; then
   echo "shar: ***** error transmitting file pgpview (should have been 28 characters, but was "`wc -c < 'pgpview'`" characters) *****"
fi
fi

touch 0823232194 pgpview
chmod 0755 pgpview

echo "shar: extracting vie - (379 characters)"
if test -f 'vie' ; then
   echo shar: will not over-write existing file vie
else
sed 's/^X//' << \SHAR_EOF > 'vie'
X#
X# vie - like vi, but sign & encrypt with pgp
X#
Xsed -e 's/^> //g' $1 > $1.clr
X# why doesn't pgp $1 $1.clr work?  It should produce $1.clr... <sigh>
Xpgp +force $1.clr $1
Xsed -e 's/^/> /g' $1.clr > $1
X/bin/rm -f $1.clr
Xif [ "$EDITOR" == "" ] ; then
X	pico $1
Xelse
X	$EDITOR $1
Xfi
Xclear
XL=`logname`
Xif [ "$L" = "erc" ] ; then
X	L=ecarp
Xfi
Xpgp -seta +clearsig=on -u $L $1
Xmv $1.asc $1
SHAR_EOF
if test 379 -ne "`wc -c < 'vie'`" ; then
   echo "shar: ***** error transmitting file vie (should have been 379 characters, but was "`wc -c < 'vie'`" characters) *****"
fi
fi

touch 0904203294 vie
chmod 0755 vie

echo "shar: extracting vis - (199 characters)"
if test -f 'vis' ; then
   echo shar: will not over-write existing file vis
else
sed 's/^X//' << \SHAR_EOF > 'vis'
X#
X# vie - like vi, but sign with pgp
X#
Xif [ "$EDITOR" == "" ] ; then
X	pico $1
Xelse
X	$EDITOR $1
Xfi
Xclear
XL=`logname`
Xif [ "$L" = "erc" ] ; then
X	L=ecarp
Xfi
Xpgp -sta +clearsig=on -u $L $1
Xmv $1.asc $1
SHAR_EOF
if test 199 -ne "`wc -c < 'vis'`" ; then
   echo "shar: ***** error transmitting file vis (should have been 199 characters, but was "`wc -c < 'vis'`" characters) *****"
fi
fi

touch 0801202294 vis
chmod 0755 vis
echo End of all shell archives
exit 0
- -- 
Ed Carp, N7EKG    			Ed.Carp@linux.org, ecarp@netcom.com

Finger ecarp@netcom.com for PGP 2.5 public key		an88744@anon.penet.fi
                       ** PGP encrypted email preferred! **

"What's the use of distant travel if only to discover - you're homeless in
your heart."  --Basia, "Yearning"

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLtsLMiS9AwzY9LDxAQHTWgP/VAxadrlIIhH/QwqDUX1KtfnPd6UBh5kL
rouCpajJj4BfFGk486gHOekVZcwTe19NDzUHXE78UDSIWytf1zuAZvf5b9bFgVkV
lXxyaRJK4xIcYHUFTptumpCDRvAQi9ixMwI07K3rs4gzQNd4fgOqMZj7g08wOot9
64BnvLL/J10=
=7WFV
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

> They are already there - in elm and pine, as well as many others.

Yes, I know this.  I have hacked up a couple of primitive scripts I use 
to sign my outgoing mail from elm, for example.

There is, I think, a big advantage to using premail as a
/usr/lib/sendmail, though, namely that it provides a general solution.  In
one fell swoop, I get elm, pine, /bin/mail, etc.  Email sent from trn or
tin is encrypted, (but posts are still unsigned, unfortunately.)

The thing that I'm shooting for is a unix workstation which works and 
acts pretty much exactly like most other workstations, at least as far as 
email goes, except that there's a file (in this case ~/.premailrc) with a 
list of people with whom encrypted and signed email ought to be 
exchanged, transparently.  As far as I'm concerned, as a user, I won't 
even be able to tell the difference between corresponding with people on 
the list and off the list.  It will look pretty much the same to me.

It's not a revolutionary improvement by any means, but I think it is an
evolutionary step forward.  And because it is pretty much a matter of 
kludging together a bunch of available pieces, it might be a good prelude 
to pop clients which would be more useful to the public at large, but a 
lot harder to implement.

> > This leaves the problem of passphrases for outgoing signatures and
> > automatically decrypting incoming mail, but I think that cfs will let me
> > kludge something together which will get around this.  
> 
> No need to kludge anything.  Take a good look at the PGP docs - they will
> let you do exactly what you want.

I know, but I'm a little squeamish about leaving my keys unprotected.  
Also, I'm not very fond of the idea that encrypted email would be 
decrypted when it got here and left in plaintext on the mail spool.
 
> > (My situation is a little unusual, because I'm running linux on a pc which
> > is connected to the net via a static slip account.  I don't think this
> > would work well in other situations.)
> 
> I'm running Linux here, and have run it both as static/dynamic SLIP, and hung
> (well!) off a T1 line.

The main problem comes from using cfs vs. having mail come in all the
time.  A constant flow of mail necessitates having cfs dirs mounted all
the time, which sort of defeats the point of using cfs in the first 
place.  Of course a queue would fix this, and might tidy up some other 
loose ends about multiple email addresses as well.

> > o	would be reasonably secure when it was powered off
> 
> This last one is really the only advantage to running cfs, IMO.

I agree with you about it being the only advantage, but I think it's a big
enough one to justfify bringing cfs into the picture.  Otherwise it
wouldn't be practical to use this setup in an office or school
environment, because anyone could boot your machine with a floppy and
steal your key. 

> Here's the set of scripts I use here.  Others use more sophisticated ones, but
> I'm not into shell programming ;}

Thanks...  yours is a lot more sophisticated than mine, though:

	#!/bin/sh
	/usr/bin/vi $@
	clear
	echo -n "Sign file? (y/N)"
	read ans
	case $ans in
		y)	pgp  -fast < $1 > $1.asc; mv $1.asc $1;;
		Y)	pgp  -fast < $1 > $1.asc; mv $1.asc $1;;
	esac

==
Alex Strasheim | finger astrashe@nyx.cs.du.edu
alex@omaha.com | for my PGP 2.6.1. public key

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLtt6AhEpP7+baaPtAQHjuQP/XEsruK0E5ViyU95MYUboE8JqWMYATCzh
beXnus7458hDDq/7zxVhjZHBmNMXz3y3ixrt43n/7VakOyi1pgPEi/7EuEQpvBgt
6rx5LB19OHZCfeo2H8vsyvuzaGnjP+rFPVcqbp6DVFvg7oD5rF8Zu+OkSkuLaZTA
k0IVyasvg2Y=
=Td4h
-----END PGP SIGNATURE-----

From: Alex Strasheim <alex@omaha.com>

   I know, but I'm a little squeamish about leaving my keys unprotected.

Then make up separate insecure keys for transmission to the host.  Add
an attribution which says to disbelieve any signature made with this
key.

   Also, I'm not very fond of the idea that encrypted email would be 
   decrypted when it got here and left in plaintext on the mail spool.

Some protection is better than no protection.  Protection in transit
is still protection, even if it is not universal.

   Otherwise it
   wouldn't be practical to use this setup in an office or school
   environment, because anyone could boot your machine with a floppy and
   steal your key. 

That's a different threat than interception of mail, remember.  A
partial solution is better than none.

One of PGP's many problems is that it's policies for key use are quite
restricted.  There's no way, for example, to make a receive-only key.

Eric

rom owner-cypherpunks  Tue Nov 29 23:24:34 1994
Return-Path: <owner-cypherpunks>
Received: by toad.com id AA18942; Tue, 29 Nov 94 23:24:34 PST
Received: from netcom13.netcom.com by toad.com id AA18930; Tue, 29 Nov 94 23:24:28 PST
Received: by netcom13.netcom.com (8.6.9/Netcom)
	id XAA12077; Tue, 29 Nov 1994 23:23:12 -0800
From: tcmay@netcom.com (Timothy C. May)
Message-Id: <199411300723.XAA12077@netcom13.netcom.com>
Subject: Re: "You aren't following the _rules_!"
To: jrochkin@cs.oberlin.edu (Jonathan Rochkind)
Date: Tue, 29 Nov 1994 23:23:12 -0800 (PST)
Cc: cypherpunks@toad.com
In-Reply-To: <ab0128ce01021004740d@[132.162.201.201]> from "Jonathan Rochkind" at Nov 29, 94 01:56:30 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1991      
Sender: owner-cypherpunks@toad.com
Precedence: bulk

(My list mail f0or today is now arriving in huge batches, courtesy of
Netcom's mail machine finally becoming unclogged...)

Jonathan Rochkind wrote:

> Which was admitteedlyu your main point; until there is a _need_ for crypto,
> it's not going to be used.
> Because premail makes it incredibly easy to use PGP on a unix box. And, for
> that matter, the Eudora/PGP applescritps make it incredibly easy to use PGP
> on a mac.  And there are some people working on an applescript that will

Not if you read mail on-line, while also reading News. 

> automate using remailers on a mac too.    But ease of use appearantly isn't
> enough; no matter how easy it gets to use, it's still going to have some
> cost to the user over not using it. Even if the cost is only having to wait
> the 1.5 seconds it takes your machine to decrypt/encrypt a message.  Unless
> there's a use for it, people won't be willing to spend that 1.5 seconds per
> message.

I strongly doubt that _anyone_ is not using crypto because of
something so trivial as a .5 or 1.5 or even 4.5 second delay. No, the
issues are that handling encryped messages is, for too many of us,
_much_ more than a 1.5 seconds per message delay. Several of us have
outlined the steps.

Are we just lazy? No, in some cases we're at home, pretty much
relegated to dial-ups like Netcom. In other cases, on VAXes, or
terminals, or AVIIONs. Whatever. Again, described repeatedly.

--Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
Cypherpunks list: majordomo@toad.com with body message of only: 
subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tcmay

From: Alex Strasheim <alex@omaha.com>

re: signature checking at the toad.com server

   It seems to me that such a rule would stifle discussion and encourage 
   people to store their keys on insecure accounts.

Good!  That means they'll have generated a key.

One of the problems with cryptography generally is a prevailing
attitude that crypto isn't worth using unless it provides security as
complete as it can offer.  I reject this attitude.  Partial security
is better than no security.  Protection against some threats is better
than no protection.  Storing a key on a public machine is OK, just
fine, hunky-dory, just so long as it doesn't induce false beliefs
about a lack of protection from sysadmins and other roots.

   The real solution is to try to build tools which will make it so easy to 
   use crypto that there's simply no reason not to do it.

Sure.  No argument.

I will disagree, however, with a conclusion that insists that these
tools have to be the first to be built.  Partial progress is desirable.
Or to put it the words of the old homily:

Don't let the best become the enemy of the good.

Eric

-----BEGIN PGP SIGNED MESSAGE-----

Alex Strasheim <alex@omaha.com> writes:

>I think it's a bad idea to require signatures on the list, or even to 
>penalize people who don't use them.  People aren't signing their posts 
>because it's too much of a hassle to do it from a dial up, netcom style, 
>account, not because they're insufficiently committed to the cause.

>It seems to me that such a rule would stifle discussion and encourage 
>people to store their keys on insecure accounts.

Just create a special key for your netcom account.  Use no pass phrase;
using one would give a misleading sense of security IMO.  Just pass your
mail through "pgp -saft" or equivalent and you've got it.  It is easy to
do this from most editors.

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBLttXrxnMLJtOy9MBAQHPNgIAu42vPelscZqT7yQkY08NtOw6XGdNciXI
WBVXvgRsRdzIoH7GPbHUIPBVXbPNuZ6zDYzbazmSr+Z2tErY9qTHBw==
=wqC5
-----END PGP SIGNATURE-----