From: Karl Barrus <elee9sf@Menudo.UH.EDU>
Date: Thu, 4 Mar 93 20:17:41 PST
To: cypherpunks@toad.com
Subject: CASH/REMAIL: combination
Message-ID: <199303050416.AA01513@Menudo.UH.EDU>
MIME-Version: 1.0
Content-Type: text/plain


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

Cypherpunks,

Some people have made excellent suggestions regarding digital cash and
anonymous remailers.  I'm going to try to obtain another account from
a friend in order to implement a remailer which accepts digital cash.
(However, this will probably wait until I am able to upgrade the bank
to PERL)

Maybe future for "profit" anonymous services will work similarly, thus
helping to cut down on remailer abuse since abusers must be willing to
"pay" for the service.  I don't think I can work in usenet posting as
well (technical reasons not philosophical ones!) but the whole thing
should be an interesting experiment anyway.

The remailer will work like the others, except valid cash must be
included or the remailer will not forward the message.  For ease, a
number of bills will be generated upon request, which will then be
deposited as used.  As a side effect, bank accounts will be
incremented as well (too bad real banks don't work like this) so
customers may "withdraw" more bills to use for remailing messages.

Since the bank won't mail back confirmation of deposits (messages may
be coming from other remailers, etc.) and it would be nice to have a
way for you to see if your cash was accepted and your message
forwarded, I think I'll have the bank accounts copied into the .plan
file so you can finger the account, check your account number and
balance, and determine whether or not the remail was successful.  Of
course, the full account number will not be displayed - perhaps the
MD5 hash of an account number or whatever will be put in the file,
along with the account balance.  I'll also provide a command to obtain
the .plan file via email, for those without finger.

Actually, for the purposes of this experiment, it might be best to not
use the new site in a chain.  At least until the single hop mode works
well!

Nathan Estey suggested to me that traffic analysis could be made more
difficult if messages under a certain length were padded, and message
over the length were split and remailed a piece at a time.  This will
help, although I think it would be easier for the sender to include
padding in the message itself (thus identical messages plus random
padding will encrypt differently).  Plus, the message may be multiply
encrypted and thus padding cannot be added "inside."  Maybe future
mail software will automatically pad in addition to encrypt :-)

I may implement a delay feature, which would help foil traffic
analysis.

Comments?

/-----------------------------------\
| Karl L. Barrus                    |
| elee9sf@menudo.uh.edu             | <- preferred address
| barrus@tree.egr.uh.edu (NeXTMail) |
\-----------------------------------/
-----BEGIN PGP SIGNATURE-----
Version: 2.1

iQCVAgUBK5bTsoOA7OpLWtYzAQEYMQP/WGUGNFiA9ftV7N8JRe01zLooa5b1hTaG
Fh5eYiQflf9S1ttv0DCvZXo+6/yUVWLmPZHqG04xsnZXc6Z1SFw9C0zd3oP/kM9h
2IMrbrqF8ICNA8hSoDV97U2Rf+r0qpUVtSzgoOsuxw+4EVEkgjflNA9v8YJcL+Sv
ZQR/6po1lU8=
=QdR1
-----END PGP SIGNATURE-----