Magic Money and Remailers

[remailer@merde.dis.org (remailer bogus account)]

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