From: catalyst-remailer@netcom.com
Date: Sat, 5 Feb 94 03:15:25 PST
To: cypherpunks@toad.com
Subject: RE: Magic Money questions
Message-ID: <199402051111.DAA11286@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


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

Magic Money is available from csn.org in the same directory as pgptools.
Be sure to add in the fast mp_inv posted here. It speeds up the unblinding
of a 1024-bit coin from 2 minutes to 3 seconds. Thanks to whoever posted
that code. I will include it in the next release, as soon as some people
shake down the current one for bugs.

fb@cyberg.win.net wrote:

>A few questions.  Since the client which generates the proto-coins is
>under the control of the consumer, the bank has no way of making sure
>that he is not running his own code, or that the RNG he is using is
>cryptographically strong, or even that he is not distributing modified
>client programs to other users.

If his RNG is bad, he is only hurting himself. If he gets the same coin
as another person, and that coin has already been spent, his coins will
bounce, costing him money. Same is true if he corrupts his packets - 
the server looks for the ASN string, and if it's not there, bounces the
transaction. He can run his own code if he wants to.

>How does the bank deal with collisions in the 16 byte values of coins?

There shouldn't be any, except for deliberate double-spending. The coins
are 128-bits, so you'd need 2^64 of them before the odds favor a collision.
The odds of a coin collision are equal to the odds of two messages having
the same PGP signature.

>What if the user picks the numeric values for the server to sign in a
>way which leaks information about the banks private key?  RSA is much
>more secure when signing random-esque data, like a message digest,
>than it is when signing numbers provided to it by some outside party.

This is a problem, if this attack is feasible. The coins won't spend if
they don't have the proper ASN string in them, but the server has no way
to see what it is signing. Can someone produce values which will reveal the
private key?

I've heard of attacks which involve getting signatures on factors of a
message, and multiplying them to get a forged signature. These won't work
here, because each coin value is signed with a different d. All you could do
is multiply several invalid coins of value x to get one valid coin of the
same value. But a signature leaking the private key - that is a new one for
me. Please tell me about this attack. How would one prevent it without using
a cut-and-choose protocol?

Applied Cryptography suggests (page 106) that it is okay to dispense with the
cut-and-choose portion of a blind signature in cases (such as this one) where
the user is motivated not to provide a corrupted coin. The coins use different
e's from the bank's PGP key, so a coin could not be used to forge a message
from the bank.

>Similarly, how can the consumer trust the bank's representation that
>money has already been spent?  Surely the bank should be required to
>publish a list of cancelled coins and timestamps with a running MD5
>hash periodically for inspection by the unwashed masses.

There is no punishment for double-spending. The transaction is simply thrown
out. The bank, in fact, has no way to identify the customer. What could the
bank hope to accomplish by claiming that a coin was already spent? It can
print more coins at any time, so it has no reason to cheat. A server will
have to protect its reputation by not printing too much money or otherwise
making its users angry. If you want to put in an MD5, it wouldn't be hard.

>What do you do about lost messages from the server to the client.
>Once coins have been recorded as spent, they cannot be redeemed again.
>Yet the mail message containing the new coins may have been lost in
>transit.

What can be done? The server can hold onto outgoing messages for a while,
and can have a means of remailing those which are lost. Or the message can
be mailed back to the user through two different routes, to increase the
reliability of the system. But one cash-like property of digital money is
that, if you lose the data, you're SOL.

I don't claim the system is perfect. But it's a start, and in my opinion,
that is what digicash needs right now: a start.

These Clipper postings have me worried. It seems as though the government is
in a big hurry to get Clipper on the market. They only have one shot at this.
What needs coded now? A menu-driven PGP? Any ideas for new projects?

                                                   Pr0duct Cypher

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

iQCVAgUBLVNAjcGoFIWXVYodAQHtgwP+OTFcxAbZL8uvVeBbwwn4/N1jnLGeHFRB
lw7U3Y3ciESs0PBRDu1JO4hOqzpW7Ch+GkY1z+ueWD8m4+EoroacJMcTI28EKGm3
+2eV0KpQsKfcfsPCfMFVKhqBRAzcwJhFdziFbPvG9g4CU9/Huz4ff8KiSud8zdWO
n8odZHk5zTs=
=6Yw2
-----END PGP SIGNATURE-----