December 2003 - cypherpunks-legacy

Leviathan Dying
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Tue, 25 Nov 1997 10:21:05 -0800 to: misesmail(a)colossus.net from: news(a)mises.org subject: Leviathan Dying Sender: owner-misesmail(a)colossus.net Precedence: Bulk "The Future of Liberty" is the title of a feature piece in VITAL SPEECHES OF THE DAY (November 15, 1997) by Llewellyn H. Rockwell, Jr. "The leviathan state, that monster devouring civilization in this century, is in the throes of death," says Rockwell. "This is not a wish or a prediction, but a conclusion drawn from a broad look at the trends of the last decade and a half, which, if we take the right steps, can continue on into the next century. What has happened around the world--nation states collapsing, markets outwitting planners, citizens rising up against government masters--can and is happening here at home." The speech is from the 15th anniversary conference of the Ludwig von Mises Institute. Rockwell--head of the Institute--explains that in our times, we are witnessing the development of something more radical and far reaching than mere "limitation of government"; the very idea of institutionalized and centralized state power is under fire. The primary catalysts for this trend are the end of the Cold War, the increasing global resentment of the U.S. imperium, and the rise of new information technologies. All that's left in their wake is the reality of Washington as a parasite, which is how government is increasingly regarded in the late nineties. Rockwell spells out the implications of this and foresees a future of liberty, conditioned on intellectuals being willing, in the tradition of Mises and Rothbard, to take the right steps in leading the way. VITAL SPEECHES is widely indexed. Also in this issue are speeches by Bill Clinton and Madeleine Albright. --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

1 0

Suggested Reading...
by Jim Choate 17 Dec '03

17 Dec '03

The Case Against The Global Economy: and for a turn toward the local ed. J. Mander, E. Goldsmith ISBN 0-87156-865-9 $16.00 A collection of 43 essays discussing the consequences and alternatives to unitary global economy. The homogoneity of such a system is seen as counter-productive to the long-term human condition. ____________________________________________________________________ | | | | | We built your fort. We will not have it used against us. | | | | John Wayne - Allegheny Uprising | | | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

official CyberCash response
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text X-Sender: cme(a)cybercash.com Date: Tue, 25 Nov 1997 15:37:14 -0500 To: rah(a)shipwright.com From: Carl Ellison <cme(a)cybercash.com> Subject: official CyberCash response Cc: cme(a)cybercash.com Mime-Version: 1.0 If you know of any lists where the message appeared but the official response didn't, you're welcome to post the following. - Carl -------------------------------------------- [The following should appear in its entirety if it's printed at all.] The following message appeared on the net. From: Anonymous <anon(a)ANON.EFGA.ORG> Subject: Major security flaw in Cybercash 2.1.2 To: BUGTRAQ(a)NETSPACE.ORG CyberCash v. 2.1.2 has a major security flaw that causes all credit card information processed by the server to be logged in a file with world-readable permissions. This security flaw exists in the default CyberCash installation and configuration. The flaw is a result of not being able to turn off debugging. Setting the "DEBUG" flag to "0" in the configuration files simply has no effect on the operation of the server. In CyberCash's server, when the "DEBUG" flag is on, the contents of all credit card transactions are written to a log file (named "Debug.log" by default). The easiest workaround I've found is to simply delete the existing Debug.log file. In my experience with the Solaris release, the CyberCash software does not create this file at start time when the DEBUG flag is set to 0. The inability to turn off debugging is noted on CyberCash's web site under "Known Limitations". The fact that credit card numbers are stored in the clear, in a world readable file, is not. We have taken this quite seriously and have put through a full release of our software which will be available Monday 11/24 for three platforms and others shortly thereafter. The flaw was in the debug logging function, not in the protocols or core implementation. Nonetheless, the effect was an unnecessary exposure of potentially sensitive information, and it shouldn't have gone out the door that way. We're tightening our internal processes to avoid this in the future. That said, here's the actual exposure. The credit card information that's in the clear in the log comes from "merchant-initiated" transactions, which means the merchant obtains the credit card number from somewhere -- phone, mail, fax, SSL-protected Internet interaction, or unprotected Internet interaction. The merchant thus has the same info in the clear already. If the card number was provided via a wallet, then the card number is blinded at the consumer's end. It is therefore not in the clear as it passes through the merchant's machine and the reported exposure does not apply.. In order for the unprotected log to pose a risk of exposure, someone has to be able to gain access to the merchant's machine. If the machine is well protected, viz behind a firewall and/or carefully configured, presumably an outsider won't be able to gain access. And in terms of the *additional* exposure the open log represents over existing risks, if the same information is accessible in the clear elsewhere on the machine, eliminating from the log or encrypting the log provides little or no real protection. We continue to advise merchants to take strong steps to protect their machines. To our knowledge, the exposure documented above has not resulted in the actual loss of any customer data or other security incident. ---------------------------------- Steve Crocker Desk: +1 703 716 5214 CyberCash, Inc. Main: +1 703 620 4200 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 20191 crocker(a)cybercash.com --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

2 1

Freedom Forum First Amendment conference (12/16/97)
by Declan McCullagh 17 Dec '03

17 Dec '03

----------- Date: Wed, 26 Nov 1997 10:33:05 -0500 From: Paul McMasters <pmcmasters(a)freedomforum.org> Subject: First Amendment Conference The Freedom Forum is sponsoring a major conference on the First Amendment on December 16 in Arlington, Va. We will be releasing Donna Demac's "State of the First Amendment" report and a landmark public opinion survey on the First Amendment. In addition, there will be presentations by leading authorities on violence in the media, hate speech, pornography, flag desecration, television, the Internet, videos, the press, art, and religion. If you would like more details and directions for signing up (there is no charge), please go to my web page at: http://www.freedomforum.org/first/1997/11/20famdcon.asp Here it is in a nutshell: Who: Everyone concerned about the First Amendment What: State of the First Amendment conference Where: The Freedom Forum World Center, Arlington, Va. When: Tuesday, December 16, from 8:30 a.m. until 5:30 p.m. Why: Release of a major report, "State of the First Amendment," and a landmark national survey of public attitudes toward the First Amendment How: Just check our web site for details and directions The catch: There is none. No charge. Good food. Good conversation. First-rate speakers. Dynamite program. Contact: Paul McMasters, 703-284-3511, or: pmcmasters(a)freedomforum.org

1 0

Newsletter Internetwk: InternetWeek Newsletter - Nov. 25
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text To: dcsb(a)ai.mit.edu Subject: Newsletter Internetwk: InternetWeek Newsletter - Nov. 25 Date: Tue, 25 Nov 1997 08:01:13 -0500 From: "Eric S. Johansson" <esj(a)harvee.billerica.ma.us> Sender: bounce-dcsb(a)ai.mit.edu Precedence: bulk Reply-To: "Eric S. Johansson" <esj(a)harvee.billerica.ma.us> ------- Forwarded Message That Ain't No Standard Spec It looks like SET may have run out of breath before even leaving the starting gate. Despite a dogged insistence by its sponsors that the 6-month-old Secure Electronic Transactions specification is essential to the growth of Internet commerce, the technology's creators cannot point to one operational deployment. And with good reason, apparently. The two main beneficiaries of the technology--merchants and banks--say the technology is severely flawed. They say compliance with the spec does not guarantee compatibility across vendor implementations. They further charge that SET is too complex to integrate cleanly with legacy transaction systems. In short, they say, the standard is not a standard at all. "It's an enormously complex technology that's flawed from the bottom up," according to Aberdeen Group analyst Chris Stevens. "The only people who are interested in it are the credit card associations, analysts, the press, Hewlett- Packard and IBM." Two of SET's inventors, Hewlett-Packard's VeriFone division and IBM, all but admitted SET's shortcomings earlier this month when they announced a program to ensure that their SET 1.0-enabled products are interoperable. The results will be published in a reference guide for developers. But SET products are supposed to be interoperable by definition, according to the published spec. Other features of the spec are confidentiality of information, integrity of data, card holder account authentication and merchant authentication. The preliminary 0.0 version of the spec has been extended to February of next year so retailers can work with a more tested version through the Christmas season. Version 2.0 is already in the works for release late next year. As a result of the glitches, the sponsors of the initiative, mainly the credit card issuers and E-commerce software vendors, are loosening their definition of a standard. "In the SET 1.0 specification, we tried to be as precise as possible, but any specification is open to interpretation," said Steve Mott, MasterCard's senior vice president for E-commerce. "The marketplace will determine if it's a standard." Mott acknowledged that the root of SET's troubles is its complexity. SET relies on a three-tier architecture-the client wallet, the merchant server and the gateway to processing banks. Not only does each tier have to exchange transaction data, but it must be able to do so with software developed by different vendors. Moreover, as a certificate-based system, SET requires the management of digital certificates for millions of merchants and consumers. All of this has left the banking industry holding the ball. "There are a lot of operational issues left unresolved, like the problem of integrating SET and a new level of certificate information with the banks' legacy systems," said Stephanie Denny, until recently the vice president and director of marketing for Bank of America's credit card unit. By Matthew Friedman http://techweb.cmp.com/internetwk/news/news1124-1.htm ************************* - ------------------------------------------------------- Copyright 1997 CMP Media Inc. a service of InternetWeek. - ------------------------------------------------------- Distributed by Email Publishing Inc. - http://www.emailpub.com ------- End of Forwarded Message For help on using this list (especially unsubscribing), send a message to "dcsb-request(a)ai.mit.edu" with one line of text: "help". --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

1 0

US Air Force IPSEC Requirements
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text From: "Boyter, Brian A." <boyter(a)afiwc01.af.mil> To: "'ipsec(a)tis.com'" <ipsec(a)tis.com> Subject: US Air Force IPSEC Requirements Date: Tue, 25 Nov 1997 17:03:03 -0600 MIME-Version: 1.0 Sender: owner-ipsec(a)ex.tis.com Precedence: bulk First, I would like to introduce myself... My name is Brian Boyter, I'm a Senior Consulting Engineer with the Computer Sciences Corp, and I am under contract to the US Air Force Information Warfare Center in San Antonio, Texas, working on USAF computer security... The USAF is evaluating the use of IPSEC products to help secure its unclassified networks... These unclas networks are used to communicate with contractors, and to process financial, logistic, personnel, and medical data... The IPSEC would be used to protect the data from unauthorized viewing and to protect the networks and computers from hackers... Our goal is to eventually IPSEC encrypt all unclassified computer communications end-to-end... The USAF recently completed a hasty evaluation of several IPSEC products... Most products would work fine for a small organization, but do not scale to an enterprise the size of the USAF (500,000 computers)... Here is a short list of basic USAF requirements which we found lacking in the current IPSEC products: 1. The Department of Defense will soon deploy a Public Key Infrastructure (PKI)... The IPSEC products need to use this existing PKI (not require a separate keying product)... 2. The USAF uses HP OpenView as its standard SNMP management product... Error logging and other IPSEC status information needs to interoperate with OpenView... 3. The USAF needs to be able to manage the IPSEC security policy sanely... An example of a USAF IPSEC security policy might be: "all USAF computers can talk to all other USAF computers using DES, all other computers it talks in-the-clear"... It will not be possible to manage 500,000 different rule sets... The security policy must be made simple... We need the X.500 equivalent of *.mil, *.af.mil, *.lackland.af.mil, and *.hospital.*.af.mil so that we can generate rule sets using these wild cards... I don't think rules based on IP addresses will work either... I'm not including interoperability in the above list because the ANX has done a good job of making that requirement visible.... What I'm trying to point out is two things: 1. The IPSEC products need to re-use as much of our existing infrastructure as possible (for example PKI, SNMP, etc)... If the USAF were a small company that didn't have a large infrastructure investment already, it wouldn't be an issue... But if each IPSEC product requires a management console at each air force base, then that can add up to millions of dollars, thousands of man hours, training costs, etc... 2. I'm also trying to point out that there is no standard (that I can find) for representing, storing, or disseminating the security policy.... Although these are Air Force requirements, I'm sure the same requirements will exist for any large enterprise contemplating the use of IPSEC products... I plan to be at the IETF meeting in December and will be glad to speak to anyone about these issues... Perhaps an IPSEC security policy BOF could even be arranged??? Thanks, Brian Boyter boyter(a)afiwc01.af.mil (210)977-3113 --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

2 1

Quoting Portions of a Signed Document
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- It would be neat if you could quote people and prove that they signed the particular paragraph quoted without supplying the entire text. Is there a way to do this? (It seems impossible, but so does mental poker.) A crude approach would be to sign every paragraph or line separately, but that's obviously inelegant. Monty Cantsin Editor in Chief Smile Magazine http://www.neoism.org/squares/smile_index.html http://www.neoism.org/squares/cantsin_10.htm -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNHscCpaWtjSmRH/5AQHlUAf+MgXC6uKGn+EMsOzw9wumJeYdjNWYTlnl IxaksIHa2o1HL88GZlrve7F3lATOM1IpDlZIIwe56rGZzqTQci+ImMIG3kqKWyTE 6NjtTqKY0Qr028MsudhVE+RwTvUIzbsi+6Qh4wJo+AzfEmnKlMkPHBxMmgem/+sQ Cm3PasUW91N6xakkoR/M9x6ZtJ8MlAAI1C460LIndzV2DqxnFnyNs9cCxVYaZ+FQ BMK8Mwf8EXhnSrfv6CQ3oKgi8cO1jd0FHyLr7uYQ8n0HWWMMcC06k3rYyo8EXInc WyJ/oeuSewhQjTumrPn5e3+aP55k3IzttBhE2TQy6tBX9r1nX7fVVg== =feAO -----END PGP SIGNATURE-----

6 5

RE:: [NTSEC] - cheap tempest solution (fwd)
by Ray Arachelian 17 Dec '03

17 Dec '03

=====================================Kaos=Keraunos=Kybernetos============== .+.^.+.| Ray Arachelian |Prying open my 3rd eye. So good to see |./|\. ..\|/..|sunder(a)sundernet.com|you once again. I thought you were |/\|/\ <--*-->| ------------------ |hiding, and you thought that I had run |\/|\/ ../|\..| "A toast to Odin, |away chasing the tail of dogma. I opened|.\|/. .+.v.+.|God of screwdrivers"|my eye and there we were.... |..... ======================= http://www.sundernet.com ========================== ---------- Forwarded message ---------- Date: Mon, 24 Nov 1997 20:50:10 -0500 From: "Stout, William" <StoutW(a)pios.com> To: "'ntsecurity(a)iss.net'" <ntsecurity(a)iss.net> Subject: RE: OFF-TOPIC RE: [NTSEC] - cheap tempest solution > ----- Original Message ----- > From: Tim Lebrun [SMTP:tlebrun@internetmci.com] > > This may be a stupid question, but what is tempest monitoring? And > what kind of information can you get from doing it? Ooh, ooh, something I was trained in once. Tempest protection is the ability to prevent undesirable signals from escaping a computer system. In the old days, electro-mechanical teletypes were used by the military. Someone discovered that placing a signal analyzer on the power feed shows what character is represented by each signal spike. Automating the translation gives you a mirror output of each message someplace else. Electrical filters (not just transformers which can pass these signals) prevent this. Present day keyboards and mice also radiate signals, readable even though the device is within the FCC part 15 class A or B device signal emanation restrictions. Both tube-type and LCD displays are big transmitters, and can be read by receivers connected to similarly phased displays. The receivers can be in a nearby building, van, plane or satellite. Makes you think twice when typing PGP messages or 'accidentally' hitting a 'can be used against you' newsgroup. Search for 'Van Eck' for more data. Physical metallic shielding (and thorough testing) fixes this. Network wires and equipment are also major radio transmitters, metallic types are readable from a distance, and of course networks can be directly tapped, even glass fiber. (It's been found in military environments, a simple wire was surreptitiously stretched above a ceiling, and which would act as a retransmitter.) All cables are guilty of transmitting readable signals if not properly shielded and filtered. Van Eck/tempest exploiting devices are used in the military/spy/wire-fraud/'drug war' business and in both government sponsored and private corporate espionage. Don't confuse EMP (Electro-Magnetic Pulse) protection with Tempest, since EMP is a high-energy pulse (such as created by a nuclear burst) that generates a high-voltage electrical pulse in both plugged in and off-line electronic equipment, and typically frys all unshielded electronics. Same effect as a power surge, but affects all circuits, even parts sitting on shelves. HERF guns do the same thing. Damn. I'm also guilty of contributing to the noise and 'firewalls-list' demise of NTsecurity list. Bill Stout

1 0

New Algorithm (reposted)
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Hello I send you links to my site where my crypto algorithm is published. I hope you will find time to visit it and see what I have discover. Algorithms I have design are Anigma and MEX128. Anigma is encryption algo based on use Variable Function Technology, it main characteristic is possibility to create unique encryption function for every possible key. This make algorithm strong to all known attacks, this is only my thesis I look for your help to find out is it true. Please visit <http://eon.pmf.ukim.edu.mk/~kbajalc/algo/index.html>. Documentation about Anigma and Mex128 now are available only in Macedonian. I will appreciate very much if you give me your opinion about Anigma and Mex128 or give me address of people who can do. Koki ------------------------------------------------------------------------ ------------------------- Kostadin Bajalcaliev http://eon.pmf.ukim.edu.mk/~kbajalc/ 26th of April Str. No: 14 91480 Gevgelija kbajalc(a)eon.pmf.ukim.edu.mk Macedonia kbajalc(a)informa.mk ------------------------------------------------------------------------ ------------------------

2 1

Cato Institute request for policy papers on encryption
by Declan McCullagh 17 Dec '03

17 Dec '03

---- Date: Tue, 25 Nov 1997 10:18:33 -0500 From: Solveig Singleton <solveig(a)cato.org> Subject: Request for short policy papers Cato Institute's progam for information studies (that is, privacy and crypto) is interested in receiving proposals for **short** policy papers (five to thirty pages) on different aspects of the encryption debate. In particular, I am interested in detailed, well-argued but concise papers addressing the following: * The costs (narrowly conceived) of mandatory key recovery: OMB has one estimate with no particular empirical support beyond the assertions of national security folks. We are interested in cost estimates that move the debate forward in being based on something more concrete and reliable than what has been offered thus far--so, we won't need years of carefully calibrated econometric data (which just isn't there)--but we do want something more than speculation. * Also needed, a short paper illustrating the impact of the export control regime on experimental software or hardware ventures. What are the costs of the regulatory process in time and money, from the standpoint of the developer? Anecdotes welcome. * I would also like to do a paper on the uses of encryption in combatting human rights violations worldwide, again replete with examples and anecdotes... * and A short paper on the ease of evading export controls--detailing the ease with which encryption programs can be homemade, purchased from foreign sources, etc.; * and a short paper on the strength of U.S. assertions that other countries are likely to go along with U.S. attempts to foist mandatory key escrow upon everyone by international agreement. Please contact me if you are interested. Solveig Singleton (202) 789-5274 (202) 842-3490 (fax) Director of Information Studies Cato Institute 1000 Mass. Ave. NW Washington, DC 20001

2 1