- cypherpunks-legacy - lists.cpunks.org

Re: Corrections about Bob Noyce and Intel
by John Young 17 Dec '03

17 Dec '03

Worth magazine of Dec/Jan has a lubricious article on "The Super Investors of Silicon Valley": " 'Rise of the Silicon Patriots,' by Donald Katz. If their egos and paychecks are oversized, so is their impact on the economy and culture. It's not for nothing that California's venture capitalists think they're at the center of the universe." It traces some of the mauling by rapacious VC tigers of unwary techno-bambis and gleefully vaunts winner-take-all when the chips are down (multiple puns there) -- commensurate with the flatulent flattering flummoxing of this "financial intelligence" oilslicker. For more FFF FinInt organ-grinding the monkeys, see "Downloading Warren Buffet's Brain."

2 1

Re: credit card conventional wisdom
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Alice here ... On Thu, 16 Nov 1995, Vladimir Z. Nuri wrote: > but one distinction I do realize has to be made in all this is the > difference between "fraud" and "breaking a system". the latter is > a far more potentially serious problem with cryptographic security than > the former. in fact cryptographic security attempts to deal with all > fraud by making "breaking the system" impossible, and succeeds to the > degree it accomplishes this. I think this is extremely important to consider. The functions which define relationships between large numbers of variables, (such as say the world economy) -- these functions are not "idiot proof". They can collapse. And, yes Virginia, the system can be "broken". To suggest that cryptography can address this issue is to misunderstand the problem, and is part of this whole mindset that "security" is cryptography. Our economies are, if anything, less resilient than they were in the not to distant past. They are far more vulnerable. The introduction of new business practices, such as the reduction in most firms inventories, and the ever greater reliance on "just in time" approaches has made us far less able to sustain any interruption. The headlong introduction of "new variables" and new vectors into an unstable system has never been "sound policy". I guess it's sort of like what happened when rabbits were introduced into Australia. An eco-catastrophe. Perhaps, we can all agree that existing systems are best "not destabilized". Then again, I'm not the one who gets his jollies by rocking the boat. I get mine elsewhere. I guess here then is the real question, what is the fallback plan when something does go catastrophically wrong?? What then, hand-wringing, and saying that it "exceeded our theoreticians predictive capabilities" just does not suffice. Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: credit card conventional wisdom
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Alice here ... On Wed, 15 Nov 1995, Howard Melman wrote: > Vladimir Z. Nuri wrote: > > attempts to get secure credit card number transfer on the internet are > > not an end in themselves. they are the first steps toward an entirely > > new transaction system. those who see a single step and criticize it > > as feeble in the context of past systems are missing the point and > > apparently can't think past the present nanosecond of their lives. My grandfather used to say, that the first horse to break from the gate, isn't necessarily the first to cross the finish line. Often, he'll be pulling up the rear. > You'll have a hard convincing folks that they need something > better than what works perfectly well today. In my humble opinion, the present system can't really be characterized as "working perfectly well". Far from it. While not as familiar with the US system as the Canadian, I can give as a simple example, the bank clearing system for paper checks. In Canada, we can clear a check from one side of the country to the other overnight. We have 24 hour clearing. While this is far from "perfect", our existing paper systems allow for a degree of efficiency which I don't believe is engineered into the US clearing system. Perhaps someone can correct me, if I have erred but I think it takes far longer than 24 hours to clear a check drawn on any US bank, and deposited to any other bank's credit in the United States. It may work "functionally" ... but certainly far from "perfectly" nor "efficiently". > Here's another point that I didn't see in your list. Today it might be > just as safe to send your CC# over the internet as giving it to a clerk, > etc. This is mostly because the number of CC#'s sent over the net vs > the whole traffic is small. It is therefore not very cost effective to > try to steal credit card numbers over the net vs other means (searching > through dumpsters, taping a phone line near LL Bean, etc.). A very good point. But then, dumpster-diving attacks could be moderated by simply implementing carbonless forms. No carbon, reduces a lot of the risks. It's basic risk management. All of this becomes a part of the cost/benefit analysis, and is part of the function of security policy. It's very much like all the talk on another thread on this list about Java security. There is no point in even discussing Java security in Netscape, when Netscape PRESENTLY has existing security holes written into the very fabric of the existing installed codebase. Holes which Netscape and AT&T refuse to address, correct or even comment on. Sun's security approach misses the point. Putting dead-bolts on houses while leaving all of the windows open, just doesn't address the problem. It really misses the mark. > If CC# purchases became common over the net, it would become much more > valuable to try to steal them from the net and more people would. It > would then become much less secure, not for any technical reason but > because there will be more crooks exploiting the existing flaws. This is also unfortunately true. Information on how to "break" a system does propagate. As more people know how to exploit a system, or as more people learn how to utilize the "letter of the rules" (the "code") rather than the "spirit" (the "intent") the degree of exploitation grows. Ask any executive in the Gaming Industry about this. Black-Jack card-counting went through an evolution in exactly this fashion. Many casinos lost a veritable "fortune" to good card counters. They lost to organized "teams" of card counters. Counters who literally broke the bank. Systems always have exploitable features. And new systems will always present new opportunities for exploitation. A completely new set of risks which are additive to those already in place, even those which may not yet be in a state of active exploitation. A pertinent network example: credit card numbers. Credit card numbers are not just a set of random digits. Only particular patterns of numbers can be valid. This existing "security provision" -- check digits -- actually ends up opening a security hole when we look at transmitting credit card numbers via the Internet. The security feature on one side of the ledger makes it far easier to differentiate between what is a random set of numbers, and what is in fact a valid CC number. Simple pattern analysis allows to search for valid numbers. It makes the potential "crooks" job much easier and its already engineered into the system. The "credit card number" risk though is accidental, while the Netscape Navigator risk isn't accidental at all, it's willful. Alice de 'nonymous ... ...just another one of those... ...hunters... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

50 attacks on Netscape - please send the check
by fc＠all.net 17 Dec '03

17 Dec '03

50 Attacks: a.k.a. Why Not to Run Hot Java in your netscape (or other) browser: Concept 1 - Hot Java code that, once started, takes and retains control of the viewer. It includes hot buttons, etc. that let you use common resources on the net, store favorite places, etc. When you push any button in this window, it simulates Hot Java within its own code, but all reads and writes contain code to restart the program (such as the "remember favorite places" button, etc.). Attack 1 - It records all entries and sends them to an unfriendly. This includes credit card numbers, etc. Attack 2 - It reroutes all traffic through a known site to record information about all of your accesses. Attack 3 - It selectively multiplies dollar values on purchases up by a factor of 10 when you authorize purchases through their store. Attack 4 - It reroutes all purchases through their intermediary and adds 20% for the service, thus becoming the middle person in all your transactions. Attack 5 - It replaces select information from select sites with false or misleading information - particularly about the competition. Attack 6 - It reports certain sites as down, thus damaging the reputation of those sites. Attack 7 - It sends requests to sites and ignores their answers to increase hit rates on key vendors that pay for their W3 sites based on usage. Attack 8 - It gets dirty pictures using your credit card information and sends it to another recipient. Attack 9 - It implements an anonymous remailer for smut, thus making you the smut capital of the network. Attack 10 - It waits till you save another Java code from the net and replaces the code with its own code and a pointer to the code you thought you got. Attack 11 - It waits till you save a file and overflows your disk with garbage. Attack 12 - It sends displays that flash on the screen at a rate that causes epilectic seizures. Attack 13 - It puts up subliminal messages to cause you to accept its subsequent request to overwrite a .com file onto your disk. Attack 14 - It analyzes your typing style to determine psychological factors and stores that information in a database. Attack 15 - It analyzes your typing style to determine psychological factors and, if you are a child, connects you to child pornography rings. Attack 16 - It sends requests for URLs to numerous addresses on your network, records results, and returns a network map to the attacker. Attack 17 - It uses spare time when you are not computing to participate in codebreaking activities, including the breaking of netscape codes. Attack 18 - It sends massive quantities of email to mailing lists creating the impression that you are not a nice person (a spammer) Attack 19 - When it recieves incoming email, it sends copies to newsgroups who now have access to all your personal incoming mail. Attack 20 - When you send outgoing email, it sends copies to newsgroups who now have access to all your personal outgoing mail. Attack 21 - When you send outbound email, it adds insulting or abusive humor to the end of your signature line. Attack 22 - It is used to send and receive email as part of a right wing group's coordination activities aimed at overthrowing the government. Attack 23 - It slowly fades your screen till you think the display is going bad, forcing you to buy a new display. Attack 24 - It slowly degrades performance causing you to think you need a faster computer. Attack 25 - It sends threatenning email to the President under your name, getting you arrested. Attack 26 - It sends embarassing email to the New York Times getting you fired. Concept 2 - Hot Java code that sends all of your messages through my computer and gets the results back from my computer by rewriting URLs on-the-fly. Attack 27 - Attack 3 from above, but with more intelligence so that amounts are changes less obviously. Attack 28 - Attack 4 from above, but it also changes the costs on incoming information so that you can't detect the price change in the process. Attack 29 - Attack 5 from above, except that it is more sophistocated - like creating misspellings or poor formatting or moving the locations in maps so that when you push on one part of a map, it sends a different part to ther server. Attack 30 - Attack 6 from above, except that instead of reporting servers down, it makes them seem very slow, or misses lines of pictures, etc. to make them look bad but without causing trouble reports. Attack 31 - Records all credit card transactions and forward information to services that pay to know what you buy. Attack 32 - Determines whether you look at dirty pictures and, if so, sends the information to criminals to use against you in shakedowns. Attack 33 - Replaces legitimate calls to children's pages with child pornography - including solicitations for where you can become a star. Attack 34 - Adds subliminal messages to sound files that cause you to enter a murderous rage (as in the claims about acid rock a few years back). Attack 35 - Adds dirty pictures to video files causing you to become sex-crazed and commit sex crimes and have bad dreams. Attack 36 - Causes simulated waviness on the screen, resulting in dizziness and increased sick time at work. Attack 37 - Introduces high frequency buzzing that irritates people and causes them to become more violent and less cooperative. Attack 38 - Introduces low frequency beating (similar to the tactics used against the Branch Dividians and in Viet Nam) to weaken your resolve and then asks you to confirm the upload of a program. Attack 39 - Creates subliminal feedback to your use of the Web to get you to tend toward particular services and away from others. Attack 40 - Adds background advertising to all your pictures. Attack 41 - Replaces the background information provided by Web sites with the attackers background advertising. Attack 42 - Shifts frequencies of sound files from select other sites so they seem off-pitch and don't reflect well on those companies. Attack 43 - Reroutes all of your Web requests through the NSA and CIA so they can do better intelligence. Attack 44 - Causes select Web sites to require User ID and Password information before use (particularly company Web sites) so as to get you to reveal your UIDs and passwords. Attack 45 - Renames Web sites so that your remembered sites only work for a few days and then the pointers appear to go away. Attack 46 - Puts a lot of really interesting things on your screen, thus making you believe that the Web is really great, and then removes them from accessibility when you try to get them again. Attack 47 - Universally replaces the work AND with OR in all Web information. Attack 48 - Randomizes all 5-digit numbers sent via the Web, thus confusing all zip codes contained in address fields. Attack 49 - Sends a series of high frequency sounds combined with screen flashes designed to cause permanent brain damage. Concept 3 - There is a chosen plaintext attack against the RSA (published in the 1980s in a Crypto conference (IACR?). Attack 50 - Use your Hot Java capability to sign selected message after message till the attacker derives your private key. I think this takes one or two messages per bit of private key. Bonus Attack (no extra charge) - If they use your PGP random number information, they get your PGP key too! Netscape: Please send your check for US$50,000 to the address below. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

6 5

Motherload of Crypto Site...
by frenchie＠magus.dgsys.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I hope that I'm providing some useful info here. I came accross this site in DDJ (Oct 95). A comprehensive amount of crypto stuff available. Crypto Stuff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Admiration, n.: Our polite recognition of another's resemblance to ourselves. -- Ambrose Bierce, iQCVAgUBMIVvH7bmxeO+s+1xAQHS+AP+ImrrqcHfBi6OGOyu5tSAhNHrpkvPE9E5 qh3e8TsFfbyxq1UXgz73FEFfalhs3GeZOgye5DKp0/vsTQ+ZwQyizKX0XhM/MsNT zFnv7B2uOACljwqjiMCc6ZiNA25nXveA+TMIa1sZkhTMtwHzVFogE7X4S91F2gBg Til3urgFAWU= =C/CT -----END PGP SIGNATURE----- =====================PGP Encrypted Mail Preferred======================== PGP Public Keys: 1024/BEB3ED71 & 2047/D9E1F2E9 on request. As soon as any man says of the affairs of the state " What does it matter to me? " the state may be given up for lost. J.J.Rousseau - The Social Contract GAT/E/O d++@>- H--- s: a29 C+++$ UL++++($) P+>+++ L++>++++ E W+++ N++ K- w---- O- M- V-- PS+ PE++ Y+ PGP+++ t 5+ X R* tv b++ DI++ D++ G++ e h+ r y++ [Geek Code v3.0] a.k.a [ root(a)magus.dgsys.com / vamagus(a)delphi.com] ==========================================================================

2 1

perl-RSA CJ request sent today
by Raph Levien 17 Dec '03

17 Dec '03

A number of people have been asking me whether I've gotten any response from the CJR yet. Well, I only sent it off today, because I've been so busy. I sent the main one priority mail, so I suppose the clock can be considered to have started ticking on the 20th, just in case anybody is keeping track. Raph

1 0

Media Accuracy
by Martin Diehl 17 Dec '03

17 Dec '03

In the October 16, 1995 issue of PC Week, Spencer F. Katt writes: >Isn't it ironic? Andreessen creates the WEB while in college; now >college students are finding all the holes in it. Two students have >uncovered a serious bug in Netscape Navigator, one Katt source >contends. The browser has a 2K-byte buffer for reading HTML >documents. Well, these tipsters found that once the page has sent >more than 2K, any assembly code in the HTML document will be >executed. As an experiment, these kids set up a simple Web server >with some assembly code embedded in the HTML page to overwrite the >client computer's FAT table [sic]. Sure enough, it worked. >spencer(a)pcweek.ziff.com He might be talking about the (already fixed) bug that allowed an HREF that is longer than 356 bytes to overwrite the stack. Hadn't heard here that anything would happen other than getting Netscape to crash. No names or URL's were given in the story. Maybe he needs an update. Maybe we need an update. Martin G. Diehl

2 1

Re: Mark Twain Bank ecash scripts needed
by Bill Stewart 17 Dec '03

17 Dec '03

At 04:25 PM 11/16/95 -0700, Bryce wrote: >I am in the process of setting up a shop using Mark Twain Bank >Ecash. Could someone please forward me the scripts to accept Ecash >(running on SunOS. On c2.org actually) and/or any advice you have http://www.digicash.nl/mt/ #-- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0663 Pager/Voicemail 1-408-787-1281

1 0

the beverage you are about to drink
by mrm＠netcom.com 17 Dec '03

17 Dec '03

All this netscape-bashing reminds me ... Doesn't anyone think it's sad-funny now that every styrofoam coffee cup has to be labeled "Warning The Beverage You Are About To Consume Is Hot!!" The reality is, we don't want to get burned. But the coffee is hot. So you try to have some reasonable compromise since lukewarm coffee is just not appetizing. Marianne mrm(a)netcom.com

2 1

Legal argument invalidates Merkle-Hellman
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

More on free public key crypto! The Hellman-Merkle patent claims to cover the entire notion of public key cryptography. The patent holders say that any scheme which has a private key that is computationally infeasible to derive from the public key infringes on the Hellman-Merkle patent. Here is a nice legal argument against that position. It is taken from the public record, direct from Roger Schlafly's motion for summary judgment, dated October 16th, 1995. Basically, the knapsack algorithm disclosed in the patent does not have the claimed property of computational infeasibility, so the patent cannot cover any system that does implement the claim. For example, if I submit a patent that claims coverage of all forms of cold-fusion to generate power, and disclose an invention that does not work, then those general claims are not valid. Someone who really does invent a workable form of cold-fusion gets to make the big patent claims. ---------------------------- 4. Hellman-Merkle is inoperative, hence invalid. 4.1. The Hellman-Merkle patent discloses a cryptosystem popularly known as the "trapdoor Knapsack system", or simply "knapsack". Ralph Merkle is credited with being the principal inventor, and he placed a $100 bet that it is secure. Being "secure" makes it useful for communications or authentication. 4.2. Time Magazine reported on Oct. 25, 1982 that the trapdoor knapsack had been broken, i.e., found to be not secure. Merkle had to pay off the $100 bet. IN patent jargon, the best mode was shown to be inoperative. The article is attached as Exhibit. CB. 4.3. Apparently unhappy with the article, but not denying his $100 payoff, Merkle wrote a letter to Time Magazine, published in the Nov. 15, 1982 issue and attached as Exhibit. CC. In this letter, he offered $1000 to anyone who could break the "multiple iteration knapsack" system. That system was the only alternate mode disclosed in Hellman- Merkle which was not shown inoperative by the work described in Time. Merkle recommended using two or three iterations. 4.4. Two years later, Merkle had to pay the %1000 to Ernie Brickell who broke the Hellman-Merkle trapdoor knapsack scheme with up to 40 iterations. The Diffie survey article cited above (AM. Compl. Exhibit. V) documents on p. 565-566 the failure of the Hellman-Merkle invention. (Note that Exhibit. CI recommends this Diffie article.) One of Brickell's articles on the subject, published as part of the proceedings of Crypto '84, is attached as Exhibit. CK. 4.5. Note that Exhibit. CD, a paper in the Communications of the ACM, a leading computer science journal, has an editor's comment that "the trapdoor Knapsack systems have been broken". This is a direct reference to Hellman-Merkle being inoperative. 4.6. The Hellman-Merkle patent is invalid and unenforceable because it is inoperative as disclosed. Claims 1-6 and 14-17 require a quantity computationally infeasible to generate from a public key. Claims 1-3 and 6-17 require secure communication over an insecure channel. There are no other claims. As documented above, it turned out to be feasible to compute the secret key from the public key. It follows that the claimed computational infeasibility is not achieved, and the communication is not secure. 4.7. PKP partners RSADSI and Cylink have known the Hellman-Merkle invention to be worthless since at least 1985, and have not used it in their commercial products. 4.8. As further proof of the failure of Hellman-Merkle, PKP is refusing to allow it to be used to protect their own trade secrets. There was a motion before the Court which hinged on this issue. In PKP's Reply Memorandum, PKP argues that protecting its trade secrets with Hellman- Merkle is tantamount to putting them in the public domain. Schlafly interprets this refusal as an admission that Hellman-Merkle is not secure. 4.9. The Hellman-Merkle invention is not useful because of the flaws explained above, and therefore fails to satisfy the 35 USC 101 requirements for patent protection. 4.10. In the alternative, Schlafly argues that Hellman-Merkle is invalid for reasons of nonstatutory subject matter. See arguments pertaining to the RSA patent below. Hellman-Merkle discloses more hardware than RSA, but none of it is novel, and all of the RSA arguments apply. The trapdoor knapsack system is described in Exhibit. CE, a Scientific American article by Hellman. It is readily seen to consist purely of mathematical formulas. 4.11. PKP may argue that the Hellman-Merkle claims are broader than the disclosed embodiments, and therefore the patent is valid in spite of the failure of the embodiments. This notion is absurd, and incorrect as a matter of law. Abstract concepts and ideas cannot be patented at all, and certainly not with an inoperative disclosure. 4.12. In addition, there is prior art on those abstract concepts. See the conference abstracts submitted by Diffie (Exhibit. CG) and Hellman (Exhibit. CH). These were published in June 1976. 4.13. In the Hellman-Merkle file history, the inventors argue that they are entitled to broad patent claims because earlier embodiments of public key cryptosystems in the prior art were impractical. If their invention is impractical, then it is no better than the prior art they criticized.

1 0