-----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-----