December 2003 - cypherpunks-legacy

ARMCHAIR Commando List(Cypherpunks@cyberpass.net)
by Anonymous 17 Dec '03

17 Dec '03

"I CANT PARTICIPATE IN THE REVOLUTION BECAUSE I DIDNT GET ENOUGH NOTICE OR ITS TOO INCONVENIENT OR THEY ARE USING LEFTIST PROTEST TECHNIQUES" EXPORTING PGP WITHIN MINUTES OF ITS RELEASE NOW THAT WOULD IMPRESS ME... (BEEN THERE DONE THAT!) NOW I am trying to shake the apathy from all of you.. Its so much easier to talk about revolution than participating or contributing... Talking about revolution does NOT make it happen magically.. I suspect the revolution will die given the above anon

1 0

crypto boredom
by bill payne 17 Dec '03

17 Dec '03

Tuesday 12/15/98 4:37 PM John Young Seeing http://jya.com/kea-errata.htm makes me feel good that I am not doing crypto work anymore. I talked with Kent Parsons this afternoon at Holman's computer. Parsons was the department manager who was going to make his claim-to- fame at Sandia on the Forth code we developed. "We aren't getting the recognition [for Forth] we deserve." was a Parsons quote. I told Parsons that the Forth code we developed is executing all over the world. Jane Ellson was one of Parson's secretaries when we did the Forth 8085 and 8051 development in the weapons components department. Ellson is now Sandia president Paul Robinsons secretary. I need to revise my NSA-funded and Sandia-approved Forth book for the 80c32 and windows. http://www.apcatalog.com/cgi-bin/AP?ISBN=0125475705&LOCATION=US&FORM=FORM2 I saw http://jya.com/intel120898.htm. NSA's Forth expert Donald Simard talked to me about putting Forth on a x86 PC as a stand-alone secure operating system. Putting a secure RELIABLE operating system on a Pentium-class processor will be a MAJOR task. Perhaps more than just building a rad hard version of the chip. Parsons also led the effort at Sandia to build the 8051 as a rad hard chip at Sandia to replace Sandia's rad hard 8085 chip SET. Forth works great for weapons programmers. We need to get this unfortunate matter settled so that we can ALL move on to more constructive projects. Later bill

1 0

HAS The Revolution Died??
by HyperReal-Anon 17 Dec '03

17 Dec '03

"I CANT PARTICIPATE IN THE REVOLUTION BECAUSE I DIDNT GET ENOUGH NOTICE OR ITS TOO INCONVENIENT OR THEY ARE USING LEFTIST PROTEST TECHNIQUES" EXPORTING PGP WITHIN MINUTES OF ITS RELEASE NOW THAT WOULD IMPRESS ME... (BEEN THERE DONE THAT!) NOW I am trying to shake the apathy from all of you.. Its so much easier to talk about revolution than participating or contributing... Talking about revolution does NOT make it happen magically.. I suspect the revolution will die given the above anon

2 1

DARPA's Active Network page (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Tue, 15 Dec 1998 17:50:56 -0500 > From: Robert Hettinga <rah(a)shipwright.com> > Subject: DARPA's Active Network page > I saw an article on this in InfoWorld. NAI/TIS and DARPA talking about > putting self-switching packets into the network. I don't see this as too > far off from packets purchasing their passage across the network with > micromoney of some kind. How does the packet know what is a good price or a bad price as it makes each hop? Whose processor is it using to run its program to evaluate the costs? Who pays for that processor cost on a node that isn't selected? Who has access to the audit trail? How does a reliable copy get back to the originator? How does it do this in an anonymous network? ____________________________________________________________________ What raises the standard of living may well diminish the quality of life. The Club of Rome The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage(a)ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------

2 1

NSA Electronic Sheriff
by John Young 17 Dec '03

17 Dec '03

>From a new report: "Cybercrime, Cyberterrrorism, Cyberwarfare" Tomorrow's frontline commanders will be drawn from the ranks of computer wizards. The sandal culture is challenging the wingtips. The National Security Agency's (NSA) new electronic sheriff, responsible for protecting NSA's ground stations, is a 23-year-old GS-14. In the civilian sector, "techies" have moved into senior management positions. http://jya.com/cyber-trip.htm

2 1

Equipment Resource: December Equipment Update
by sales＠equipmentresource.com 17 Dec '03

17 Dec '03

EQUIPMENT RESOURCE Ph:303-451-8022 Fax:303-451-8747 11184 Huron Ste.12 Northglenn, CO 80234 Equipment Resource wishes you a Happy Holiday! What better way to get ready for a prosperous New Year than to Accelerate Assembly. Increase production floor space by selling your surplus, or add a link on our web site to increase sales. (click on the http links to view equipment. You must be online.) Equipment Resource presents its top 10 list to increase production and save money! 1.Westek Formula III Plus. Inline Aqueous Cleaner. Great cleaner, Great Condition. 2.Eubanks 2700 -IV. Wire cut/strip system. With TAB wire marker. Beautiful Shape. 3.Watkins Johnson 18-SMD. Reflow oven. Edge Rail, N2O. Convection. Nice Shape, Nice Price. 4.Quad 100 Pick and Place Systems. Several available. Great start up system. http://www.equipmentresource.com/quad_100_pick.htm 5.Unit Design MDS 100. Drag Solder System. Rebuilt from the frame up. Warranty available. http://www.equipmentresource.com/images/UDMDS.jpg 6.Hepco 8000-1. Axial Cut and Form. Tape feed. Hassle free component prep! http://www.equipmentresource.com/images/Hepco8000-1.JPG 7.Blue M Oven. 1 Cubic foot interior. 38c to 260c. Stabil-Therm Controller. Make an offer. 8.ECD 6300 Batch Washer. PCB Cleaning made easy. No Frills, Nice Price. http://www.equipmentresource.com/images/ECD6300-101398.JPG 9.Cut & Bend. Hand Crank Axial Prep System. Simple efficient way to increase production. http://www.equipmentresource.com/images/cutbend.jpg 10.AMI Presco 1826. Screen Printer. Most under-rated system on the market.= Quality/Low cost Leasing available on all equipment For a complete listing of Equipment, to Sell your Surplus at no Cost, or to take advantage of a Free link to your web page go to .http://www.equipmentresource.com If you know someone who could benefit from our services please forward this to them. If you do not wish to receive equipment updates please reply with remove in the subject line to. All recipients who do not reply to remove will receive further updates. Thank you all; buyers and sellers, friends old and new, and inquirers too for your business and support all thru the year of 1998. We send our sincere wish for a prosperous business year with good health and much happiness to each of you. Sincerely, All of us at Equipment Resource.

1 0

Distributed Programming with DIPC (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From owner-sparclinux-outgoing(a)vger.rutgers.edu Tue Dec 15 20:47:43 1998 Date: Tue, 15 Dec 1998 17:09:40 -0600 (CST) From: Kamran Karimi <karimi(a)cs.uregina.ca> To: sparclinux(a)vger.rutgers.edu Subject: Distributed Programming with DIPC Message-ID: <Pine.SGI.3.91.981215170900.10107H-100000(a)MERCURY.CS.UREGINA.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;sparclinux(a)vger.rutgers.edu Sender: owner-sparclinux(a)vger.rutgers.edu Precedence: bulk X-Loop: majordomo(a)vger.rutgers.edu To people interested in distributed programming and clustering under Linux, This is to introduce DIPC (Distributed Inter-Process Communication). DIPC is a software-only solution for very easy distributed programming under the Linux operating system. Here developers design their applications as a group of processes, each possibly running on a different Linux computer, and then use DIPC to _transparently_ exchange data between them. The main objective of the DIPC project is to make distributed programming as much like "normal" programming as possible. DIPC hides itself behind UNIX System V's IPC mechanisms, consisting of Semaphores, Messages, and Shared Memories, and makes them work over a network. This means that DIPC offers, among other things, Transparent Distributed Shared Memory (DSM) with strict consistency: Processes can read from and write to the shared memory with no need for any explicit synchronization! This makes DIPC very different from systems like PVM or MPI. The source code of a DIPC program is nearly identical to a normal UNIX program using System V IPC. Actually, a DIPC program can even run in a Linux computer with no DIPC support; no need for recompilation. System V IPC is widely available in UNIX variants, and is very well documented, meaning that developers may already know the programming interface, or they can learn it very easily, confident that the usefulness of the newly learned material is not tied to the availability of DIPC. This is in sharp contrast to most other distributed programming systems. Using a mainly "shared-memory" programming interface means that the same distributed application can also run on a multi-processor Linux machine at "full speed" DIPC modifies the Linux kerenl in order to offer its excellent degree of transparency. There are no needs for any link libraries, and it can be used from any programming language that allows access to the OS calls. The hardware can consist of a single Linux machine, or a cluster of computers connected to each other by a TCP/IP network. DIPC has been tested on inter-continental WANs and is a heterogeneous system, as it can run on Linux/i386 and Linux/m68k, with both versions being able to talk to each other. (volunteers for porting DIPC to other CPU families are welcome). People intersted in distributed systems can easily and safely try DIPC. After patching a standard Linux kernel, DIPC becomes a configuration option (make config), and can be left out at compile time if desired. When DIPC is compiled in, it can be turned off any time with no need for a reboot. For more more information about DIPC, visit http://wallybox.cei.net/dipc . You can download the package (which includes the sources and the documentation) from the web page, or from ftp://wallybox.cei.net/pub/dipc . A mailing list devoted to discussions about DIPC is addressed at linux-dipc(a)wallybox.cei.net . Feel free to send your comments and questions here. To view the previous posts to DIPC's mailing list target your browser at http://wallybox.cei.net/dipc/ml-archive . -Kamran Karimi - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of the message to majordomo(a)vger.rutgers.edu

1 0

Re: First "Crypto Refugee"?
by Tim May 17 Dec '03

17 Dec '03

At 11:04 AM -0800 12/15/98, tony(a)secapl.com wrote: >> the shakespeare analysis seems like a good idea to >> me. I am not aware of literate papers that try to >> analyze it with frequency analysis instead of >> just vague assertions by the authors. there is >> a huge set of literature that tries to link of >> the writings of shakespeare to someone else, but >> as far as I know not much of it is computer analysis. > > This was what brought William Freidman to Riverside, where he both >created monographs on cryptanalysis and met his wife. (described in detail >in Kahn.) And computerized textual analyses of Shakespeare was one of the most publicized applications of the computers in the 60s. I remember reading several stories about this then. And I recall an exhibit on the results of such computerized search, as of around 1968 or so, at the Folger Shakespeare Library in Washington, D.C. (a class outing). As when Detweiler or someone proposed this as a "neat thing for Cypherpunks to do" a couple of years ago, the idea was old before 98% of this list were born. Not saying it's not still an interesting research topic, just that it's a well-established field. And most of the low-hanging fruit has been picked. --Tim May Y2K -- LMGALMAO -- Loading my guns and laughing my ass off ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 831-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments.

1 0

DigiCash Update, part II
by Lucky Green 17 Dec '03

17 Dec '03

As some of you may be aware of, I am involved with an effort to acquire DigiCash. Allow me therefore to suggest that now is not a good time to attempt to purchase a patent license directly from DigiCash. You would most likely be paying too much. DigiCash has for months now attempted to find a buyer for the company's assets. Due to the expectations on the value of the assets, and differences between this and the offers they've received, the board has turned down these offers, including the first offer by my group. Ultimately, the differences between some of the high expectations the board has, and the actual offers they are receiving will be worked out between higher offers and lower expectations. Until then, DigiCash operates on a post-bankruptcy filing bridge loan. This loan won't last forever. Ultimately, DigiCash will be sold. But nobody wants to wait forever. Not you, not me, not the DigiCash board. The faster DigiCash gets sold to our group, the faster the technology will become available to all interested parties under low cost (and in many cases free) licensing terms. Even if DigiCash should now be willing to sell licenses to generate cash flow or reorganize in some new plan and forestall the inevitable sales of assets a little bit longer, the current DigiCash is unlikely to make the licenses available for as low of a cost as our group will make them available after an acquisition of DigiCash. We are in a position to offer potentially significant cost minimization to any prospective licensee of DigiCash IP. With every additional party committing to our effort, we can reduce the cost per license. Scott of course would be amiss of his fiduciary duty would he not attempt to maximize the financial return to DigiCash. We have no such constraint. I have a lot of respect for Scott and he is trying to do what is best for the DigiCash shareholders and debtholders (As he should). We on the other hand are more focused on what is best for the technology, to ensure it is deployed widely and in all it's various potential uses. The more serious parties join our effort, the faster will we be able to make another bid and the faster the DigiCash board will review and hopefully approve our next offer. Ultimately, everybody will be happy. The creditors will be happy since they get their money, the current executive group at DigiCash will be happy to move on having successfully found a palatable deal, and the licensees will be happy, since they will be able to obtain the IP and options for support and technology development instead of being held in limbo with the present DigiCash situation. And of course the developer community will be happy, since the patents will be available to all, not just to the few to which DigiCash might license the patents to improve their unfortunate cash flow situation. This broad availability will allow the market to validate the technology. No single player, or even small group of players, can make eCash a success. Only an aggressive push by many large, small and medium sized players who are all deploying eCash and blinded private payment systems can. This is one of the many reasons our group has the support of several of the larger banks in the world, banking software/EDI vendors, credit card clearing houses, personal financial/cryptography software vendors, global media corporations, and other players that are required to make eCash and other DigiCash IP derived technologies ubiquitous. Feel free to contact DigiCash directly if you must. We certainly encourage people who are interested in exclusive ownership of the DigiCash IP, and are not interested in opening up the patents or technology to deal directly with them since this is contrary to our goal. But if you are interested in any one part, one use or application or even in all of the parts in a non-exclusive way please make sure to email me first as I believe it will benefit everyone for a lot less money. --Lucky Green <shamrock(a)netcom.com> I will soon revoke my PGP key 0x375AD924 for administrative reasons.

5 5

The Fallacy of Cracking Contests
by Bruce Schneier 17 Dec '03

17 Dec '03

The Fallacy of Cracking Contests Bruce Schneier You see them all the time: "Company X offers $1,000,000 to anyone who can break through their firewall/crack their algorithm/make a fraudulent transaction using their protocol/do whatever." These are cracking contests, and they're supposed to show how strong and secure the target of the contests are. The logic goes something like this: We offered a prize to break the target, and no one did. This means that the target is secure. It doesn't. Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so. 1. The contests are generally unfair. Cryptanalysis assumes that the attacker knows everything except the secret. He has access to the algorithms and protocols, the source code, everything. He knows the ciphertext and the plaintext. He may even know something about the key. And a cryptanalytic result can be anything. It can be a complete break: a result that breaks the security in a reasonable amount of time. It can be a theoretical break: a result that doesn't work "operationally," but still shows that the security isn't as good as advertised. It can be anything in between. Most cryptanalysis contests have arbitrary rules. They define what the attacker has to work with, and how a successful break looks. Jaws Technologies provided a ciphertext file and, without explaining how their algorithm worked, offered a prize to anyone who could recover the plaintext. This isn't how real cryptanalysis works; if no one wins the contest, it means nothing. Most contests don't disclose the algorithm. And since most cryptanalysts don't have the skills for reverse-engineering (I find it tedious and boring), they never bother analyzing the systems. This is why COMP128, CMEA, ORYX, the Firewire cipher, the DVD cipher, and the Netscape PRNG were all broken within months of their disclosure (despite the fact that some of them have been widely deployed for many years); once the algorithm is revealed, it's easy to see the flaw, but it might take years before someone bothers to reverse-engineer the algorithm and publish it. Contests don't help. (Of course, the above paragraph does not hold true for the military. There are countless examples successful reverse-engineering--VENONA, PURPLE--in the "real" world. But the academic world doesn't work that way, fortunately or unfortunately.) Unfair contests aren't new. Back in the mid-1980s, the authors of an encryption algorithm called FEAL issued a contest. They provided a ciphertext file, and offered a prize to the first person to recover the plaintext. The algorithm has been repeatedly broken by cryptographers, through differential and then linear cryptanalysis and by other statistical attacks. Everyone agrees that the algorithm was badly flawed. Still, no one won the contest. 2. The analysis is not controlled. Contests are random tests. Do ten people, each working 100 hours to win the contest, count as 1000 hours of analysis? Or did they all try the same things? Are they even competent analysts, or are they just random people who heard about the contest and wanted to try their luck? Just because no one wins a contest doesn't mean the target is secure...it just means that no one won. 3. Contest prizes are rarely good incentives. Cryptanalysis of an algorithm, protocol, or system can be a lot of work. People who are good at it are going to do the work for a variety of reasons--money, prestige, boredom--but trying to win a contest is rarely one of them. Contests are viewed in the community with skepticism: most companies that sponsor contests are not known, and people don't believe that they will judge the results fairly. And trying to win a contest is no sure thing: someone could beat you, leaving you nothing to show for your efforts. Cryptanalysts are much better off analyzing systems where they are being paid for their analysis work, or systems for which they can publish a paper explaining their results. Just look at the economics. Taken at a conservative $125 an hour for a competent cryptanalyst, a $10K prize pays for two weeks of work, not enough time to even dig through the code. A $100K prize might be worth a look, but reverse-engineering the product is boring and that's still not enough time to do a thorough job. A prize of $1M starts to become interesting, but most companies can't afford to offer that. And the cryptanalyst has no guarantee of getting paid: he may not find anything, he may get beaten to the attack and lose out to someone else, or the company might not even pay. Why should a cryptanalyst donate his time (and good name) to the company's publicity campaign? Cryptanalysis contests are generally nothing more than a publicity tool. Sponsoring a contest, even a fair one, is no guarantee that people will analyze the target. Surviving a contest is no guarantee that there are no flaws in the target. The true measure of trustworthiness is how much analysis has been done, not whether there was a contest. And analysis is a slow and painful process. People trust cryptographic algorithms (DES, RSA), protocols (Kerberos), and systems (PGP, IPSec) not because of contests, but because all have been subjected to years (decades, even) of peer review and analysis. And they have been analyzed not because of some elusive prize, but because they were either interesting or widely deployed. The analysis of the fifteen AES candidates is going to take several years. There isn't a prize in the world that's going to make the best cryptanalysts drop what they're doing and examine the offerings of Meganet Corporation or RPK Security Inc., two companies that recently offered cracking prizes. It's much more interesting to find flaws in Java, or Windows NT, or cellular telephone security. The above three reasons are generalizations. There are exceptions, but they are few and far between. The RSA challenges, both their factoring challenges and their symmetric brute-force challenges, are fair and good contests. These contests are successful not because the prize money is an incentive to factor numbers or build brute-force cracking machines, but because researchers are already interested in factoring and brute-force cracking. The contests simply provide a spotlight for what was already an interesting endeavor. The AES contest, although more a competition than a cryptanalysis contest, is also fair Our Twofish cryptanalysis contest offers a $10K prize for the best negative comments on Twofish that aren't written by the authors. There are no arbitrary definitions of what a winning analysis is. There is no ciphertext to break or keys to recover. We are simply rewarding the most successful cryptanalysis research result, whatever it may be and however successful it is (or is not). Again, the contest is fair because 1) the algorithm is completely specified, 2) there are no arbitrary definition of what winning means, and 3) the algorithm is public domain. Contests, if implemented correctly, can provide useful information and reward particular areas of research. But they are not useful metrics to judge security. I can offer $10K to the first person who successfully breaks into my home and steals a book off my shelf. If no one does so before the contest ends, that doesn't mean my home is secure. Maybe no one with any burgling ability heard about my contest. Maybe they were too busy doing other things. Maybe they weren't able to break into my home, but they figured out how to forge the real-estate title to put the property in their name. Maybe they did break into my home, but took a look around and decided to come back when there was something more valuable than a $10,000 prize at stake. The contest proved nothing. Gene Spafford wrote against hacking contests. http://www.itd.nrl.navy.mil/ITD/5540/ieee/cipher/old-issues/issue9602 Matt Blaze has too, but I can't find a good URL. ********************************************************************** Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098 101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590 Free crypto newsletter. See: http://www.counterpane.com

3 2