-----BEGIN PGP SIGNED MESSAGE----- Tim May wrote:

Subject: Simplified Digital Postage--Proposal

... A more sophisticated system based on true digital cash, perhaps based on Magic Money," is more desirable, but almost anything is better than the current system. (Well, not _anything_.)

I propose remailers immediately adopt some form of digital money/postage, even if current instantiations are not fully debugged or optimized. "Magic Money" may be ready for such a trial use.

Magic Money will have to be modified for that use. As it works now, clients A and B are using a common server S's coins. Client A wants to pay client B some money. Client A sends client B the coins. Client B sends the coins along with new, blinded but unsigned coins, to server S. Server S checks the old coins, signs the new ones, and sends them back to client B. This leaves two options: A) The remailer is the server. In this case, you don't need Magic Money, just a straightforward blind signature system, and I could write that if someone could describe in detail what they want it to do. The remailer operator could write it too, using PGP Tools and Magic Money source code as a basis. B) There is a third party server, and all remailers use its coins. In this case, the remailers have to mail the coins to the server and get the server to verify the coins before remailing the message. A good way to set up a time lag, but pretty complicated for an all-automatic system (the client would have to be modified, too) and lost mail from the server would wreck the system. First someone has to set up a Magic Money server, which so far nobody has.

- subtle flaws in digital money protocols (and I doubt "Magic Money" is completely free of subtle or not-so-subtle flaws...everything needs debugging and evolutionary learning) will not be so serious when only "postage" is involved. As opposed to "real money" situations, where finding a way to break or spoof the protocol could result in large amounts of money being lost. At least with digital postage, about the worst that could happen is someone gets free remailing--the current situation.

Magic Money isn't too bad in security. It uses Chaum online cash: a random number x, MD5(x) put in a properly padded signature packet and blindsigned by the server, and different e/d pairs for different denominations. Messages to the server are encrypted with the server's PGP key, and the server's replies are encrypted with the client's PGP key (provided in the original message) and signed with the server's key.

How ready is Magic Money for a test-bed use like this?

Right now it's designed to allow people to pass coins between each other, but the code could be hacked to accept coins automatically. I have mixed emotions about pay-per access (to remailers or anything else) but I am interested enough in seeing digital cash experimentation to write the code now and worry about the ideology later.

- and of course, a charge of, say, $2.00 in real money (send in $20, get bact 10 remailer "stamps" of some form, suitably anonymized through a blinding procedure a la Chaum) would mean that posting to 20 newsgroups would be a nontrivial expense for a would-be flooder.

Everyone would use the free remailers rather than pay $2. Both Chaum and RSA would jump on you if real money was involved. What about just having a finite number of stamps going around, to prevent mailbombing? Here's an anonymity-breaking attack I've been worrying about: In an untraceable digicash system, deposits cannot be matched to withdrawals, so the bank cannot find out where a customer spends money. However, the bank in collaboration with a payer can determine who deposits a particular coin. Suppose you are providing a non-approved service or product, using remailers and digital cash to protect your identity. Someone wants to trace you. All they have to do is set up a sting: buy your service with coins which are recorded, and get the bank to identify who cashes in those coins. To prevent this, the bank cannot know who deposits particular coins. The bank cannot know who any of its accountholders are. Being an accountless system, Magic Money can be operated through a remailer. But Magic Money is an online system. Offline systems depend on the bank knowing who the customers are, and being able to punish them for double spending. How could an offline system be made immune to this attack? I don't know about remailers, but I wish someone would set up a Magic Money server. I haven't heard much about Magic Money on the list lately. That could be good (the code works) or bad (nobody cares). Which is it? BTW the latest versions are PGPTL10C and MGMNY10E. Pr0duct Cypher -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLWGqBMGoFIWXVYodAQEFjAP/SvhcAGk4ZGuvDaFN9oNiTtZi0Yhf1Q63 ARqSJgHGtrwsMxoxKnT5cuErjoV3+ba0b7Id49apq6zdS6W7UVo6Gpm5WIxfIOui V6VeFlYE5Wry4YKrMahjYCd4th80hWLWpgcGcjCw0WqmESfR0i8jLVpiKzwB0cKO VldNKHU4/GY= =7EVp -----END PGP SIGNATURE-----