From: theilman@umsmed.edu (Gary Theilman)
Date: Mon, 14 Aug 95 08:42:11 PDT
To: cypherpunks@toad.com
Subject: Re: My pseudo-anonymous dream list
Message-ID: <9508141541.AA03333@fiona.umsmed.edu>
MIME-Version: 1.0
Content-Type: text/plain


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


>There are, however, a great number of internal improvements that could be 
>made that would both improve user-end usefulness AND improve overall 
>security.

I use Private Idaho, Eudora, and an account on alpha.c2.org.   Let's see how
the wishlist
compares with this setup.

>1)  Multiple Remailers:
>I'd like to see multiple (maybe >12) remailers that utilize the same
>database, upgraded by batched processes once or twice a day or "broadcast"
>realtime to all the reamilers in the web (probably the latter is better). 

Probably could be done by sharing the alpha.c2.org database to other remailers.
I don't see any security problems with this as long as people use encrypted
remailing
blocks.


>2)  Encrypted Databases:
>Any properly designed 'nym' server should have a totally 
>encrypted database.

alpha.c2.org doesn't require this, but a smart user will arrange to have
their reply block encrypted with the key of several different remailers.

>3)  Limited ID lifetime
>Another failing, IMHO, with penet.fi is that ID#'s have an unlimited 
>lifetime.

Is this really a problem?  Makes sense from a housekeeping point of view,
though.

>4)  Chained Mailings
>Because you have many remailers operating, all messages should be randomly
>chained through them. 

You can set up your reply block for chaining, although it isn't random.

>Before a chaining is done, the remailer should ping the target remailer to
>make sure it is up, so that mail isn't sitting in the queue.  

Hmmm.   May be a problem if you are using latent time.

>All chained mail should also be encrypted.

alpha.c2.org can do this

 
>5)  Encryption/Signature Validation
>Any message that is emailed PGP signed should be validated by the remailer
>(with the User having to email in their public key as part of the
>registration process, if they so choose, or remailers can use the
>keyserver). 

Does this present a security problem, perhaps in conflict with suggestions #2?


>6)  Two-way

I can do this now, although sometimes the reply is delayed a few days.


>7)  Option Validation
>In order to change any of the options on your ID (ie, the expiration date
>of your ID, or to expire it immediately, or to set the number of "hops" 
>you want to chain through), you should have to submit a PGP Signed command
>message.  Then, similar to a LISTSERV that confirms subscriptions and
>unsubscriptions, a message is sent back asking you to "ok" these changes. 
>This return message is sent as PGP encrypted email to your public key. 
>When you decode it, you are given a, say, 10digit code string that you need
>to mail back to confirm the changes. If you don't, it doesn't.  

A password is required for alpha.c2.org to make changes.  And any message 
containing command changes must be encrypted with the remailer's key.


>8)  Robust Web of Remailers
>Remailers come and go daily.  Any pseudo-anonymous remailer web needs to
>be able to handle that fact.  Thus, a mechanism needs to be put into place
>to allow for easy adding of a new machine (if it's easy, more people will
>do it) with minimal maintanence.  In addition, if a remailer disappears
>(say, because somebody caught wind of it and ordered the student to turn
>it off :-), the rest of the remailer web needs to be able to survive.  Of
>course, that particular address will be dead, but with apprpriate FAQs
>posted around, people should be able to quickly find another address that
>uses the same database. 

I regularly check the pinging service at remailer-list@kiwi.cs.berkeley.edu
to do this.


>
>9)  Proper PR

Agreed.


GREAT SUGGESTIONS!    I think that alpha.c2.org comes closest to fulfilling
your wish list,
although it has several problems.   The greatest problem is ease of set up.
It took me several
tries before I figured out how to set up and send an encrypted reply block
in such a way
that it could not be traced back to me.  It also suffers from tremendous
overload, much like
anon.penet.fi.  As a result, it can be slow.

I would add a few more suggestions of my own to your wishlist.

11)  Seamless integration with existing mail programs, such as Eudora.

12)  Notification that your message has been received (I'm not sure how to
do this and maintain
anonymity)

13)  Ability to handle very large encrypted files (binaries).

14)  Perhaps increasing security by breaking messages into several parts,
routing them through
different chains, and reassembling them just prior to transmission to recipient.


Keep up the good work!

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

iQCVAwUBMC+JEFQVGHmq7kxdAQEWOQQAvKO3kZp6uMoYdRgEohWFk8PpPdw27iSB
si2hFqZOm72581sEo2OXCmCSM9pn193XSOSqZJ1yYALi1OfQ2UrzuNbpteyE2rP8
koz72XU7OIs+8eLJ4+lp02gCq4/0no/simB9fWO+cAIp5zWB30jaHdp2lca37Z8Y
7vuiMuT3Pxc=
=4X+7
-----END PGP SIGNATURE-----
Gary D. Theilman, Pharm.D.
University of Mississippi School of Pharmacy
Department of Clinical Pharmacy Practice

Finger for PGP Public Key