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