Magic Money vulnerabilities?

[nobody@shell.portal.com]

-----BEGIN PGP SIGNED MESSAGE-----

People have mentioned possible attacks against Magic Money.

I don't think it is possible to send the server a value to sign which
would reveal the server's secret key. The server signs your message x by
raising x to the power d. If you know x^d and x, finding d would seem to be
a discrete-logarithm problem, which is just as intractible as factoring.
Can a small or otherwise rigged x help you to find d? If so, participating
in any blind signature protocol is very dangerous, but I don't think that
you can find d this way.

wcs@anchor.ho.att.com wrote: (some deleted) 

(attack 1)

>One security hole in online digicash systems of the Chaum variety is
>that you _do_ need to make sure the money is only transmitted in
>encrypted forms not susceptible to playback attacks.

>If Eve can read the cash either before Bob gets it or before Bob's
>message gets from his fast LAN across the slow part of the net
>to the bank, then she can occasionally spend it before Bob can.

(attack 2)

>If Eve stomps on the Account-number bits, even though she can't
>break the encryption to substitute her account number for Bob's,
>she can substitute a random account number for Bob's.
>This acts as a denial-of-service attack against Bob.

>As a defense, either the message has to contain signatures or at least
>MACs for validation, and be rejected if invalid, or the format
>needs to make it impossible to find the account number field
>or to modify it without trashing the cash as well.

Magic Money is not susceptible to the first (intercept) attack, because
the coins are encrypted with the server's public key. The reply is also
encrypted with a response key sent to the server inside the encrypted
packet. The server signs its responses, so you couldn't send someone some
bogus coins and then fake the server's response to fool the person into
believing that the coins were good.

Magic Money has no account numbers; the server just exchanges old coins 
for new coins immediately. A version of the second attack is a problem. The
message from the user to the server has no authentication. It is just an
encrypted PGP message to the server. There is an RSA packet and an IDEA
packet, and the data is directly inside the IDEA packet. 

If you were to dearmor the message and garble something near the end, then 
re-armor it, the server would bounce the garbled coins with a bad signature. 
Some of the first coins would already have been cancelled, and their value 
would be lost. To prevent this, the next version will MD5 the data packet 
before encrypting it, and include the MD5 value. This will be checked, and 
if it is bad, the message will be thrown out before processing any of the 
coins. This is not a pressing problem. Who would go to all the trouble to
make a remailer detect and corrupt certain messages? The person doing the
corrupting would not have anything to gain.

A while ago I read of a program in alpha-test called Nautilus. This was
specifically designed to compress speech for modem transmission. The author
said that the beta, when it was ready, would be Copylefted. PGP Tools, if
combined with Nautilus, has everything you need to do a secure phone. With
the Clipper push, we need one badly, and now. It should use PGP keys for
authentication, but either DH or a one-shot RSA key for key exchange. That
way they can't record the session and demand your key later, as they could
if you used your regular PGP key for the key exchange.

                                             Pr0duct Cypher


-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLVSdtMGoFIWXVYodAQHC9AQApMjaIF2+h0k6Zb2YSwjkFL1/zAgCXJU+
Dm+kS0us9kusKMc2wr2pc4cEzQow9apM/Od2CisXAaRtHZNUyE8tN3mYWEPxAdcd
6qG03ZekvTqQB+do2HBGRAH3KXGscPIDCyjuh9iIKp9bB7/GWLNoAYm7fPjxpIYz
gnWTuRyBme4=
=wOox
-----END PGP SIGNATURE-----