December 2003 - cypherpunks-legacy

PLA_gue Germ Terrorism
by John Young 17 Dec '03

17 Dec '03

12-30-95. To update the list of terrorist threats, the Wash Post reports on the purchase in May of bubonic plague germs by "white supremacist" Larry Wayne Harris, his bust by the FBI and germ teams, prosecutors amazement that possession of such deadly micro-organisms is not illegal, and the consequent plea bargain of wire fraud with probation. The article explains that possession of "terrorist" mites is not prohibited due to a legal loophole which allows scientific trade in wee supremacists. There are calls for outlawing the meat-eaters by closing the gap in the anti-terrorism bill before Congress. But scientists say how dare you spit in our nanodeath soup. It notes that offshore spread is Commerce regulated. BTW, why this story now about summer events? For the anti-terrorist bill, TLA-plague growth, any germ any? PLA_gue

4 3

(fwd) Benchmarks - revs 1.3.50 & 51
by Julian Assange 17 Dec '03

17 Dec '03

Path: news.apana.org.au!goliath.apana.org.au!sysx.apana.org.au!sleeper.apana.org.au!greathan.apana.org.au!news-mail-gateway From: fluido(a)marktest.pt (Carlo Emilio Prelz) Newsgroups: apana.lists.os.linux.kernel Subject: Benchmarks - revs 1.3.50 & 51 Date: Thu, 28 Dec 1995 08:05:17 +0100 (MET) Organization: Mail-to-News Gateway Lines: 158 Sender: daemon(a)greathan.apana.org.au Approved: usenet(a)greathan.apana.org.au Distribution: apana Message-ID: <Pine.LNX.3.91.951228075225.11217A-100000(a)pimpinel.fluido.org> NNTP-Posting-Host: greathan.apana.org.au Hi. Here follow the benchmark comparisons w.r.t. revisions 50 & 51. I decided to wait before posting rev 50 before because the file read & write results again bounced up with it, and I spent some (very little) time trying to see if I could have done anything to cause that. With no results, as usual. Now I also have results for the "greased weasel", and I decided to send out my numbers for what they're worth. Not much has changed with the latest release... I repeat my query: if anybody has suggestions about these huge jumps in disk performance, please let me know. I am ALWAYS running the benchmark test after a reboot. I login as root, start the process in background and log out, and then generally go to sleep. The machine is NOT online, and is not doing anything important at night. I have not changed anything in the kernel config in the latest 3 revisions. I have a plain old ISA disk controller, and two generally fullish disks, but again, the situation did not change notably between 1.3.49 and 1.3.50. And, I now have to admit that I find it faster, for example, to load a huge C file into emacs, and have it do the syntax coloring. I noticed it this morning. No problems in patching & compiling. --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- From: * Linux pimpinel.fluido.org 1.3.49 #77 Fri Dec 22 21:05:57 MET 1995 i486 * Fri Dec 22 21:41:03 MET 1995 To: * Linux pimpinel.fluido.org 1.3.50 #78 Mon Dec 25 11:18:00 MET 1995 i486 * Mon Dec 25 12:11:11 MET 1995 ******* Results ******* File Write (30 seconds) || 1000.0 -> 9460.0 +846.00% File Write (10 seconds) || 1200.0 -> 8070.0 +572.50% File Copy (30 seconds) || 968.0 -> 2636.0 +172.31% File Copy (10 seconds) || 1024.0 -> 2645.0 +158.30% Execl Throughput Test || 67.9 -> 85.3 +25.63% C Compiler Test || 48.7 -> 51.9 +6.57% Pipe-based Context Switching Test || 9863.0 -> 10493.0 +6.39% Process Creation Test || 347.7 -> 368.9 +6.10% Shell scripts (1 concurrent) || 96.4 -> 101.9 +5.71% Shell scripts (4 concurrent) || 25.5 -> 26.5 +3.92% Shell scripts (2 concurrent) || 50.8 -> 52.6 +3.54% System Call Overhead Test || 29945.4 -> 30523.5 +1.93% Dhrystone 2 using register variables || 49658.9 -> 49910.8 +0.51% Arithmetic Test (type = int) || 8365.0 -> 8377.5 +0.15% Arithmetic Test (type = double) || 5063.6 -> 5071.1 +0.15% Recursion Test--Tower of Hanoi || 726.1 -> 727.1 +0.14% Arithmetic Test (type = arithoh) || 127103.2 -> 127265.6 +0.13% Arithmetic Test (type = short) || 7508.8 -> 7515.5 +0.09% Arithmetic Test (type = register) || 8367.3 -> 8372.8 +0.07% Arithmetic Test (type = float) || 5066.8 -> 5069.3 +0.05% Arithmetic Test (type = long) || 8371.8 -> 8372.1 +0.00% Shell scripts (8 concurrent) || 13.0 -> 13.0 +0.00% Pipe Throughput Test || 17850.0 -> 17726.9 -0.69% Dhrystone 2 without register variables || 51001.9 -> 49772.1 -2.41% File Read (30 seconds) || 4613.0 -> 4404.0 -4.53% File Read (10 seconds) || 4648.0 -> 4390.0 -5.55% Dc: sqrt(2) to 99 decimal places || 11886.7 -> 10822.2 -8.96% --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- From: * Linux pimpinel.fluido.org 1.3.50 #78 Mon Dec 25 11:18:00 MET 1995 i486 * Mon Dec 25 12:11:11 MET 1995 To: * Linux pimpinel.fluido.org 1.3.51 #79 Wed Dec 27 19:16:06 MET 1995 i486 * Wed Dec 27 22:41:23 MET 1995 ******* Results ******* File Read (30 seconds) || 4404.0 -> 4548.0 +3.27% File Read (10 seconds) || 4390.0 -> 4516.0 +2.87% Dc: sqrt(2) to 99 decimal places || 10822.2 -> 11034.2 +1.96% Process Creation Test || 368.9 -> 375.0 +1.65% File Copy (10 seconds) || 2645.0 -> 2683.0 +1.44% File Copy (30 seconds) || 2636.0 -> 2669.0 +1.25% Shell scripts (4 concurrent) || 26.5 -> 26.8 +1.13% C Compiler Test || 51.9 -> 52.4 +0.96% Dhrystone 2 without register variables || 49772.1 -> 49808.7 +0.07% Arithmetic Test (type = long) || 8372.1 -> 8376.6 +0.05% Arithmetic Test (type = register) || 8372.8 -> 8376.1 +0.04% Arithmetic Test (type = float) || 5069.3 -> 5069.9 +0.01% Arithmetic Test (type = short) || 7515.5 -> 7515.7 +0.00% Shell scripts (8 concurrent) || 13.0 -> 13.0 +0.00% Arithmetic Test (type = double) || 5071.1 -> 5067.4 -0.07% Arithmetic Test (type = arithoh) || 127265.6 -> 127172.0 -0.07% Dhrystone 2 using register variables || 49910.8 -> 49870.6 -0.08% Arithmetic Test (type = int) || 8377.5 -> 8370.4 -0.08% Recursion Test--Tower of Hanoi || 727.1 -> 724.3 -0.39% Shell scripts (2 concurrent) || 52.6 -> 52.3 -0.57% Shell scripts (1 concurrent) || 101.9 -> 101.2 -0.69% File Write (30 seconds) || 9460.0 -> 9356.0 -1.10% Pipe Throughput Test || 17726.9 -> 17227.1 -2.82% Pipe-based Context Switching Test || 10493.0 -> 10194.8 -2.84% System Call Overhead Test || 30523.5 -> 29476.8 -3.43% Execl Throughput Test || 85.3 -> 81.5 -4.45% File Write (10 seconds) || 8070.0 -> 7680.0 -4.83% --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- From: * Linux pimpinel.fluido.org 1.2.10 #59 Tue Jun 13 09:46:17 MET DST 1995 i486 * Tue Jun 27 10:18:13 MET DST 1995 To: * Linux pimpinel.fluido.org 1.3.51 #79 Wed Dec 27 19:16:06 MET 1995 i486 * Wed Dec 27 22:41:23 MET 1995 ******* Results ******* Process Creation Test || 119.9 -> 375.0 +212.76% Pipe-based Context Switching Test || 3446.9 -> 10194.8 +195.77% Dc: sqrt(2) to 99 decimal places || 5906.2 -> 11034.2 +86.82% Execl Throughput Test || 51.6 -> 81.5 +57.95% Shell scripts (8 concurrent) || 10.0 -> 13.0 +30.00% Shell scripts (1 concurrent) || 78.3 -> 101.2 +29.25% Shell scripts (4 concurrent) || 21.0 -> 26.8 +27.62% Shell scripts (2 concurrent) || 41.0 -> 52.3 +27.56% C Compiler Test || 42.2 -> 52.4 +24.17% Dhrystone 2 without register variables || 46284.2 -> 49808.7 +7.61% File Write (30 seconds) || 8911.0 -> 9356.0 +4.99% Recursion Test--Tower of Hanoi || 709.2 -> 724.3 +2.13% System Call Overhead Test || 29238.2 -> 29476.8 +0.82% Arithmetic Test (type = float) || 5055.6 -> 5069.9 +0.28% Arithmetic Test (type = long) || 8353.5 -> 8376.6 +0.28% Arithmetic Test (type = register) || 8353.2 -> 8376.1 +0.27% Arithmetic Test (type = short) || 7496.0 -> 7515.7 +0.26% Arithmetic Test (type = double) || 5056.8 -> 5067.4 +0.21% Arithmetic Test (type = int) || 8353.4 -> 8370.4 +0.20% Arithmetic Test (type = arithoh) || 126914.4 -> 127172.0 +0.20% Dhrystone 2 using register variables || 49802.4 -> 49870.6 +0.14% File Write (10 seconds) || 8100.0 -> 7680.0 -5.19% Pipe Throughput Test || 18512.0 -> 17227.1 -6.94% --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- Enjoy! Carlo -- * ...Ma appena fuori tutto e' gomma, * K * Carlo E. Prelz - fluido(a)marktest.pt tutto e' cicca impiastricciata... * (Marco Zappa-Niente cicca nella scuola) -- +----------------------------------+-----------------------------------------+ |Julian Assange | "if you think the United States has | |FAX: +61-3-9819-9066 | has stood still, who built the largest | |EMAIL: proff(a)suburbia.net | shopping centre in the world?" - Nixon | +----------------------------------+-----------------------------------------+

1 0

Re: PLA_gue Germ Terrorism
by E. ALLEN SMITH 17 Dec '03

17 Dec '03

From: John Young <jya(a)pipeline.com> > 12-30-95. To update the list of terrorist threats, the Wash Post reports on the purchase in May of bubonic plague germs by "white supremacist" Larry Wayne Harris, his bust by the FBI and germ teams, prosecutors amazement that possession of such deadly micro-organisms is not illegal, and the consequent plea bargain of wire fraud with probation. The article explains that possession of "terrorist" mites is not prohibited due to a legal loophole which allows scientific trade in wee supremacists. There are calls for outlawing the meat-eaters by closing the gap in the anti-terrorism bill before Congress. But scientists say how dare you spit in our nanodeath soup. It notes that offshore spread is Commerce regulated. ------------- There are very good reasons for keeping this legal loophole. How could one ship, say, Ebola virus for evaluation if it wasn't there? Besides which, E. Coli (the workhorse of prokaryotic genetics) can be a pathogen if the right plasmid is inserted. Banning shipment, buying, etcetera of strains of it would rapidly reduce most genetics work in the U.S. to the state of gene therapy work in Switzerland (i.e., none, due to the Swiss laws outlawing any form of it). Incidentally, thanks to the person who quashed the "black-seeking virus" idiot. Human races are so far from being proper genetically distinct subspecies that nobody competent would call them that, if they only weren't us. -Allen

1 0

SecurIDs (was Re: Australian "calculatorcard")
by vin＠shore.net 17 Dec '03

17 Dec '03

amp <Alan.Pugh(a)internetMCI.COM> described his SecurID: >> sounds like the card i use for remote dialup to certain non-public >> systems i use at work. it has a six digit number on the front that >> changes every 60 seconds. David Lesher <wb8foz(a)nrk.com> asked: >Do these card systems use a window to handle clock-slip? SDI's ACE/Server or ACE access control module (ACM) has a Progress RDBS built in which maintains a constantly-updated historical record of the _relative_ drift in a particular token's clock-chip, relative to the clock in the server or host. When it receives the first identifier from a user (Name) submitting a SecurID authentication call, the server checks the database for the recorded drift and then predicts what that particular token will use as Current Time. CT, together with a token-specific secret key, is then hashed to generate a token-code which is matched with that submitted by the user, together with the user's memorized PIN. >I'd think you could have the server safely accept # N, N-60 sec, and >N+60 seconds; and adjust the server's idea of your card's clock speed >from that. You have it almost exactly right (or, at least, that's how SDI's ACE/SecurID system handles it;-) SDI throws in a couple other factors: the ACE system handles Current Time in 30 or 60-second blocks (depending on the model of SecurID token being authenticated,) so it needs a little leeway to handle a token which, because of drift, slips into the next time-slot or the one behind. The ACE system actually pre-calculates three token-codes -- each a pseudo-random number, so one will not inform your guess of another -- as it waits for a user's incoming authentication call to be completed. The server will approve access if it receives a token code generated from either its _projected_ Current Time (for this particular token,) or the token-codes generated from Current Time plus or minus one time-slot. When the ACE database indicates that this particular SecurID token has not been used in the past 60 days (many sysadmin make this 90 days) it also kicks in a search mode to minimize the false rejections. In search mode it calculates a series of prospective card-codes, sweeping out to a maximum of 10 time-slots (the actual scope of the search is defined by the sysadmin) fore and aft of whatever the database suggests this token should consider Current Time. If it finds a match between the token-code submitted from a long-unused SecurID and one of those calculated by the server in search mode, it updates its database projection for the drift of that particular token and then requests the use to submit another PRN token-code. A search-mode "match" alone will never result in a user being authenticated -- it only sets him or her up for a second formal authentication cycle where a new PRN card-code is matched against a new set of three token-codes. There are also a number of additional security devices and rules which the server enforces to protect against security threats, racing spoofs, stolen PINs, stolen tokens, etc. The most obvious is a secured record of all incoming authentication calls, recorded by token-code and GMT time. All incoming authentication calls are checked against this file. A SecurID PRN token-code is never accepted twice, and the virtual "time-stamp" within an incoming SecurID token-code must always be later and in proper sequence to all other recorded authentication calls. > >What new risk would that create? If the SDI hash algorithm is of sufficient strength, very little, I would think. (SDI just asked me to create an FAQ for their SecurID, so all queries are welcome -- on-line or off.) Suerte, _Vin Vin McLellan +The Privacy Guild+ <vin(a)shore.net> 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>

1 0

(NOISE - LONG) Re: PLA_gue Germ Terrorism
by jonnyx 17 Dec '03

17 Dec '03

Crypto relevance: absolutely none! Good lord, what nasty reactions! Maybe there's hope for us after all. I'll allow myself one reply. Sorry 'bout the length. < snip re: my bits on targetting specific genetic traits > zinc wrote: > this is so much shit. targetting anything is very difficult. > just ask all those people about the wonders of gene therapy. > hell, even the economist had an article about it's failures > recently (Dec 16-22 1995, p77). Putting a person on the moon was considered impossible by most folks 50 years ago. The German v-series rockets were cutting edge technology. Now licensed hobbyists can buy solid fuel motors that are just as powerful some of the ones the Nazis had (source: _High Power Rocketry_). Things change. > in any event the so-called 'differences' you are imagining > are phenotypes. these are a long cry from DNA. i'm not > aware of any genetic markers available to distinguish a > black man from a white man. and, even if there were, > recombination requires long stretches of homology between > DNAs, not small differences. i'd bet it's nearly impossible > to target black vs white vs yellow vs a gorilla. Good. The article I read that suggested the possibility (I'm pretty sure it was in _Science_ or _Scientific American_) was rather spooky. I wish you'd said FLATLY impossible, though. I'm (obviosly) not a biologist/geneticist/whatever, but aren't there bugs that go after only chimps? And didn't that ebola strain in Virginia only go after the lab monkeys, not the people? ...and from Jim Choate: > Malarky. < snip > > Most of the threat of this type of experiments are from simple > infections since viruses are not easily raised with this form > of equipment. People will have access to more and better equipment, though. > One of my favorite 'technology rulers' is when the first strain > of commen yeast is released which produces THC or LSD. Heh. Guess they'll have to post extra guards at the Wonder Bread plant, eh? Woudn't want terrorists dosing little Jimmy's lunch. < interesting stuff snipped > > I do not believe we will see this in the near term using the > micro-manipulater systems which do direct injection of genetic > material because of the cost and utility requirements of such > equipment. Which will probably become simplified, streamlined, and cheaper. Who knows what techniques will be used 20-50 years from now? Even though (fortunately) it seems that this kind of virus would be much tougher to produce than I thought (if not impossible), I can still see someone trying it and infecting EVERYONE in his neighborhood/city/state. And if it is possible, well, I'd rather have the idea explored and cures developed (with the info available to all) before any would-be Hitler surprised us. Finally, from E. ALLEN SMITH > E. Coli (the workhorse of prokaryotic genetics) can be a pathogen > if the right plasmid is inserted. > Incidentally, thanks to the person who quashed the > "black-seeking virus" idiot. Not my idea (I'm not that twisted; I find the idea horrifying). I read the suggestion in either _Science_ or _Scientific American_ (early 1993?). Incidently, the idea was a virus that went after people with specific racial traits, not a "black-seeking virus". Don't attribute me with quotes that aren't mine. I have enough problems with idiots who assume I'm a racist KKK country-music loving redneck simply because I'm from Nashville. > Human races are so far from being proper genetically distinct > subspecies that nobody competent would call them that, Guess what sunshine, they still teach this in mid- and high-schools. Hell, even my dictionary sez "race - 1) a division of the human population distinguished by physical characteristics transmitted by genes." (Webster's II New Riverside Dictionary, if anyone cares) > if they only weren't us. Huh? Now back to our regularly scheduled crypto (yeah, right). -- || ______ || comments, criticisms, and/or death-threats may be sent to: || || \__ /\ || jonny anonymous, c/o jonnyx(a)edge.net || || __/ / \ || or snail-mail pobox 23001, nashvegas tn 37202-3001, usa || || \__/_/\_\ ||______"DRIVING DRUNK ON THE INFORMATION SUPERHIGHWAY!"______||

1 0

put me on the list
by Basspunx＠aol.com 17 Dec '03

17 Dec '03

i would like to be put on the cypherpunks mailing list

1 0

Re: For the New Year: A Symbol for Information Freedom
by groundfog＠alpha.c2.org 17 Dec '03

17 Dec '03

In talk.politics.crypto, ptupper(a)direct.ca (Peter Tupper) wrote: > A Symbol for Information Freedom > by Peter Tupper <ptupper(a)direct.ca> > 1996 is off to a discouraging start when it comes to the >future of information freedom. The American Congress seems >determined to impose censorship on the Internet. The legal >status of strong dual-key cryptography is still in debate. >Telephone companies, cable TV services and publishing services >are all eagerly trying to seize control of the Internet and >eliminate the many-to-many nature of the medium. The accidental >wonder that is the Internet seems to be threatened on all sides, >in danger of being destroyed or denatured before reaching its >potential. > My proposal is only a small contribution to the solutions to >this problem. I believe a symbol is needed; a simple yet >recognizable item that will communicate to others that you are: > -for freedom of speech and expression in all realms, >particularly via computer mediated communications. > -against the imposition of arbitrary community standards by >centralized authority on communications. > -for making access to communications available to everyone. > -against the violation of individual privacy by wiretapping, >intercepting computer communications, compiling dossiers by >government or commercial organizations or other forms of >surveillance. > -for making strong, dual-key encryption programs without >back-doors available to the public. > -against building surveillance measures into communications >and financial infrastructures. > -for a future of communications that is by, for and of the >people, not the state or the market. > The symbol I have chosen is the paper clip. Why a paper >clip? > There are many reasons: > Pragmatic: Paper clips are readily available for >practically nothing, all over the world. They can be applied to >collars, lapels, scarves, pocket edges, suspenders and neck ties >without damaging them and without risk of the pin breaking the >skin. > Aesthetic: The paper clip is a simple, elegant design that >is easily recognized the world over. It can be rendered in many >colors or plated with precious metals. > Symbolic: The paper clip is a simple but effective piece of >technology. An individual uses it to bundle together documents >from disparate sources to create a unified document upon a given >subject, which may be dismantled and remade for another topic. >Furthermore, a paper clip may be bent out of its regular shape >and used as an improvised tool for any number of purposes. > Historic: During the German occupation of Norway in World >War II, Norwegians wore paper clips on their collars as a sign of >solidarity against the invaders. > Commercial: While anybody can obtain a plain paper clip >with little trouble, funds for Information Freedom can be raised >by marketing electroplated or designer paper clips. > The cause of awareness of and activism about AIDS had a >simple, readily recognized symbol, the folded red ribbon. Just >as every celebrity who wears a red ribbon, no matter how trite >and self-promoting it is, is a reminder to those watching that >AIDS is happening and that many people are concerned, >celebrities appearing at the Academy Awards or Grammies with a >designer, gold-plated paper clip on their outfit reminds the >world that information freedom is under fire and that people are >concerned. It will make the Internet community a visible reality >in the public sphere. It will bring these issues into the public >eyes, and give those involved a rallying symbol. It will make a >small difference, but it will contribute to the greater good. > Advertising couldn't hurt.

3 2

(fwd) e$: Looking down, not up, to the future
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Sender: e$(a)thumper.vmeng.com Reply-To: rah(a)shipwright.com (Robert Hettinga) Mime-Version: 1.0 From: rah(a)shipwright.com (Robert Hettinga) Date: Fri, 29 Dec 1995 15:07:53 -0500 Precedence: Bulk To: Multiple recipients of <e$(a)thumper.vmeng.com> Subject: e$: Looking down, not up, to the future -----BEGIN PGP SIGNED MESSAGE----- e$: Looking down, not up, to the future 12/29/95 First a little administrivia. Going forward, I'm going to be posting my rants here first at e$(a)thumper.vmeng.com, with a forward from e$ of the given rant, after some arbitrary delay, to any other lists that might be appropriate to the subject. My sponsors have paid for this list, and the readership of the e$pam and e$ are there to hear what I and others have to say about e$ and its consequences here, and so my stuff goes onto the e$ list first from now on. Like all my writing on the net, redistribution with attribution to me and the other people I cite (When remember to cite them all...) here is just fine. If you're publishing it, and you pay your authors, I'd like to be compensated too, of course. Not that what I say here is going to be all that earthshaking, but I thought I'd clear the air a bit. I've read a lot of interesting things about the future of the net in the last few weeks, some of which I've sent on to e$pam, and I'd like to talk about them, by way of clearing the decks for the New Year. First, I'd like to go revise my model of net.reality a bit. Most of people look at the net as a hierarchy. Architecturally, it is exactly that, from the IP addressing scheme, to the object super-hierarchies in component software models, to server-mirroring, to just about any kind of structural component of the net you would care to look at. Physically, big lines get broken up by big switches into smaller lines which get broken up by smaller switches into smaller lines, in a fractal process which ends up at you or me, where it goes back up each larger level to get where it needs to go. In software, the CORBA object model, and the super-object-model that the research people have been cooking up at Microsoft, all have a "root" somewhere; the "top" of their taxonomical system, if you will. In information, there's a source of the information, and it gets accreted with other information and synthesized and averaged and summarized and rolled up into some larger aggregate which allows you to have some knowlege about that information and other information like it. In finance, my money gets pooled with other people's money through several larger aggregation layers and then invested or spent centrally somewhere. The recipient of capital or cashflow then spends or invests it in fractally smaller chunks until I get it in a check for something I do. I could go on and on with this, but you can see my point, and it is the same point Rich Lethin loves to use on *me* when I start talking about "geodesic" anything, that is, the idea that Moore's law exponentially collapses switching costs, making nodes cheaper than lines, making the network and the software processes mapped onto it more geodesic instead of hierarchical, and "surfacting" information and software into fractally smaller and smaller pieces. What I've been saying to Rich, particularly when I talk about geodesic networks, is that the message itself is point-to-point, even though the actual electrons may flow more or less hierarchically around the network. That's kept him busy while I made my getaway. It always felt like a sophistic shuck, myself, but I'd learned to live with it until now. I don't know if I've gotten anywhere, but I've been thinking about it a bit, thrashing anologies from other parts of the world, --the major way I think, unfortunately -- to describe what I see out there. I've been thinking about biological models, because in my stranger moments, I like pretend that the net is an electro-biological entity. For instance, the circulation of blood is a good anology, I think, because all the endocrine messages in the blood stream are ultimately broadcast from a single cell and paradoxically sent point to point to another cell -- just like things are on an ethernet wire, or on Gilder's fanciful dark fiber, even though the circulatory "backbone" is hierarchical. The most obvious example of course is the organization of neurons, in that the brain pathways are essentially geodesic, but we still have to deal with the hierarchy of nerves outside of the brain. The one thing I think that differentiates these models from the hierarchies we encounter in social life, the industrial induced control hierarchies we all rail against, and the stuff I like to quixotically do battle with on the net, is that every one of those biological hierarchies is chaotic. There is no pretense of top-down control of the system. The load of the system is hierarchical, and so the system organizes itself hierarchically. There are physical forces which create physically hierarchical stuctures, but they're usually set up to solve the problem of efficient distribution of something over a distance, like draining a watershed, or getting blood to a central heart and lungs, or nerve impulses back and forth to the brain. When distance isn't a problem, networks, like the brain, tend to get more geodesic. Bandwidth is maintained by an abundance of neuronic "switches", doubling as processors, tripling as memory, each with some number of connections to other neurons, rather than a bunch of "fat" nurons doing all the signal processing. As an exception which proves the rule, note there *are* in fact "fat" neurons, more precisely redundant neuron pathways, particularly between the two halves of the brain, and between the brain and the rest of the body. So, what else is new? We still have hierarchies on the net, right? We're about to bump up by many orders of magnitude the number of possible IP addresses real soon, so that someday your toaster can tell your alarm clock to wake you for breakfast. I've ranted, tounge-in-cheek, about the "dangers" of the "X.blabla" book-entry view of the world, with hierarchical, government-as-root certification "authorities", and the consequences of having an audit trail on your every net-based financial activity. Most of this X.blabla stuff will come to pass, mostly because it's the easiest thing for the financial system as it's currently organized to do. It's sort of like financial "shovelware", moving the contents of one financial medium, the hierarchic industrial paradigm of government regulated central banking systems onto the new medium of the internet. However, in a world of micro-pay-as-you-go packet routing, where routers may someday spot-auction their bandwidth on a demand basis at packet prices displayed best in scientific notation, all those audit threads could lead to a Gulliverian restraint on personal freedom, much less on individual privacy. Fortunately, I don't think that's going to happen, because those same Lilliputian audit trails will just get in the way and slow the system to a standstill. We need to get more chaotic. I think my contention on this is that as we get smaller and smaller, the more chaotic it's going to have to be. Book-entry based transaction processing systems will choke on their own accounting at those levels. To look at the extremely-hypothetical router above, it will be easier to attach some digital bearer microcertificates to an information packet, so that the packet pays its way through all the routers it needs to go to, than it will be for some giant book entry system to account for it all. People have said that those microcertificates could work like stamps, where the first router cancels the stamp and pays back the other routers in the route some fraction of the "stamp" price to be settled later, or it may be possible to simply endow a packet with all the certificates nessary to get from point to point in a network someday. It kind of reminds me digital cash-as-processor-food, a bit. Note that this kind of bio-economic thinking is not new, the Agorics folks and Stewart Brand have been talking about this stuff for quite a while. My point here is that "down" the network, not up, is the place to look for the interesting stuff in the future. There are several interesting micropayment certificate systems out there, and there will be more. As software gets smaller and smaller with component architectures like OpenDoc and its eventual successors, it will be more and more economic to charge rediculously smaller and smaller amounts for rediculously smaller and smaller network behaviors. Just wait until someone figures how to get software to really "evolve", or gets software to write other software on a practical basis. Most of the people I read, on the net or off, don't see this. They're looking "up" the net, how connections are made up, at the level of the grosser network features, like how monolithic corporations, or book-entry database and financial control systems, or government regulations, will happen on the net. How the net will integrate itself with the "real" world they're familiar with. 8 years ago, I used to talk about people who lived "on" microcomputers versus the ones who lived "in" them. I used to say that Macs were more for people who lived "in" computers because they weren't hindered by the mechanics of the interface so much. I think that there are still a lot of mainframe-cum-client/server folks out there who still live "on" the net, and not in it. Those are the people who are looking "up" at how the "big" players will behave, when they should be look at their feet, where the real action is. Where the very ground is in the process of dissoving out from under them. Cheers, Bob Hettinga -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMORJaPgyLN8bw6ZVAQG+WQP/X4j2qn9tnhDoJKdqctxBCoQzH4F//kKc zsau7Cxs49XGHAaoZo2Pk2svU79FWG7HyWsm0VAPR9ezHiWf8W/Tyi1NgxCkNwjo 62HFNsE0U6Rfo0Itd26WuICe9aC2SG5J6tX8+MzJZqHzzx2xhBUNPKFqt/ZwVtFZ KNLAGkM/7Hg= =jc3o -----END PGP SIGNATURE----- -------------------------------------------------- The e$ lists are brought to you by: Making Commerce Convenient (tm) - Oki Advanced Products - Marlboro, MA Value-Checker(tm) smart card reader= http://www.oki.com/products/vc.html Where people, networks and money come together: Consult Hyperion http://www.hyperion.co.uk info(a)hyperion.co.uk See your name here! Be a charter sponsor for e$pam, e$, and Ne$ws! e-mail rah(a)shipwright.com for details... ------------------------------------------------- --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "Reality is not optional." --Thomas Sowell The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/ >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

The F.C. flamewar
by Jeff Simmons 17 Dec '03

17 Dec '03

You know, if I worked for an organization that was dedicated to restricting strong crypto, eliminating people's privacy rights, monitoring and recording everything that people say or write, etc. etc. ad infinitum, I'd probably spend at least a part of every day sitting in front of my computer in my little cubicle somewhere in Virginia, making posts to cypherpunks just like these ... -- Jeff Simmons jsimmons(a)goblin.punk.net

1 0

SHATEST (was: Re: DOS - MD5 - Thanks)
by wlkngowl＠unix.asb.com 17 Dec '03

17 Dec '03

On Fri, 29 Dec 1995 15:22:46 -0700 (MST), you wrote: I've got a little goodie called SHATEST which I'm going to include with the next release of the NOISE.SYS driver.. it's the Secure Hash equivalent of MD5SUM... (Originally written to test the optimized SHA code-- much thanks to Colin Plumb, BTW--- for the /dev/random driver...) --Rob >A freestanding implementation of MD5SUM (compiled from that in the PGP >distribution) for DOS is at >ftp://ftp.csn.net/mpj/public/md5sum.zip and on the Colorado Catacombs BBS >at 303-772-1062. >I suggested to Phil Zimmermann that he should put this in the next PGP >release along with the compiled DOS version of PGP, but there hasn't been >a new release of PGP since then. >Happy New Year! Ditto... >Mike Johnson >mpj(a)exabyte.com >#include <std_disclaimer.h>

1 0