December 2003 - cypherpunks-legacy

Magic Money Digicash System
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----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 <file>". 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 <file>" 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 <file>" 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 <x> <x> <x>" 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-----

1 0

Re: remailer delays
by nobody＠shell.portal.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Brian Beker asked, "The last two messages I've sent through remailers have taken upwards of two days to arrive at their destinations. Parallel messages sent directly arrived immediately. The two remailers are Hal's and rebma. What is making this happen? Is it related to all the recent PGP FAQ traffic? Which remailers if any are not suffering from these lags?" I am not using remba at all, not even pinging it. The last three days have seen the "Bomb me!" request dwindle to about 5-6 a day. Hal's ("shell") is working without a glitch. That leaves remba. If I can get my list of remailer details completed, people like you with specific needs (today you want speed) will be happier. The fast remailers that I am using and have had NO problem with are: @remailers = ( "catalyst(a)netcom.com", "remailer(a)dis.org", "ebrandt(a)jarthur.claremont.edu", "remailer(a)merde.dis.org", "elee7h5(a)rosebud.ee.uh.edu", "hfinney(a)shell.portal.com", "hh(a)soda.berkeley.edu", "qwerty(a)netcom.com" ); These are not necessarily the most secure ones, but they are all pingable with variable 5 minute to 1 hour delays for the pings to come back. If speed is of concern, these are your remailers. cicada and pmantis are also quite fast but are not meant for what I need them for. I am very sensitive to kicking mailers off my list if I cause a problem, even once. The merde and dis.org remailers often add an hour delay, seeming to batch things out. jarthur is often ~10 minutes, but just as often an hour. - From my incomplete List: Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB -------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ---------- bsu-cs + ? ?/? + ? ? ? ? ? 23a ? catalyst + N? SM/MQ - - ? - PA M 23a - choas + ? ?/? + ? ? ? ? ? - - cicada ++ ? ?/? - - - - ? ? - - dis.org -/-- ? ?/? - ? ? ? ? ? 23a ? extropia +/? ? ?/? + ? ? ? Pr? ? 23a ? jarthur +/-- St SM/MQ? - ? ? ? Un ? 23a - menudo -- ? ?/? - t1 ? ? ? ? - ? merde -/-- ? ?/? - ? ? ? ? ? - ? penet.fi -- St ?/? - t? 24 + Pr H - - pmantis ++ ? ?/? - ? - - ? ? - - qwerty + C SM/MQ - - - - PA M 23a + rosebud ++/- ? ?/? - - - ? ? ? 23a ? remba ? ? ?/? ? ? ? ? ? ? 23a ? shell ++/+/- St ?/? - ? ? ? ? ? 23a - soda ++/- St+? ?/? - ? ? ? ? ? - Subj: Strips Subject header? NL: Non-linear remailing? 123->231. RD: Random delay added (max, in hours)? Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages. CPU: Pr = private. PA = account on public access machine. Un = university. Phys: Physical security of the CPU, especially at night. H/M/L. BitB: BitBucket feature? Fast?: ++ <5 min + 5-10 min. - ~10-30 min delay -- pinging isn't practical due to long delays +/- sometimes +, sometimes - Normal internet mail delays are common, and are not equivalent in the two directions between any two remailers. Mail still gets through. OpLog: F: full copies of all mail is archived. My large volume mailing should help put a stop to this. St: Stats logs of when mail was remailed. St+: Stats logs of when and where mail was remailed. St-: simple counter. N: operator keeps no logs. SysLog: SM: sendmail logs of when and where mail was exchanged. Root access. MQ: mailqueue accessible by anyone on the site. Could make logs. -Nik (Xenon) -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLVJ3RwSzG6zrQn1RAQEfFQP/Rkt6bVBWCetn4YH/dm7LJ+EhAia+NXDy EutlgmKJKXPc2eh3pypVb0cxdlMr/dOidXrTY3LzCF4iHOc7/l1FNegkbrJltf9R +rOHyh23FDnQZE8NIxq9KLr++iUxMFsq8UfmNy+Z5ojMh2Nc+54CBSHoAMMEryPG oEOu5i3jK08= =nfRB -----END PGP SIGNATURE-----

2 1

Re: Magic Money Digicash System
by Hal 17 Dec '03

17 Dec '03

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

1 0

Re: Prodigy snooping
by Mike Ingle 17 Dec '03

17 Dec '03

>I heard from a friend that Prodigy was scanning user's hard drives. >Basically, when you logged on Prodigy made a complete directory of your >hard drive and uploaded it. Prodigy was using this to find out what >applications you used so they could direct the appropriate advertising >towards you. Apparently, they're suffering several lawsuits now because >of it. This tale has been around for a while. Prodigy makes a huge file, over 1 MB, on your hard drive and stores information there to speed up the data transfer. People started finding bits of their files in there. They claimed that Prodigy was snooping into their systems. Prodigy denied it and claimed that their software just didn't bother to clear the disk space when it allocated it, so whatever was there, stayed there until the space was used. They distributed a utility which would zero out that information. Whether they were really snooping or not, who knows? If they were, they were pretty stupid to leave clear text in the file. >My friend heard this on the trailing end of a radio talk show. If it was >really happening, it sounds horrible. Could Secure Drive be set up to >stop this kind of attack? Secure Drive would stop it if you weren't logged into the encrypted drive when you ran Prodigy. Of course, if you were logged in and they knew about Secure Drive, they could get your encryption key as well as your data... --- Mike

1 0

request for information
by dave_taffs＠rainbow.mentorg.com 17 Dec '03

17 Dec '03

I saw the following on imp-interest, and thought somebody here might be interested in responding (perhaps?)... PS: She has David Chaum's internet address by now, I'm certain... to: imp-interest(a)thumper.bellcore.com from: owner-imp-interest(a)thumper.bellcore.com date: Fri, 4 Feb 1994 10:29:56 -0500 (EST) subj: Digicash story/Internet Letter sender: jayne levin <helen(a)access.digex.net> sent: 02/04/1994 8:33 am (PDT) --------- **| I would like to explore the issue of digital cash in my next issue of The Internet Letter. I am trying to contact David Chaum but don't have his e-mail address, so I'd appreciate any help in making contact with him. I'd also like to get a grip on some of the issues involved in developing digital cash as well as the status of work in this area. Who else should I talk to? Jayne Jayne Levin Net Week Inc. Editor 220 National Press Building The Internet Letter Washington, D.C. 20045 USA +1 202 638 6020 Fax: +1 202 638 6019

1 0

interagency_workgroup.notice (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: Running regularly
by mbriceno＠netcom.com 17 Dec '03

17 Dec '03

Xenon askend: >> Before I start throwing out ideas that I'm sure aren't new to readers here, >> I have a simple question that perhaps I should post to comp.unix.questions >> or comp.lang.perl, but.... Can I, and how would I, get a perl script to >> kick in and send out mail every few minutes when I am NOT logged in. Is this >> possible on Netcom? Hal answered: >Most public Unix systems will not let you do this, in my experience. >The two Unix commands which usually give you the ability to run programs >at regular intervals are "at" and "crontab". You can read the man pages >and try running these to see if they are enabled for you. Netcom has a "policy against detached processes because of the load they put on the system and therfore 'crontab' and 'at' disabled for all users.(Netcom support)" To make your life even harder they kill all your processes upon hangup. Here is (half) the workaround: They forgot to disable "sleep" and they also didn't disable "nohup." You can simply write a script that sleeps for 30 min, executes your program and goes back to sleep. Call it with "nohup script &" and you're in business. The next problem that must be addressed is the auto-logout upon >14min of inactivity on the modem level that Netcom imposes on you. There is a simple 2 line command that you can add to your .login file to disable the auto-logout. I saw it once posted in one of the Netcom newsgroups, but I lost it. Perhaps you might post the question there. I would not advise to ask Netcom support for it... Some of the messages responding to the above post talked about "supending the account for intentionally disabling, blah, blah" 8-) Good luck, -- Marc Briceno <mbriceno(a)netcom.com> PGP public key by finger

1 0

reno_key_escrow.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

gore_crypto.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0

harris.statement (fwd)
by Mike Godwin 17 Dec '03

17 Dec '03

Forwarded message:

1 0