- cypherpunks-legacy - lists.cpunks.org

Re: IMP (was Re: ecash-info (fwd))
by Hal 17 Dec '03

17 Dec '03

> From: rah(a)shipwright.com (Robert Hettinga) > >> http://digicash.support.nl > This, like CommerceNet(tm), seems to be pretty much under construction. > The store windows look nice, however... I agree with this, which is why I don't understand why you said: > 1.) Chaum's e-cash coupled with WWW/Mosaic is a de facto internet > mercantile protocol. You're jumping the gun here a little, aren't you? There is no evidence yet that Chaum's current proposals are going to catch on. The CommerceNet idea seemed to have more backing judging from the press releases. And it did not appear to support anonymous transactions. > 2.) It seems to me that that e-cash, contrary to the status quo's thinking, > is *critical* to internet commerce. An anonymous cash market is most > unrestricted and efficient market there is, because privacy/security (more > than trust, I think) is the capstone of any serious transaction mechanism. I don't follow this argument. You are suggesting that an anonymous cash market would be more efficient than one based on checks and credit cards? It would have lower transaction costs, so things would be available for lower prices? Why is this? The hypothetical discussions we've had here on "if I ran an anonymous bank" often talked about service charges. Your use of the term "capstone" is unclear in this context. Are you suggesting that retaining privacy is more important for most people than trusting a seller in most transactions? Most people would rather buy from FlyByNight Corp if they could stay anonymous than from Sears using their credit card? I don't think so. For some people, the kind who won't use checks today and get by with cash and money orders, this might be true. But I don't see it as being the rule. > The imp-interest people seemed to be afraid of e-cash because the > Chaum-patent hairball reminded them too much of the RSA/PGP fight, and > probably because they didn't want to be associated with any wild-eyed > crypto-anarchists(tm). (As a dyed-in-the-wool yellow-dog congenital > up-by-your-bootstraps crypto-fascist <gasp> republican, I haven't the > slightest idea what they're talking about. . .) It seemed to me that the IMP list discussions degenerated into flame wars between Detweiler and cypherpunks. Those in the middle, which included most subscribers, were shocked and disgusted by Detweiler's crude flaming and this made everyone uncomfortable about bringing up the topic of anon- ymity and cash. With Detweiler on the list it was impossible to have a serious discussion of the matter. > 3.) Since a big pile of the discussion on this group lately has been about > our collective concerns about an RSA-approved version of PGP, I think there > is a real parallel here in e-cash. Not that some enterprising cypherpunk > should immediately code up "e-cash for the masses"; that would be way cool > but probably not within the second-mortgages of the people here. However, > some effort should be made to get Chaum et. al. to see to logic of > distributing *both* the "cash-register" and the "wallet" of this e-cash > system to anyone who wants it. It seems that, like Mr. Bill (Gates), his > real market is the people who make e-cash ("banks", "currency exchanges", > "mints"), not the people who use it. Chaum is trying to make money off his ideas. In doing so, he is being guided by the invisible hand of the market to try to find those niches where his technologies can be most profitable. Maybe going after the bankers is the wrong idea, but it is understandably tempting to prefer trying to get millions of dollars from a few people than a few dollars from millions of people. It does sound, though, like he is trying to branch out now and spread his technology around. Perhaps he will follow the lead of RSA and make a "ChaumREF" free implementation of his cash technology. The Commerce- Net model had RSA supplying free client software while charging the vendors licensing fees, I believe. Chaum may be planning a similar approach. It would be nice to see more details about what Chaum has in mind. My WWW access is very weak. Could someone summarize what is available at the page listed above? Hal

5 8

encrypted IP
by Jim Hart 17 Dec '03

17 Dec '03

Does anybody have an update on the crypto IP efforts? I've heard there are several commercial products, including weakened U.S. DES versions from Semaphore Technologies, Motorola, Hughes, and UUNET technologies. Also, some higher quality foreign versions. How many of these products interoperate across vendors? Are there any public domain versions available or in the works? Any emerging standards, so that if I wrote my own system it could interoperate with other crypto IP based clients and servers? thanks, Jim Hart hart(a)chaos.bsu.edu

2 1

Magic Money 1.1/AutoClient
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Magic Money V1.1 with AutoClient and MultiServer Capability Uploaded to csn.org, should be available soon. Read README.MPJ in /mpj This is the automatic client I described a couple of weeks ago. This is a new version of Magic Money. It is compatible with V1.0 in both directions. The major improvements are: * Automatic Client allows software-automated services to accept and pay out Magic Money. * Coin files contain the keyid of the server that created the coins. This allows the Automatic Client to accept money from multiple servers. * New fifo.c fixes a memory-freeing bug in fifo_destroy. This fix was previously posted on csn.org as pgptlupd.zip The keyid is appended to the end of the coin file with a new packet type number preceding it. These coin files will be accepted by the V1.0 client. V1.0 coin files will also be accepted by the V1.1 clients. See the README10.DOC file for more general instructions about how to use Magic Money. This file concentrates on the changes. The Automatic Client performs the same functions as the manual client, except that it has no user interface. It is designed to be controlled by software (PERL scripts or C programs). The program is controlled by command-line arguments and information piped into stdin. All output is written to files or sent to stdout. Compiling AC.C with MM.C and the appropriate PGPTools files produces the Automatic Client. If you are using a PC, it is worthwhile to get the 8086.ASM file from PGP2.3a and use it. Define MSDOS, SMALL_MEM, DYN_ALLOC, and UPTON for the MS/DOS version with 8086.ASM. These defines work for both the normal and automatic clients. Automatic Client Commands The automatic client accepts one option, and zero, one, or two filenames. If run with no options or filenames, it will print a help screen. ac -[option] [inputfile] [outputfile] - -k display bank's keyid and client's keyid This prints the keyid of the bank on the first line, and the keyid of the client on the second line, as 8-byte hex strings. - -k [inputfile] display keyid of bank which made this coins.dat file, or the keyid needed to decrypt an ascii-armored pgp message. If the file is a coins.dat-type file produced by a client, this will produce the keyid of the bank that created it. If it is a PGP message, such as a reply from a server, it will produce the keyid the message is encrypted with. In either case, it returns an 8-byte hex string. If the file is from a 1.0 client, there is no keyid so you will get a NO_DATA error. There is a 1/256 chance that the byte at offset 9 from the end of file will match the identifier byte. In this case, you may get a no-good server id. If you get a server id but do not recognize it, assume this has happened. - -d list coin denominations Prints the available denominations of coins from the elist file, one denomination per line. These are all the possible denominations, and their presence here does not mean you have any coins of that denomination. - -i [outputfile] initialize client (key length, key name from stdin) This initializes the client, producing the initialization message (which must be sent to the server) in the specified file. The bank.asc file must be present before running this. It creates a key to communicate with the server. The key length in bits, and the name for the key, are read from stdin. They should be on separate lines. - -l list all coins in allcoins.dat Lists all available coins as a stream of numbers, one coin per line. - -l [inputfile] print total value of a coins.dat (client output) file. Checks signatures and rejects if signature bad Prints one number, the total value of the coins.dat file specified. If any signatures are bad, or coins have unknown exponents, the program terminates with a BADSIG or BADEXP error. - -p [inputfile,outputfile] process a coins.dat file for exchange with the server. Reads from stdin a list of coin denominations to create, terminated by 0. Writes to stdout a 128-bit transaction identifier. Before running this, you must have used the -l above and decided what denominations to create. Then run this to process the coins and prepare a message for the server. Feed the denominations you want into stdin, one number per line, terminated by a zero. There is no checking here. If you specify less value than you are turning in, you will lose value. If you specify more, the server will throw out the transaction and you will lose all the coins you are depositing. This function writes out one value to stdout: a 128-bit hex identifier. This is an xor of the coinids of all of the new protocoins created. This allows your script to identify this transaction when it comes back from the server. - -r [outputfile] Reinitialize (generate init packet) This generates a new client initialization packet. If your system is inactive for a while, do this, send it in, and run -s on it. This will check for a coin expiration and update your elist if necessary. - -s [inputfile] Process a response from the server. Outputs the 128-bit transaction identifier, followed by total value, followed by any message from the server. This takes a reply from the server (ascii-armored) and processes it, adding new coins to your allcoins.dat file and removing the corresponding protocoins. The output is: on the first line, the same 128-bit identifier generated by -p when this transaction was prepared. On the second line, the total value added to your coin file (same as the value of the coins you created in the -p). Following that, any message from the server, if there is one. If -s is run on a response to a -i or -r initialization, it will return 00..00 for the identifier and 0 for the value, because no coins were processed. - -w [outputfile] Withdraws coins for payment. Accepts a list of coin values from stdin, terminated by a zero. Extracts coins from your allcoins.dat file and writes them to the output file. Send to stdin a list of values to create, followed by a zero to terminate. The output file can then be processed by another client. - -x Returns the total value of any old coins (in danger of expiration) Checks for old coins that are in danger of expiring. Outputs the total value of all old coins, or zero if there aren't any. - -x [outputfile] Exchanges old coins. Accepts a list of denominations and generates an identifier like -p This is like -p for old coins. Run -x above first, decide what denomin- ations you want to create, and run this. Feed in the denominations, term- inated by a zero, and send the output file to the server to exchange your old coins for new ones. If you have expired coins (you didn't exchange them in time) this will throw them out. Error codes (from MM.H) These are returned by exit(code) when the program ends. A 0 is good, anything else is bad. The only errors that are not included here are out-of-memory and missing rand.dat file. These will still print English messages, however, if the system is correctly set up, they should not happen. #define MMAC_OK 0 /* Normal exit */ #define MMACERROR_BADCOMMAND 1 /* Bad command */ #define MMACERROR_NOFILE 2 /* File not found or inaccessible */ #define MMACERROR_NODATA 3 /* Data such as a key not found */ #define MMACERROR_BADSIG 4 /* Coin/file has bad signature */ #define MMACERROR_BADEXP 5 /* Coin has unknown exponent */ #define MMACERROR_NOCOIN 6 /* Tried to use nonexistent coin */ #define MMACERROR_NOPROTO 7 /* No protocoin in file */ Using the Automatic Client Ok, that's great, but how do I use it? For an automatic service, you want to receive coins, process them, get the response back from the server, and then perform some service. You may optionally want to send some coins back to the person. So first, when a message comes in, you have to decrypt it or dearmor it or uudecode it, or whatever is necessary to get a binary coins.dat file. Then run -l [file] to check its value. If you get a value and not an error, figure out what denominations you want. -d will list all possible denominations. Now run -p [file] [output file] and send it your list of denominations. Record the transaction id output from the client, along with whatever information you need to keep about the service the customer wants. Mail the output file off to the server, and go on to the next problem. When the message comes back from the server (-k [file] and compare with -k to verify it is encrypted for your client) run -s [file] on it to deposit the coins in your allcoins.dat file. The output from the client gives you the transaction id, value, and any message. Use the transaction id to look up the information you recorded earlier, and deliver the service to the customer. The value can be verified if you want, and the message should probably be saved in a file for later reading. You can check each new message against the last one and only save it if it has changed. Occasionally run a -x to see if you have any old coins. If so, figure out what denominations you want to trade them for, and run -x [file] to exchange them. You can probably do this part by hand, since coin expirations are pretty rare. To pay out money, do a -l to find the denominations to extract, then do a -w to withdraw them into a coins.dat file. Handling Multiple Servers You can run a service that accepts coins from multiple servers. To do this, you have to keep a separate client directory for each server. When a coin file comes in, run -k [file] to determine which server it is for. Using the server id as the directory name would make life much simpler. Then CD into that directory and process the coins from there. If you get coins from a 1.0 client (which has no server id), you will have to go into each directory in turn and try a -l [file] on the coins. You will get an error return on each one until you find the right directory. If messages are coming back from multiple servers, using -k [file] on the incoming message will tell you which client's key it is encrypted with. Running -k will tell you the key of that client (on the second line). - From this, you can determine which client should process that server's reply. This is probably easier than using the from line in the email. Ideas for Automated Magic Money Applications Currency Exchange - Accept one currency and return another, skimming off a profit. Find the correct exchange rates where the same amount of each currency is coming in and going out. Pay-For-Use System - Accept Magic Money to pay for remote access to a machine, use of a MUD, remailer, news posting service, etc. Gambling - Accept bets on sports, the stock market, horses, etc. This is the MGMNY11A release. That means it might have bugs. If you find any, please post them on Cypherpunks(a)toad.com or alt.security.pgp. These are also good places to announce your service, or to contact me. Pr0duct Cypher "One line of code is worth a thousand rants." -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLerF1MGoFIWXVYodAQFtVAQAn7HOBDX4bg6MZv6uAgr3KhDfpTsAF1Te i8C9WjWGgPlqv6wJz+uACBo9dKnT5oP3u7foz3rB7GRp8UHHGBs2u8TjvTeedrQ4 wUit6Bb3LcmwRPjQ8MfLK3cam8EeNsy9Hn9hqw9fm7xs4jwgaqsZU8dslthSEdh4 lab6JYE0vWM= =7QpT -----END PGP SIGNATURE-----

1 0

Seattle Times cpunks article, 5/27/94
by Matt Thomlinson 17 Dec '03

17 Dec '03

Paul finally polished this one up and put 'er in print. It talks about the NSA document, cypherpunks, and clipper. Pretty good, I thought. (c) 1994 Seattle Times, I'm sure.. ;) Is government chipping away at freedom, privacy on new information highway? --------------------------------------------------------------------------- -Another in a periodic series looking at the impact of technology on contemporary society- By Paul Andrews, Seattle Times staff reporter Long dormant, '60s-style civil disobedience may soon make its reappearance -- not at college campuses or draft inductions but on the information superhighway. The issue this time around: electronic privacy. An underground computer group, known as cypherpunks, is among a variety of groups fighting the Clinton administration's attempt to monitor electronic communications, saying it smacks of Big Brother and thought control. And they're intent on using the electronic equivalents of protest marches, sit-ins and card burnings to make their point. The dress rehearsal came last month when cypherpunks distributed the employee manual of the National Security Agency over the Internet in an attempt to embarrass the administration. The incident was generally viewed as a teenage prank. Although an intriguing glimpse into the psychology of one of the government's most secret bureaus, the manual is not a "Top Secret" document. The agency contacted and questioned at least one cypherpunk, but took no formal action. "There was no information in the document that would be considered damaging to national security," said Judi Emmel, public-relations officer for the NSA. But observers say the episode presaged the inevitable: digital enactments of civil disobedience not seen since publication of the Pentagon Papers in 1971. In that case, a one-time Pentagon consultant named Daniel Ellsberg leaked documents to The New York Times and Washington Post, detailing decades of official deceit, ineptitude and ignorance over Vietnam foreign policy. The Justice Department attempted--unsuccessfully--to bar newspapers from printing the papers, arguing that publication threatened U.S. soldiers and wartime strategy. Ellsberg, whose action contributed to President Nixon's eventual disgrace and resignation, was charged with 12 counts of espionage, conspiracy and theft. The case ended in a mistrial. Inevitably, Net observers say, an Ellsberg-style cyber protester will post classified documents on the Internet--not as a prank, but to embarrass, disrupt or otherwise bait the government. Digital protests could take other forms as well -- everything from mail "bombs" -- long files meant to slow a system's functions or operations -- to viruses or "hacking" (entering and damaging files in) federal computers. If such actions happen, the government's response may move legal principals behind the First Amendment and Bill of Rights to a new and untested electronic arena. "It's absolutely going to occur," said Winn Schwartau, author of the recently published "Information Warfare." As government documents leak and people get hold of them, whether for personal or political reasons they're going to be on the Net." Like Ellsberg, cypherpunks say their aim is to expose government mendacity and incompetence as a defense of the public's right to know in a democracy. Their target: the Clipper chip, a device placed in computers that would enable security agencies to eavesdrop on, store and search all electronic communications. Last month's episode began when a 25-year-old Austin, Texas, computer engineer, Chris Goggans, posted an electronic version of the NSA manual in Phrack, an on-line magazine he publishes. It was then copied and redistributed to Electronic Frontier Foundation (an activist organization) and cypherpunk news groups on the Internet. Goggans, who uses the on-line alias "Erik Bloodaxe," reported that he received the manual in a white envelope with a Silicon Valley-area postmark and no return address. It's impossible to determine how many of the Internet's estimated 15 million to 20 million users saw the posting. Among the Net's community of users concerned about electronic privacy, it received wide distribution. Traditionally the NSA, whose specialty is decoding encrypted information, has been steeped in secrecy. During the Cold War era, its existence was routinely denied, but it has become more open since President Clinton office. The NSA manual urges employees to be vague about their job without drawing "attention to themselves nor to their association with this agency." Intelligence employees with specific job classifications are directed to "generalize" their titles to "research analyst." The manual states that it is "FOR OFFICIAL USE ONLY," encompassing "information or material which, although unclassified, ... should not be given general circulation." If the manual is disclosed, "appropriate administrative action will be taken to determine responsibility and to apply corrective and/or disciplinary measures," it states. Emmel indicated that the agency, although "not particularly pleased" with the cypherpunk posting, did not consider it illegal. "A Freedom of Information request could do the same thing," she said. Cypherpunks say the symbolism is more meaningful than the action itself. The manual was posted "to embarrass the NSA at a point where they are pushing the Clipper chip," wrote Grady Ward, an Evergreen State College graduate living in northern California, in response to an electronic inquiry. "If the NSA can't keep its own security manual from the hands of the public, what guarantees they can keep the Clipper keys" from falling into the wrong hands, he said. Ward was contacted afterward by an NSA security officer, whom he gave instructions on how to subscribe to Phrack. A Seattle cypherpunk, Matt Thomlinson, who goes by "Phantom," said he would have published the NSA manual even if it had been classified. A Univeristy of Washington senior from Auburn who had never heard of the Pentagon Papers episode, Thomlinson said he would publish classified documents to make a point only if doing so would neither harm national security, nor put someone in physical jeopardy. "It really depends on the situation," he said. The Clipper chip is designed to encrypt data transmissions over telephone lines so they cannot be read without a decoding key. Under the administration's plan, one half of the key would be held in escrow by the Treasury Department and the other by the National Institute of Standards and Technology within the Commerce Department. Government security agencies would have to get permission from the escrow agencies to use the key to decode suspect communications. Cypherpunks, a largely anonymous group of programmers whose name combines the terms cyberpunk and cipher(using the British spelling), support encryption, but say only senders and recipients should hold the keys. They argue that the Clipper keys would fall into the hands of terrorists, criminals or spies. "The idea that nobody will do this is ludicrous," said Scott Northrop, a Seattle cypherpunk who uses the pseudonym "Skyhawk." "The incentives are enormous." The Clipper chip would be replicated, they say, or obtained by a double agent such as Aldrich Ames, who has been in the news latedly for selling classified material to the Russian government. "They (cypherpunks) didn't have to go to the trouble of printing the NSA manual to make their point," said Jim Warren, a Silicon Valley computer-industry pioneer who founded an annual conference on Computers, Freedom and Privacy. "Aldrich Ames is evidence enough." Warren thinks foreign corporations after trade secrets would eagerly pursue Clipper technology -- "and they have a considerably more suspicious profile than foreign governments." The administration counters that without the Clipper "trap door" capability for monitoring communications, encryption will be used to conceal covert or illegal activities from enforcement authorities. Administration officials have suggested that without Clipper capability, encryption may have to be banned altogether. An attempted ban would be a folly, said Schwartau: "From a political, social, technological and pragmatic standpoint, it ain't gonna happen." A popular slogan on the Internet sums up opposition to a ban: "If encryption is outlawed, only outlaws will have encryption." Unswayed, the administration is moving to put Clipper encryption in government interagency communications. So far it has indicated that compliance by private industry and citizens should be voluntary. If classified documents were posted on the Internet, it's unclear what government response would be. Emmel said such a step would be met with "appropriate action," but she declined to elaborate. ----- Matt Thomlinson University of Washington, Seattle, Washington. phone: (206) 548-9804 Check my home page -- ftp://ftp.u.washington.edu/public/phantom/home.html Get PGP 2.2 or 2.5 key via email or finger phantom(a)hardy.u.washington.edu

1 0

sorry, serios error in previoos text
by jp＠jep.pld.ttu.ee 17 Dec '03

17 Dec '03

It is rather hard to factorize even small primes :-) it should of cource read like fact. large numbers. JP from TTU.

1 0

Re: New MacPGP2.3a has arrived.
by Nikolaos Daniel Willmore 17 Dec '03

17 Dec '03

:: Request-Remailing-To: cypherpunks(a)toad.com Nice four posts of noise toady PM. Drop everthing? How 'bout stick it on your ftp site and shut up about it? Dork.

1 0

No Subject
by Anonymous 17 Dec '03

17 Dec '03

> From owner-cypherpunks(a)toad.com Tue May 31 09:34:37 1994 > Date: Tue, 31 May 1994 09:31:57 -0400 > From: Nikolaos Daniel Willmore <ndw1(a)columbia.edu> > To: cypherpunks(a)toad.com > Subject: Re: New MacPGP2.3a has arrived. > Sender: owner-cypherpunks(a)toad.com > > :: > Request-Remailing-To: cypherpunks(a)toad.com > > Nice four posts of noise toady PM. Drop everthing? How 'bout stick it > on your ftp site and shut up about it? Dork. > Heh heh. Suggestion: Read the "How To" document for the remailers before trying something like this next time, Nikolaos Daniel Willmore.

1 0

Re: <no subject>
by gtoal＠an-teallach.com 17 Dec '03

17 Dec '03

: From: Anonymous <remailer-admin(a)chaos.bsu.edu> : > Nice four posts of noise toady PM. Drop everthing? How 'bout stick it : > on your ftp site and shut up about it? Dork. : > : Heh heh. : Suggestion: Read the "How To" document for the remailers before : trying something like this next time, Nikolaos Daniel Willmore. Xenon always was careless about that sort of stuff :-) I dunno why he bothers with anonymous remailers though, all those rants recently about people sitting on the source of MacPGP were *obviously* from Xenon - he doesn't even attempt to disguise his writing style... G PS I suggested it half in fun a couple of weeks back, but I'm now nearly certain that uni == tmp ... I'm also starting to suffer this really weird paranoid delusion that uni and tmp are both t.c.may - it would explain why tc never has time to post much, he's too busy being detweiler ;-) PPS While in paranoid mode, I thought I'd mention that I've noticed some of Detweiler's mannerisms emanating from email in New Delhi of all places. Weird. I think I must be cracking up.

1 0

Re: New MacPGP2.3a has arrived.
by Nikolaos Daniel Willmore 17 Dec '03

17 Dec '03

I wrote, >:: >Request-Remailing-To: cypherpunks(a)toad.com All right, we're both dorks. I'll ask politely. Will you please put the new MacPGP onto the Cypherpunks ftp site? It's on ftp.netcom.com in /pub/mpj/... only so far. I was contacted by whoever is releasing this thing about his/her woes in getting it out there. But as I have a new ITAR-clean ftp site/project, I'd like to not carry crypto code there. I've attracted a bunch of programmers with promises of a worry-free environment, and was trying to keep some distance from this thing. I gotta get back off this list, as all I'm seeing is the same old cynicism, inaction, and endless threads about money. That said, BTW, we're interested in what utilities and features you all would like to see from a large userbase of PGP users. - Nik

2 1

Re: procmail
by tim werner 17 Dec '03

17 Dec '03

>Date: Tue, 31 May 1994 11:22:17 -0600 >From: Martin Janzen <janzen(a)idacom.hp.com> > >tim werner <werner(a)mc.ab.com> writes: >>> With procmail, you can associate arbitrary actions with a match, so no >>> it would not have to be silent. >> >>Will anyone who has procmail working please send me an example of how you >>use it? I am totally confused. > >First, you have to tell the mail system that you want your mail to be >filtered through the procmail program. You do this by creating a >one-line file called ".forward" in your home directory: > >"| IFS=' '; /usr/local/bin/procmail -p" Sorry to bother the list with this thread, but I need just one more question answered, and I don't know where else to ask. I work on a heterogeneous system. My personal workstation is a decstation, running Ultrix-4.3, but I'm pretty sure that email enters our local domain via a sparcstation running SunOS-4.1.3. My email ends up in /var/spool/mail/werner, which is one of the sparcstation disk partitions. If I use the above-mentioned .forward magic to start procmail, does it execute on my local decstation, or on the sparcstation. In other words, do I build a decstation or sparcstation executable? Is there some way I can test this without the mail daemon getting into some kind of infernal .forward loop if there is an error? thanks a lot, tw

4 3