December 2003 - cypherpunks-legacy

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

Tales from Tech Support
by Chris Claborne 17 Dec '03

17 Dec '03

This is just one of the incredible "Tales from Tech Support" you can find on web page: http://128.218.7.140/auricular/homepage/tstales/tstales7.html Enjoy ! SuperMac records a certain number of technical support calls at random, to keep tabs on customer satisfaction. By wild "luck", they managed to catch the following conversation on tape. Some poor SuperMac TechSport got a call from some middle level official...from the legitimate government of Trinidad. The fellow spoke very good English, and fairly calmly described the problem. It seemed there was a coup attempt in progress at that moment. However, the national armoury for that city was kept in the same building as the Legislature, and it seems that there was a combination lock on the door to the armoury. Of the people in the capitol city that day, only the Chief of the Capitol Guard and the Chief Armourer knew the combination to the lock, and they had already been killed. So, this officer of the government of Trinidad continued, the problem is this. The combination to the lock is stored in a file on the Macintosh, but the file has been encrypted with the SuperMac product called Sentinel. Was there any chance, he asked, that there was a "back door" to the application, so they could get the combination, open the armoury door, and defend the Capitol Building and the legitimately elected government of Trinidad against the insurgents? All the while he is asking this in a very calm voice, there is the sound of gunfire in the background. The Technical Support guy put the person on hold. A phone call to the phone company verified that the origin of the call was in fact Trinidad. Meanwhile, there was this mad scramble to see if anybody knew of any "back doors" in the Sentinel program. As it turned out, Sentinel uses DES to encrypt the files, and there was no known back door. The Tech Support fellow told the customer that aside from trying to guess the password, there was no way through Sentinel, and that they'd be better off trying to physically destroy the lock. The official was very polite, thanked him for the effort, and hung up. That night, the legitimate government of Trinidad fell. One of the BBC reporters mentioned that the casualties seemed heaviest in the capitol, where for some reason, there seemed to be little return fire from the government forces. O.K., so they shouldn't have kept the combination in so precarious a fashion. But it does place, "I can't see my Microsoft Mail server" complaints in a different sort of perspective, does it not? ... __o .. -\<, Chris.Claborne(a)SanDiegoCA.ATTGIS.Com ...(*)/(*). CI$: 76340.2422 http://bordeaux.sandiegoca.attgis.com/ PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server.

1 0

Smoking gun invalidates crypto patent
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

Finally! Free public key crypto! Rumors have floated for years that Diffie-Hellman patent is invalid because it was disclosed more than a year prior to the patent application. But it was never clear if Diffie or Hellman actually disclosed (in the legal sense) the invention. It would seem that Roger Schlafly has found a "smoking gun." Through the legal discovery process, Schlafly found a copy of the "New Directions..." paper in the procession of an IBM researcher (Mike Matyas) with a stamped "received- by" date more than a year before the patent filing. This copy did not have any confidentiality markings or indications of pre-publication status. Since Diffie-Hellman pre-dates Hellman-Merkle (the Knapsack patent), no one can assert any infringement of anything for the use of Diffie- Hellman - it's free. The real beauty of the patent system is that a patent holder has to defend validity no matter how many times it's challenged. So even if Schlafly should fail on a technicality, anyone else, an unlimited number of times, can challenge this patent again. (Note: One may question whether Stanford lied to the patent office about this. That's fraud.) The following information is a matter of public record, direct from Schlafly's motion for summary judgment, dated October 16th, 1995. ---------------------------- 3. Diffie-Hellman is invalid because of a statutory bar. 3.1. The Diffie-Hellman patent application was filed on Sept. 6, 1977. According to 35 USC 102 (b), the patent is invalid and unenforceable if there was a public disclosure prior to Sept. 6, 1976. 3.2. A research paper by Diffie and Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, vol. IT-22, no. 6, Nov. 1976, was submitted on June 3, 1976. It discloses the secure cipher key generator of the Diffie-Hellman patent. A copy of the paper is Am. Compl. Exhibit. U. 3.3. A survey paper, "The First Ten Years of Public-Key Cryptography", was published by Diffie in Proceedings of the IEEE, vol. 76, no. 5, May 1988. A copy of the paper is Am. Compl. Exhibit. V. It states on p. 563 that the Am. Compl. Exhibit. U paper was publicly distributed in June 1976 and publicly disclosed at the National Computer Conference, also in June 1976. That conference was open to the public, and well-attended by experts in the field. 3.4. A true and correct copy of the "New Directions" preprint dated "August 1976" attached as Exhibit. CA. It contains a full disclosure of the Diffie-Hellman invention. Schlafly received it from the files of Mike Matyas, a cryptographer at IBM, on May 8, 1995. 3.5. Hellman also lectured on the subject at the 1976 International Symposium on Information Theory, Ronneby, Sweden, June 21-24, 1976. 3.6. The PTO was not informed of these prior art disclosures, as there is no record of them in file wrapper.

1 0

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

(buyinfo Req:) Stored value card alliances?
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Wed, 18 Oct 95 09:03:00 -0400 From: Mark <mark(a)bmainc.com> Sender: Mark <mark(a)bmainc.com> Organization: Bruce Morgan Associates, Inc. To: www-buyinfo(a)allegra.att.com Subject: <None> Would someone be able recommend a table listing all the various store-value card and digital cash strategic alliances? --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Re: Anonymity: A Modest Proposal
by David Neal 17 Dec '03

17 Dec '03

> Date: Wed, 18 Oct 1995 16:01:00 -0400 (EDT) > From: s1018954(a)aix2.uottawa.ca > Reply-to: s1018954(a)aix2.uottawa.ca > Subject: Re: Anonymity: A Modest Proposal > To: Doug Cutrell <doug(a)cdsnet.net> > Cc: cypherpunks(a)toad.com > > > On Wed, 18 Oct 1995, Doug Cutrell wrote: > > > It seems that there could at least be a hierarchy of shadowed newsgroups, > > e.g. alt.freespeech.*, requiring the enduser to use special software to > > reassemble actual postings. This could even be integrated into the > > newsreaders, or even at a local newserver level. > > There already is. I think the *.test (or at least alt.test) groups have > good propagation. Nobody "reads" anything but their own posts anyway, so the > natives wouldn't be bothered. > YIKES! Think again. Many of the *.test newsgroups have auto-responders that remail the poster assuring them their post was received. This feature is used to make sure your newsfeed is working.

2 1

Re: Postscript in Netscape
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> From: sameer <sameer(a)c2.org> > > In any case, it might be wise for Jeff to get a non-netscape > account to do his cypherpunks posting from, so as to avoid > confusion. (ObPlug: Community ConneXion offers mailboxes for just > $5/month -- shell accounts for $7.50 ;-) Oh that would be silly now wouldn't it? If Jeff wants another account that's his business, but people don't normally expect that you're a spokesman for a company just because you work there. Jeff even has, like most of us, a disclaimer in his sig saying he doesn't speak for the company. Anyone that assumes otherwise is surely a newbie to the net, and just like most bizarre assumptions that newbies make we'll gently correct them, and they'll learn. Patrick p.s. was sameer's post a spam? <snicker;> Please don't take this line seriously, it was said with tongue definately in cheek. _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

digital cash and identity disclosure
by Andreas Bogk 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Hi... In the Cyphernomicon, section 12.6.6, Tim May writes: - Chaum went to great lengths to develop system which preserve anonymity for single-spending instances, but which break anonymity and thus reveal identity for double- spending instances. I'm not sure what market forces caused him to think about this as being so important, but it creates many headaches. Besides being clumsy, it require physical ID, it invokes a legal system to try to collect from "double spenders," and it admits the extremely serious breach of privacy by enabling stings. For example, Alice pays Bob a unit of money, then quickly Alice spends that money before Bob can...Bob is then revealed as a "double spender," and his identity revealed to whomver wanted it...Alice, IRS, Gestapo, etc. A very broken idea. Acceptable mainly for small transactions. But as far as I got Chaums idea, Alice would not reveal Bobs identity, but rather her own. Am I missing a point here? Andreas -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAgUBMIVd0EyjTSyISdw9AQFvAQP/bLDQV1JEIXPlUxbUqMVffv62YQf4j6Wu IkTr0qMjP4PLpLZFyKus+uf3JQIYsK660LdDykmcKafdYMH8LW6Z4SxDkkd2HwyY Hsf5xW3aIfnyQ5bPcI5dhWz4hao9RJ23Hc7sjzvHVgTcrQCLf7ADixhPCm7xnq3n YffnXg5slHU= =pLXN -----END PGP SIGNATURE-----

3 2

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

STT - useable in real life ?
by lyalc＠ozemail.com.au 17 Dec '03

17 Dec '03

>From reading the STT specs, a 'credential' is made up of typically 4 certificates - root, country CA, issuer Ca, and cardholder/merchant. Two certificates are based upon a 1024 bit public keys, 1 (root) is 2048 while the cardholder PK is 512/768 bit. I believe a decrypt operation is required to verify each certificate. I have seen test result from a local crypto company which indicate a 1024 bit decrypt operation will take between 2.5-30 seconds (Pentium 90 - 386/33 - I am trying to relate this to userland, not the well equipped cybernaut). PK encrypt is somewhat faster. On this basis, a credential verify will take 10+ seconds up to several minutes, on this range of equipment. This seems to take a significant amount of time in verifying certificates. This situation will only get worse as renewal certificates are appended to existing certificates. Can someone comment, or steer me in the right direction if I have misunderstood certificate verification ? Working for a bank who may have to use this one day, customer impact is a big deal - we can afford specialised hardware, but not all our customers can. thanks for any clarification, lyal All mistakes in this message belong to me - you should not use them!

2 1