-----BEGIN PGP SIGNED MESSAGE----- Karl Barrus posted some ideas for running a remailer which requires payments in the form of digital cash. I have some comments.

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.

If I follow this, Karl will allow users to request digital-cash bills from the bank, then require them to send one of those along with each remailed message. The bank then puts the bills back into the user's account(!) leaving him with as much "money" as he started with. This may be OK for an exercise to get the code working, but to really have any effect the remailer should not give the money back to the user as soon as he "spends" it. This makes the whole thing rather pointless. I had an idea which would be a variant of this: make the users send you a postal-mail letter to authorize issuing another batch of digital "stamps". The letter could include an email address to send the stamps to. Maybe you could send 5 stamps per letter. This would force the user to pay 29 cents each time he wanted a set of stamps. Unfortunately, he's not paying the remailer operator, but rather the U.S. government. But it would still limit the ability of people to swamp the net with large numbers of messages. (With this system, I would not anticipate that people would have "accounts", but rather that Karl would just send out the digital stamps and let people hold it, and use them as they mailed letters.)

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

Remailers might require standard-sized messages for their operation, or refuse to pass messages larger than some limit. This, in conjunction with requiring per-message postage, should eliminate the possibilities of "volume abuse" which so worried Ted Ts'o. ("Content abuse" is much less of an issue given the free-speech traditions on the net.) As it turns out, PGP compresses, then encrypts messages (usually): C = Encrypt (KEY, Compress(M)). The decryption phase is then: M = Decompress (Decrypt (KEY, C)); Now, as it turns out, the decompression is self-terminating. That means that you can add some junk to the message after the compression phase but before the encryption phase, and it will be automatically ignored by the decompresser: C = Encrypt (KEY, Pad (Compress(M), N)) M = Decompress (Decrypt (KEY, C)); (This represents padding the message with N bytes after compression, then encrypting it.) I had a patch for an earlier version of PGP which would always pad to 1K byte boundaries using random bytes. It was kind of annoying to use because it made small messages quite a bit bigger. But I think what would be very nice would be a utility to encrypt a message which produced one or more constant-sized files as output. Then you would want a corresponding program to decrypt which would put the files together and strip the padding. This way, all files sent to the remailer would be exactly the same size, and it could then act as a "Mix", as Eric described, holding a bunch of files in a batch, shuffling them, then sending them out. Hal 74076.1041@compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK5gIPagTA69YIUw3AQFJrAQAqmgsGvipCPl3i1A78/FGensfPRK5qgfR HszULK+eggNKMJkRLc3Ed4IuSBHXOZHKJeYV7TT1li2pmwYU8a4WMMY6Eyj5tKlL Q/s7NRtI5ZqSvHI3K/5tiTA6N0CR8syOjaHLeoHHqtwVbUbEC3jZV+yTzEgZ35Dm yyrxwPghpPE= =5BwY -----END PGP SIGNATURE-----