diff --git a/magicmoney1994 b/magicmoney1994 new file mode 100644 index 0000000..b95a57d --- /dev/null +++ b/magicmoney1994 @@ -0,0 +1,389 @@ +https://cypherpunks.venona.com/date/1994/02/msg00247.html + +To: [email protected] +Subject: Magic Money Digicash System +From: [email protected] +Date: Fri, 4 Feb 1994 12:44:27 -0800 +Comments: This message is NOT from the person listed in the + Fromline. It is from an automated software remailing service operating + atthat address. Please report problem mail to <[email protected]>. + + + + + + +-----BEGIN PGP SIGNED MESSAGE----- + +Magic Money Digital Cash System +Brought To You By Pr0duct Cypher +Based on PGP Tools - The Crypto Construction Set +Send to csn.org, should appear under /mpj somewhere + +Magic Money is a digital cash system designed for use over electronic mail. +The system is online and untraceable. Online means that each transaction +involves an exchange with a server, to prevent double-spending. Untraceable +means that it is impossible for anyone to trace transactions, or to match +a withdrawal with a deposit, or to match two coins in any way. + +The system consists of two modules, the server and the client. Magic Money +uses the PGP ascii-armored message format for all communication between the +server and client. All traffic is encrypted, and messages from the server +to the client are signed. Untraceability is provided by a Chaum-style blind +signature. Note that the blind signature is patented, as is RSA. Using it +for experimental purposes only shouldn't get you in trouble. + +Digicash is represented by discrete coins, the denominations of which are +chosen by the server operator. Coins are RSA-signed, with a different e/d +pair for each denomination. The server does not store any money. All coins +are stored by the client module. The server accepts old coins and blind- +signs new coins, and checks off the old ones on a spent list. + +Suppose Alice wants to pay Bob some Magic Money. Alice uses her client +module to extract some coins from her account (file). She then mails those +coins to Bob, using a secure channel such as a PGP message. Bob runs his +client module on the coins. The client module checks the signatures, and +totals up the value of the coins. + +It then prompts Bob to choose the values of new coins which total the same +value as the old ones. For example, Alice sends Bob a 64-unit coin. Bob +chooses a 32-unit and two 16-unit coins. The client module then generates +proto-coins, which are blinded but unsigned. It produces an output file +containing Alice's coins, and the new proto-coins. + +Bob mails this to the server. The server counts up Alice's coins, checks +their signatures, and checks for double-spending. It puts the coins on the +cancelled list, signs the proto-coins, and mails them back to Bob. Bob runs +his client module on the reply message. It unblinds the signed coins and +adds them to his coin file. This completes the transfer. + +The Magic Money server is a filter, accepting input from stdin and sending +output to stdout. To set up a server, you first compile the server program +and install it in its own directory. Dump some random junk in a file called +rand.dat. This and the system clock is hashed to generate random numbers. + +Then execute "s i" to initialize the server. It will prompt you for some +information. For the denominations, I would use powers of 2 (1, 2, 4, 8, +16, 32, 64, 128...) because they minimize the number of coins needed to +transfer any amount. The server will create a key and an e/d list. An +ascii-armored copy of the server's public key is written to bank.asc. Users +must have this key to use the server, so however you publicize your server, +include the key. + +Set up the system so that, when a message comes in, the server is executed +and the message (which need not be cleaned up first) is piped into stdin. +The output from the server should be mailed back to the user. The server +can be run through a remailer, if you don't want to reveal your location. +This would be easiest through a penet-style remailer. Operating through a +cypherpunks-style remailer would require an external mechanism to handle +reply headers. However you do it, just see to it that messages go into the +server and the output goes back to the right user. + +If you just want to experiment on one machine, put the server and client in +different directories, to prevent their files from interfering with each +other. Set up a shell script/batch file to feed the client's output into +the server and return the server's reply. + +The server has the ability to include a message to the client. If the file +msg.txt exists in the server's directory, it will be included in the +server's replies, and the clients will display it. The client will wait for +a keypress after displaying the message, so the last line should be "press +any key to continue" or something similar. The message should not be longer +than one screen, because there is no "more" in the client. The main use for +the message is to warn users of expirations (see below), but you can send +anything you want. + +To set up a client, compile the client module (unless the server operator +was nice enough to provide a binary [hint]) and put it in its own +directory. Put some random junk (for random numbers) into rand.dat, and put +the server's ascii-armored key in bank.asc. Now execute "c -i" to +initialize your client. It will create a key and generate "output.asc" +which should be mailed to the server. When the reply comes back, save it +in a file and run "c ". This will initialize your e-list and coin +name files. If the server has a msg.txt, you will see it. + +Now get another user to send you some coins. Coins are binary, not ascii- +armored, because we assume you will use a PGP message or other "envelope" +to transport them. Execute "c " to process your coins. The client +will show the denominations as the signatures are checked. It will show the +total, and allow you to choose denominations for the new coins you want to +generate. Then it will generate a file "output.asc" which should be mailed +to the server. Take the server's reply and run "c " on it. It will +extract and unblind the coins, displaying them as it does so. When it is +done, you will have some coins to spend. + +To pay someone some coins, execute "c -p". The client will show a list of +coins you have, and allow you to choose values to extract. These will be +copied into "coins.dat", which you then mail to the person you want to pay. +He does as above to deposit them. Do not lose "coins.dat" because the coins +are removed from your file as they are extracted. + +Server maintenance and expirations: the server must keep track of all the +coins which have ever been spent, at 16 bytes each. While the server uses +an efficient hash file to maintain speed, the file will eventually grow to +consume the entire filesystem of the host machine. There must be a way to +clear it out eventually. + +The server operator executes "s n" to generate a new e/d list. The old list +will be renamed. Old coins are still valid at this point. The server +operator should put up a message warning users to exchange their old coins. +The next time a user interacts with the server, his elist will be updated +automatically, and the old one renamed. + +The user can (and should be warned to) execute "c -x" to automatically +exchange all his old coins for new ones. After a reasonable time, and +plenty of warning (!) the server operator executes "s d" to delete the old +spent list, efile, and dfile. Old coins are now worthless. The next time +a user interacts with the server, his old elist will be deleted +automatically by his client. Old coins will now show up as having zero +value, and a "c -x" will discard them as "expired coins". If the user was +dumb enough not to exchange his coins, too bad. + +The server will only sign as much value as it receives, so the amount of +money in circulation remains constant. We have a chicken-and-egg problem: +how is value created? The server operator has the magical ability to create +new coins from thin air. He executes "s m " where x is the +denomination of the coins he wants. The result is a coins.dat file, which +can be mailed to a user and processed by his client module. The server just +signs the coins directly, without any blinding. + +Coins are represented by RSA integers in the normal PGP-signature format. +The coin is 16 bytes, padded in the same way that PGP 2.3a pads a +signature. The coin is stored signed, that is, raised to the d power. There +is no hashing involved; RSA is used directly. + +To blind a coin, the client generates a blinding factor, a large random +number. The random number is raised to the appropriate e power, modulo the +server's n. It is then multiplied with the unsigned coin, generating a +blinded "proto-coin", which is sent to the server. The server signs the +blinded coin by raising to the power d. This "decrypts" the blinding factor +at the same time as it signs the coin, because RSA is multiplicative. Then +the client divides out the blinding factor, leaving the signed coin. + +How big should the blinding factor be? I am not sure. Right now, it is set +to the modulus minus one byte. This is certainly secure, but it takes a +long time to unblind because mp_inv is a slow operation. If you know how +long it needs to be, feel free to change it. + +Now, if you're still awake, comes the fun part: how do you introduce real +value into your digicash system? How, for that matter, do you even get +people to play with it? + +What makes gold valuable? It has some useful properties: it is a good +conductor, is resistant to corrosion and chemicals, etc. But those have +only recently become important. Why has gold been valuable for thousands +of years? It's pretty, it's shiny, and most importantly, it is scarce. + +Digicash is pretty and shiny. People have been talking about it for years, +but few have actually used it. You can make your cash more interesting by +giving your server a provocative name. Running it through a remailer could +give it an 'underground' feel, which would attract people. + +Your digicash should be scarce. Don't give it away in large quantities. Get +some people to play with your server, passing coins back and forth. Have +a contest - the first person who (breaks this code, answers this question, +etc.) wins some digital money. Once people start getting interested, your +digital money will be in demand. Make sure demand always exceeds supply. + +If some people get servers up and running, and if there is any interest, +I can write an automatic client which will accept and pay out Magic Money +without human intervention. Please let me know if you have an application +for this, or any other ideas for the system. + + Pr0duct Cypher + +-----BEGIN PGP SIGNATURE----- +Version: 2.3a + +iQCVAgUBLVChQcGoFIWXVYodAQFDhAQAlOdUdnZZxarfxIbACZlHv+Hza+lLkaQl +2eMBro4Bu/QV6wjnTPfw4AND8HbsgdCYjsh7B6XBkpLqVqSk0/fBkwrb4jmvG/bD +sU2ccYm2Da9qShHaYWSqApugVA+0bPc9LSHxpbbrAfXIkMQvYqKQMjde6VW4zecZ +fZAtf6J/7TY= +=N7Kb +-----END PGP SIGNATURE----- + +To: [email protected] +Subject: Re: Magic Money Digicash System +From: Hal <[email protected]> +Date: Fri, 4 Feb 1994 13:58:18 -0800 + + + + + + +Wow! Hot stuff! + +I looked at csn.org, but I didn't find magic money. The pgp_tools +has been there for a while, of course. Somebody post when they find +it. + +Hats off to Pr0duct Cypher! + +Hal + +---- + +To: [email protected] +Subject: Re: Magic Money Digicash System +From: [email protected] (Francis Barrett) +Date: Fri, 04 Feb 1994 17:36:52 +Mailer: WinNET Mail, v2.01 +Reply-To: [email protected] (Francis Barrett) + + + + + + + > Magic Money is a digital cash system designed for use over + > electronic mail. The system is online and untraceable. Online + > means that each transaction involves an exchange with a server, + > to prevent double-spending. Untraceable means that it is + > impossible for anyone to trace transactions, or to match a + > withdrawal with a deposit, or to match two coins in any way. + +This is the neatest thing I have read in a long time. Where can I get +one? + + > The client module then generates proto-coins, which are + > blinded but unsigned. It produces an output file containing + > Alice's coins, and the new proto-coins. + + > Bob mails this to the server. The server counts up Alice's + > coins, checks their signatures, and checks for + > double-spending. It puts the coins on the cancelled list, + > signs the proto-coins, and mails them back to Bob. Bob runs + > his client module on the reply message. It unblinds the + > signed coins and adds them to his coin file. This completes + > the transfer. + +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. + +How does the bank deal with collisions in the 16 byte values of coins? +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. + +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. + +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. + + +--------------------------------------------------------------- +Francis Barrett, F.R.C. | Thou canst not travel on the path | +The Cybernetics Guild | before thou hast become the Path | +[email protected] | itself. | +--------------------------------------------------------------- + + +-- +To: [email protected] +Subject: Re: Magic Money Digicash System +From: Hal <[email protected]> +Date: Fri, 4 Feb 1994 23:38:10 -0800 + + + + + + +From: [email protected] (Francis Barrett) +> > Magic Money is a digital cash system designed for use over +> > electronic mail. +> This is the neatest thing I have read in a long time. Where can I get +> one? + +FTP to csn.org, cd to /mpj, read the file README.MPJ which will tell you +a directory to switch to, do that, cd to pgp-tools (or pgp_tools, or +pgptools, I forget which), and get magicmny.zip. Then unzip and build it. + +> 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. + +None of these things should cause major problems. At worst useless coins +would be generated. Initially, users might send their coins in right away +to confirm that they are OK until they get some confidence in the program. + +> How does the bank deal with collisions in the 16 byte values of coins? + +This will practially never happen if they are chosen randomly. Bad +randomness could produce coins which match ones which have already been +spent (if somehow your RNG got into exactly the same state as someone +else's), so they would be valueless. I think the program makes you +initialize a random file before using it, so just make sure you put +something random there! + +> 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. + +I don't think there are any values you can sign which would give away a +private key. Even signing "1" or "2" should be safe, I think, since the +secret key is the size of the modulus. + +I ftp'd a paper recently mentioned on imp-interest (on "anonymous +credit cards") which claimed that new cash could be generated from sets +of old cash in Chaum's scheme. I don't believe this, and the ref was +to a paper "in preparation" by the authors. I'll try sending them +email to ask about this. + +> 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. + +Here is how this problem would arise. Alice has some cash, which she +sends to Bob to buy something. Bob sends it to the bank to be verified +and turned into fresh cash before he will send the goods to Alice. But +the bank says the cash has been spent before, and Bob reports this to +Alice. Alice insists that she has never spent this cash before. + +Now, this is like a mystery story. Who is telling the truth? Maybe Alice +is lying. Maybe the bank is lying. Maybe they are both telling the truth +and someone broke in and stole Alice's cash while she was sleeping, copying +it from her computer and spending it before she could. + +Ignoring that last possibility for a minute, it is basically Alice's word +against the bank's. In general, in situations like this, we often go by +the reputation of the parties involved. If the bank really is cheating, +there will be lots of other people like Alice, people with good reputations, +who are making similar charges. This will make people stop trusting the +bank. On the other hand, if Alice is cheating, this is probably not the first +time. In time she will get a reputation for being untrustworthy. + +The idea of publishing lists of used coins is interesting but I'm not sure +it helps. Double-spending could easily occur close together in time, between +publication of lists. A cheating bank could claim a coin had been spent +just before the actual coin came in. + +> 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. + +The server should re-transmit the message if it does not arive. We +discussed this a while back and it appears safe for everyone in these +protocols to re-transmit messages freely if the other person claims +never to have gotten them. Even if they are lying, what is the harm - +you are just sending them information they already have. + +Good questions. + +Hal +