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----- 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-----
-----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
participants (4)
-
Alex Strasheim -
eric＠remailer.net -
Hal -
khijol!erc＠cygnus.com