December 2003 - cypherpunks-legacy

Re: [ecash] Re: Multi-issuer questions
by daw＠boston.CS.Berkeley.EDU 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have to admit I don't know the ecash concepts well enough to respond very intelligently to everything you talked about, though I'd like to address one of your comments on inter-bank clearing. I wanted to bring up one misconception: you mention that the main worth of ecash is measured by whether merchants will accept it as payment, and that whether a bank will accept it as a deposit is just a secondary issue. From this you conclude that so long as a merchant can validate ecash (via online clearing, to detect double-spending), it doesn't really matter whether that merchant's bank will accept the ecash -- just that other merchants will accept the ecash. This is brought up in the context of "what if Bank B didn't accept [deposits of] ecash from Bank A?". I claim that this is at best misleading, because with Digicash's ecash, when a merchant receives ecash as payment, the ecash is "made out" to that particular merchant, and is non-transferable-- i.e. can't be used as payment to another merchant. When you've been payed Digicash ecash, about the only interesting thing you can do is deposit it with your bank. [ For simplicity, I'm ignoring wildcards in the "pay to" field; but wildcards are insecure on their own. Digicash hasn't really attempted to support wildcards or transferable ecash in general, as far as I can tell. Correct me if I'm wrong. ] - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMOYZwCoZzwIn1bdtAQFvaQGA1f4oy6Z2TF9810fIUEqkktpQN01FPUCb ER/q3WI/kuyjQCBJh/laA0QsU2q8jnP4 =8Mib -----END PGP SIGNATURE-----

1 0

RE: last straw (or Possible Developments re Censorship)
by blanc 17 Dec '03

17 Dec '03

From: Dr. Dimitri Vulis And now comes the *point*: There's much information on CompuServe that cannot be accessed from the outside. One example is the very informative National Computer Security Association's forum. ...[etc.] ................................................................................................... Aside from the obvious implications to liberty, of the backing down from standing up (!) to the demand for self-censorship, I was thinking about other possible developments: Since, as 'Dr. Dimitri' mentions, CompuServe offers some info which is not available from other sources - and this info is often quite useful/valuable to business enterprises, such that they and other individuals would not be too keen on abandoning these immediately just for the principle of the thing - it could develop that those who are willing and can afford it, will end up "supporting", or getting services from, different providers based on the particular services which they offer. This could represent a partial solution (in my mind, at least, not being inclined toward blanket censorship of all things discomfitting to my sensibilities) to the matter of there being free-radical electrons "out there" existing in the form & shape of various degrees of sexual permutations: . Those concerned that their children may innocently surf over to alt.binaries.naughty.nude.x-rated.pictures and see alarming truths about adult behavior, and don't want to purchase the available filtering software, could subscribe to CompuServe and rest assured that their children would only have access to safe, industrial-strength info on that account. . Those wishing want to discuss their sexually-related personal problems, or who are pleased to just look at/talk about sex et al, could continue do so through their subscription to the adult bbs-es or local ISPs providing uncensored access to all newsgroups. It could develop that large companies providing internet access will seek to distinguish/identify themselves (as they are tending to do already) between the pablum-feeding family-types like AOL, or corporate/business-types like CompuServe, or free-for alls like local ISPs. Such developments of course would depend on a tolerance for the existence of those un-specialized carriers which aren't adverse to transmitting controversial, "sensitive" content. These divisions among services might still not be acceptable to States and Nations & other 'busybodies', but the resistance to such developments would only serve to more explicitly define the problem; it could make prominent the real issue of people's attitudes, fears, and expectations concerning sex & human nature, and of the obstacles in the way of achieving personal responsibility regarding these (among other things). .. Blanc

1 0

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

17 Dec '03

> > And the cypherpunk relevance is....<drum roll>...? > >[...] linux kernel stats Absolutely zero. Your's truely pressed the wrong key. --Proff +----------------------------------+-----------------------------------------+ |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

Compuserve and copyrights
by Ed Carp [khijol SysAdmin] 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have sent Compuserve a notice that all posts originating from this site are copyrighted and barred from being stored on a site that does not allow reciprocal access. I would urge that other sites consider sending a similar notice to Compuserve. - -- Ed Carp, N7EKG Ed.Carp(a)linux.org, ecarp(a)netcom.com 214/993-3935 voicemail/digital pager 800/558-3408 SkyPager Finger ecarp(a)netcom.com for PGP 2.5 public key an88744(a)anon.penet.fi "Past the wounds of childhood, past the fallen dreams and the broken families, through the hurt and the loss and the agony only the night ever hears, is a waiting soul. Patient, permanent, abundant, it opens its infinite heart and asks only one thing of you ... 'Remember who it is you really are.'" -- "Losing Your Mind", Karen Alexander and Rick Boyes -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMOYi1SS9AwzY9LDxAQFdagP/VMdunjZ1LLY7nUVgxUgFEoHDdcyPwWLl oPTQ/jDdcsIfolBQlNp+IzKJyubutW7oUv0qmsInAlXBUDPGvTmgyhPVczud7U79 JQh/ssxCiWZbTHwwwpJyg8Iw+jjAvrNTe4sWh/NOCM/Y3+knIckEm8k5DXA3BTCV 0+fkcV6sf+o= =dQU8 -----END PGP SIGNATURE-----

1 0

Re: Australian "calculatorcard"
by Johnathan Corgan 17 Dec '03

17 Dec '03

>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. the card is registered to me. when i enter >my username/password i'm prompted for the number. it's Pretty Good >(tm) security, but like anything not biometric, it is vulnerable to >black-bag attacks. physical possession being all that is required. if >you know the algorithm and the serial number of the card and the >time, even that isn't necessary. > > >CG> Can anybody provide me with pointers to more in-depth information >CG> about this device and the algorithm(s) behind it ? > >i don't know if there are any net sources for them, but i'd be >suprised if not. my card references "security dynamics" of cambridge >massachusetts. You are referring to the ACE/SecurID token card from Security Dynamics. In addition to the displayed number, you should be prepending it with a memorized PIN; this prevents operation in case of theft. The server end will disable the card after x failed attemps, etc. Otherwise it is basically a one-time password system. I've had a business relationship with these folks for a year or so now-- sharp guys.

1 0

(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

Can We Cut the Crap?
by tcmay＠got.net 17 Dec '03

17 Dec '03

Really, the S/N ratio is approaching all-time lows, even for the Silly Season of Xmas. A week or so ago there was a massive flame war involving insults and counter-insults--I returned from my Xmas vacation to find the list melting down. Now, a week later, a new flamewar has erupted. There is no point in the back-and-forth of insults, "Dr. Fred is a loon," "Alice is Detweiler," and other such nonsense. If you don't want to read the comments of Fred Cohen, Dimitri Vulis, Alice whatever, Vlad/Lance/Larry/Pablo, then just don't read them! Filter them out, delete them immediately, read them briefly, whatever. At 5:04 PM 12/31/95, deadbeat wrote: >Regarding Fred Cohen, PhD: > [typical personal insults elided] >Let's also consider the granting institution, a second-rank school. Well, not quite. I seem to recall that Cohen's advisor at USC was Len Adleman, known perhaps to some of you as the "A" in RSA and more recently as the guy doing the "DNA computing" work. He was also working on viruses, perhaps in conjunction with Cohen, as of 1987-88, and gave an interesting paper at the 1988 Crypto Conference on "An Abstract Theory of Computer Viruses." Not surprisingly, Cohen's papers were the main citations. I recall Adleman describing in the oral talk just how it is that determining if a given program contains a virus is essentially equivalent to solving the halting problem, i.e., it may be undecidable whether a program has a virus, except presumably in some special cases (e.g., for very small programs). >Cohen's thesis broke new ground, but how many people have read it, or any of >his writings, or know anything about his ideas beyond a single word? How far >did he carry this work? Where are the conference and journal papers? Cohen's >reputation faded into obscurity long ago. Now he is building a new reputation >as a pig-headed loudmouth, threatening his "defamers." Shades of Sternlight. I have plenty to disagree with some of what Fred Cohen says, as I do with many people, but this is just plain ignorant. "How many people have read it, or any of his writings..." is a ridiculous argument, even for an ad hominem. Those who want to read it, can read it. The articles are readily available. I've even seen some of his books on the bookshelves of my local bookstores (haven't read them, though I flipped through "It's Alive!" and didn't see much of interest....but how many of us have written _any_ books?). I'm not convinced there's much more about the _theory_ of viruses to "push forward," for various reasons. The theory was laid out, some Bulgarians and others are busily writing viruses, but there's not likely to be some whole reservoir of new theory to be worked on. (This is true of a lot of fields, where the work done decades ago basically was complete....look at how we all cite Garey and Johnson and how little has changed in the field of NP-completeness.) Blasting Cohen because you don't think he carried his work far enough is clearly blasting wildly. Have you asked whether others on this list have carried the work they did in their early careers far enough? (Did I carry my work in the 1970s on alpha particle effects on chips far enough, or am I just a Cohen-like slacker because I moved on to other things?) Anyway, if you don't like Sternlight, or Cohen, or May, or Detweiler, or Metzger, or Vulis, *filter* them out! So why don't I just do this? Well, I do have a filter file in my Eudora Pro mailer, and I use it. But I still see the crossfire on the list, the pointless flames and personal attacks. This angers and saddens me. Hence this message. While I don't subscribe to the extreme view espoused by some, that the topics of the list should be exclusively crypto, math, programming, and Internet standards, I do think people should try to find some relevance to the larger themes of the list. The recent increase in "one-sentance repartee" is indicative of late-stage list meltdown. (Some of the posts here quote a couple of paragraphs, add one or two lines of insults, then have another screenful of PGP sigs, auto-signing sigs, anonymous IDs, and then a conventional sig. Jeesh!) I'm hoping that this is just a Xmas vacation silly season. --Tim May We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

4 7

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