Magic Money simplification

[Hal <hfinney@shell.portal.com>]

In my posting about remailer abuse, I mentioned a point in passing re
Magic Money that perhaps deserves a more explicit mention.

Presently, Magic Money has each user create a special public key just
for use by that program.  When MM sends a message to the bank, it includes
a copy of the user's public key.  Then, when the bank sends the return
message, it encrypts it with that key.  (Messages to the bank are also
encrypted with the bank's public key.)

Last night it occured to me that this encryption may not be necessary.
Messages to the bank are of the form f(x)*r^e, where f is a one-way
function, x is the coin's serial number, r is a random blinding factor,
and e is the bank's public exponent for this denomination.  The bank
signs this by taking it to the d power, were d is the RSA-inverse of e,
and sends back f(x)^d * r.

It looks to me like these two messages are secure even without being
encrypted with the user's or bank's public key.  r, and r^e, both act
as one-time-pads, blinding the underlying f(x) or f(x)^d value perfectly.
This blinding, of course, is what prevents the bank from linking up
withdrawn cash from spent cash.  But it should serve just as well to
prevent an eavesdropper from stealing the cash.

If someone manages to get f(x)^d * r, this is of no value to them if they
don't know r.  Since only the original sender knows r, this message can
be sent in the clear.  Similar logic applies to the message from the user
to the bank.

If this argument holds up, the usage of Magic Money can be simplified
considerably.  The user should no longer have to create a special public
key.  Nor should he need to know the bank's public key.  All he needs to
get started is the email address of the bank, to which he can send the
standard initialization query message which causes the bank to send back
information about the exponents and denominations used, as well as the name
of the money.

Of course, when users send actual un-blinded coins amongst themselves as
payment, those transmissions need to be encrypted or done via some secure
channel.  But MM never concerned itself with those.  It was only involved
with messages to and from the bank, and for these it seems to me that
encryption is not necessary.

Hal