December 2003 - cypherpunks-legacy

Empennage Seminar -- Sun Microsystems
by stevenw＠iglou.com 17 Dec '03

17 Dec '03

Seen on ba.seminars and posted here: Mathematical Sciences Research Institute Empennage Seminar An Introduction to Cryptopolitics Whitfield Diffie Sun Microsystems Mountain View, California Some years ago, Andy Gleason observed that during World War II, the physicists had discovered that what they did had an impact on the real world and that now it was the mathematicians turn. The talk will explore why seemingly arcane technology has become a political football. We will examine the significance of communications privacy in human affairs, how communications intelligence functions, and how cryptography affects that functioning. In the process we will look at a variety of proposals for controlling cryptography and the possible impact of those propsals on intelligence, law enforcement, commerce, and the personal life. 2 PM, Tuesday October 24, 1995, MSRI Lecture Hall Next Month: Scott Mitchell, Sandia National Laboratories, on hexahedralization ##################################################################### About Empennage As part of our effort to build bridges between Mathematics and the larger world, the Mathematical Sciences Research Institute is sponsoring a seminar where mathematicians can meet adventurers on the technological frontier. The Empennage Seminar will meet in the MSRI lecture hall Tuesday afternoons from 2 to 3. The seminar is intended to bring together not only scientists from the Bay Area involved directly with mathematical computing, but also people involved in envisioning and implementing new technologies, people concerned with the social and political ramifications of the development of information technology, and people working on problems, the formal nature of which brings them close to mathematics. The seminar is aimed at breaking down the walls which in this century have isolated mathematics from intellectual life outside of its own tradition. While the Empennage seminar is still in its infancy, we have begun to attract an audience beyond MSRI, including scientists from other institutions and disciplines, both within and without academe. If you have any recommendations for possible speakers, please let me know. Also, anyone interested in attending should contact me: Joe Christy, joe(a)msri.org, (510)643-6069. About MSRI The Mathematical Sciences Research Institute (MSRI) is an independently funded research institute located on the UC Berkeley campus, high above the Lawrence Hall of Science. At any given time, MSRI is host to 50 to 100 post-doctoral fellows and more senior researchers who come from all over the world for periods of a week to a year. Most of them participate in one of two topical programs which change from year to year, with a smaller group in "Area III", our catch-all. Currently the programs are Holomorphic Spaces and Several Complex Variables. MSRI is aiming to become a model site for the integration of computing into mathematical research. In practical terms this means not only the development and use of software for numerical calculation, symbolic manipulation, and geometric visualization, but also exploration of the uses of technology in other areas of scholarly life. This includes network access and distribution of structured information, new modes of scholarly communication (incorporating Email, formatted and illustrated mathematical text, and shared interactive software for experimental mathematics), and the development of software engineering tools necessary to put the creation of useful, shareable special purpose software within the reach of the average individual scientist. directions to MSRI are available at the URL: http://www.msri.org/housing/info/howtoget.html About the word "empennage" Empennage is the French word for fletching - the act of putting feathers on the tail of an arrow. This makes the arrow fly strighter by giving it a spin. ------------------------------------------------------------------------- Steven Weller | "The Internet, of course, is more +1 415 390 9732 | than just a place to find pictures | of people having sex with dogs." stevenw(a)iglou.com | -- Time Magazine, 3 July 1995

1 0

Seminar
by AFDA2＠aol.com 17 Dec '03

17 Dec '03

A quick update on the Association's upcoming seminar. As many of you know, on Saturday, November 4, 1995, the Association of Federal Defense Attorneys (AFDA) will be presenting a one-day seminar for defense attorneys entitled, "What Every Defense Attorney Should Know About The Federal Bureau of Prisons." The seminar will be held at the Los Angeles Airport Marriott Hotel, from 9:00 a.m. - 4:30 p.m. The purpose of the program is to provide defense attorneys with two avenues of insight into BOP. The first, which covers the morning and part of the afternoon, focuses on the administrative/policy-oriented makeup of the agency, and the defense attorney's strategic application of these rules. Speakers from the BOP, private defense bar and Federal Public Defenders Office will cover the following subjects: 1. Types of BOP facilities, including the key operating features of the USP, FCI and camp. 2. The flow chart of key players in BOP administration that attorneys should be familiar with, including the Community Corrections Manager, Community Corrections Staff, Regional Designator, and the legal offices at the various facilities and regional offices such as Dublin, Ca. 3.The BOP documentation system, which has its own unique classification and numbering system. This topic includes special attention to the key documents most likely to affect defense attorneys, such as Program Statements, Operations Memoranda, and Directives. 4. The key BOP terms that attorneys should be familiar with in order to communicate more effectively with staff and understand better the agency's documentation. 5. How to anticipate where the defendant will serve his/her sentence and secure a favorable outcome (to the degree possible). This subject includes: Designation of place of confinement Custody classification Institutional transfer and redesignation 6. Sentence computation (calculating release dates) 7. How to efficiently contact appropriate staff on matters of concern 8. Intensive Confinement Centers (boot camp) The second prong of the seminar, which covers about two hours in the afternoon, focuses on the "grass-roots" perspective of the federal inmate, in terms of basic facts about federal incarceration that lawyers need to pass on to their clients before the clients are designated to a facility. The speakers will be two former inmates who have done time at camps and FCIs. If you would like a fax-flyer for the program, email us a short note at AFDA2(a)AOL.com

1 0

java flaw
by an407769＠anon.penet.fi 17 Dec '03

17 Dec '03

Sun and Netscape fix Java-Navigator flaw >From PC Week for October 16, 1995 by Michael Moeller Netscape Communications Corp. has identified a flaw in Sun Microsystems Inc.'s Java development language that caused a security hole in Netscape's Navigator 2.0 Internet browser. The flaw left open the possibility for corrupted files or viruses to be downloaded over the Internet to a host PC. Netscape officials, in Mountain View, Calif., said the problem occurred when porting Java to the Netscape platform. Sun, also based in Mountain View, issued a fix that performs a tighter security scan of Java applets, or portions of code. Sun officials said no users were affected by the security flaw. The company is beta testing Java now, and the final version is scheduled to be released next month. Ironically, Java was designed as a secure development language to prevent users from contracting a virus when downloading an application over the Internet. With Java, World-Wide Web application developers can create applets that are turned into full-scale application code once downloaded by a Java- enabled browser. A security feature in Java scans for viruses before activating the applet. Java applications are designed to be run within the secure environment of a Java-enabled browser. When Java was ported to Netscape, one of the security features "fell through the cracks," said Arthur van Hoff, senior staff engineer at Sun and a principal architect of Java. As a result, a user could have downloaded a corrupt applet that could have continued to function outside the secure environment of the browser shell and infected other programs on a user's computer. Netscape has since released two new versions of its Navigator 2.0 browser for beta testing, one with Java support and one without. However, Netscape officials said that once the browser is released in mid-December, all versions of Navigator 2.0 will be Java-enabled. --****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION*** Your e-mail reply to this message WILL be *automatically* ANONYMIZED. Please, report inappropriate use to abuse(a)anon.penet.fi For information (incl. non-anon reply) write to help(a)anon.penet.fi If you have any problems, address them to admin(a)anon.penet.fi

1 0

Re: java flaw
by James A. Donald 17 Dec '03

17 Dec '03

At 06:59 AM 10/17/95 UTC, jerry the golden retriever wrote: > A security feature in Java scans for viruses before activating the > applet. I hope that this is false. Even if one had genuine artificial intelligence, it would be impossible to detect all viruses, only particular viruses and classes of virus. If Java is secure, virus scanning should be unnecessary, indeed impossible, because there could be no code configuration capable of acting as a virus. If virus scanning occurs, then it is possible to write a virus in Java, then Java is inherently insecure. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

4 3

Re: Security Spectra
by williams＠va.arca.com 17 Dec '03

17 Dec '03

P.J. Ponder writes: > In your recent post to the cypherpunks mailing list you proposed a > taxonomy of security weaknesses and vulnerabilities, adding that these Please watch your attribution. Vlad Nuri proposed this rating scheme. > The whole idea of categorizing or ranking holes and vulnerabilities ab > intitio, outside of their contextual application to a real system is not > very helpful. Systems vary so widely in their criticalities, > sensitivities, costs, etc., that each of your pre-defined categorized > weaknesses would have to be rejudged - in the context of the system being > analyzed - to determine how, and to what extent it could effect the system. I absolutely agree with you on this point. I'll point out again that this is the same problem as creating a rating scheme for the security of *products*. > The standard approach as I understand it is to analyze the system against > all the known vulnerabilities and attempt to measure (maybe only > qualitatively) the risks associated with the vulnerabilities. It is popular these days to jump on the risk assessment bandwagon and forget about assurance. This occurs because people think risk assessment is a quick fix that you can do after the system is built and configured. Some holes cannot be patched. --Jeff Williams <mailto:williams@arca.com>

1 0

San Diego Cypherpunks Physical Meeting
by Chris Claborne 17 Dec '03

17 Dec '03

San Diego Area CPUNKS symposium Thursday, Oct 26, 1995 Invitation to all Cypherpunks to join the San Diego crowd at "The Mission Cafe & Coffee Shop" were I hope to get an update of Lance Cottrell's new anonymous e-mail server, "mixmaster", exchange keys, and discuss other topical subjects. Don't forget to bring your public key fingerprint. If you can figure out how to get it on the back of a business card, that would be cool. Place: The Mission Cafe & Coffee Shop 3795 Mission Bl in Mission Beach. 488-9060 Time:1800 Their Directions: 8 west to Mission Beach Ingram Exit Take west mission bay drive Go right on Mission Blvd. On the corner of San Jose and mission blvd. It is located between roller coaster and garnett. It's kind of 40s looking building... funky looking (their description, not mine) They serve stuff to eat, coffee stuff, and beer. See you there! New guy, bring your fingerprint. Drop me a note if you plan to attend. 2 -- C -- ... __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.

3 2

Re: My chat with Goeff Greiveldinger
by Michael Froomkin 17 Dec '03

17 Dec '03

Here is my first cut at what I plan to say. Not real exciting, but I don't know how much knowledge to assume in the audience. I would be grateful for a pointer to any commercial key escrow services that are actually in operation today. And doubly grateful for a pointer to one that does not rely on a proprietary encryption scheme and/or one that allows/requires key splitting for extra security. Key Escrow in Secure Electronic Commerce October 19, 1995 4:30 pm - 5:50 pm Outline Intro: In this talk I will... * Begin with why business wants/needs *data* CKE * Turn then to law enforcement focus on communications KE * Explain how govt hardball on export control in pursuit of Comm KE threatens needed CKE -- or at least US companies' share of that market... * Discuss pending issues I. Commercial key escrow, the WHAT, WHY, WHO and HOW A. WHAT Give someone (internal/external) copies of keys (private/ symmetric) used in the course of business 1. Essential (from corporate perspective) for a. all encrypted, stored corporate data b. keys with power (1) to sign things in corporate name e.g. buy/sell (2) to issue certificates 2. Less essential (from corporate perspective) a. for email keys but still pretty important if you might have to reconstruct exchanges of messages at a later date. b. for telephone keys although useful if you think there will be need for you and/or police to spy on your employees, eg. investigate fraud/theft. B. WHY 1. Irresponsible for corporation not to encrypt data and some communications if these are of commercial value to competitors/otherwise sensitive 2. Irresponsible to encrypt data (and maybe also communications) and not have fail-safe means of access a. employees lose their keys b. employees die c. employees quit (and vanish or do some vandalism) d. employees are suspected of engaging in hanky- panky C. WHO Escrow agent could be 1. internal a. only viable solution right now unless you are satisfied with, e.g., RSA non-interoperable crypto system b. but are you hacker-proof? 2. external, e.g. a. TIS licensed "Data Recovery Center" (but there are none in existence today) b. bankerstrust c. govt agency (someday? but not today) d. can use split key systems for increased security. [but is anyone actually offering such a service?] One problem with external is that NONE of the liability issues are resolved. E.G. Suppose private escrow agent complies in good faith with facially valid warrant, but warrant is l D. HOW Here we have more doubts than knowledge Not clear yet what security precautions commercial escrow agents will offer. Can assume: 1. Secure systems 2. Contract-driven mechanism for verifying IDs/bona fides of persons attempting to take out data 3. Contract-driven assurances of speed of response 4. split key systems with different escrow agents? II. Legal implications of commercial key escrow Three families of issues: 1. data owner liability for not escrowing 2. escrow agent liability for errors 3. Government access to keys A. It is irresponsible NOT to escrow keys if you encrypt data. And it is increasingly irresponsible not to encrypt. Hence some form of escrow will become practically mandatory. 1. Query: won't this make it easier for the government to get access to my data? Answer: must distinguish between stored data and communications. You are escrowing the keys not the data itself. The data remains secure in your own machine/tape/safe/whatever. There it's subject to subpoena just like paper records. So encryption + escrow is no substitute for destroying the smoking gun, but it's also no more danger than ordinary records. Escrowing keys used for communication makes those communications more vulnerable to government interceptions. Strong, unescrowed, keys may defeat even a lawful subpoena for a wiretap. Escrowed keys are vulnerable to legal (at least) wiretaps. 2. More on "practically mandatory": The government may make it a condition of doing certain kinds of business, e.g. govt contracting, that only escrowed encryption be used. Similarly, the government may be willing to engage in secure communications with the public, but only via system that are limited to escrowed keys. 3. Still more on "practically mandatory": carrot & stick of export controls (see below). B. Escrow agent liability for errors Currently, rights and resp of customer vs. escrow agents depend on whether escrow agent is public or private 1. Public escrow agent -- low accountability? In the "Clipper 1" proposals, the escrow system lacked any legal guarantees for the people whose keys are generated by the government and held by the escrow agents. Indeed, the Attorney General's escrow procedures stated that they þdo not create, and are not intended to create, any substantive rights for individuals intercepted through electronic surveillance.þ In short, the government disclaimed in advance any reliance interest that a user of an EES-equipped device might have in the government's promise to keep the key secret. A victim of an illegal wiretap would have a cause of action under Title III against the wiretapper, but, it appears, no remedy against the escrow agents, even if the escrow agents acted negligently or failed to follow their own procedures. The Attorney General's procedures themselves are merely directives. They are not even legislative rules, which might be subject to notice and comment restrictions before being rescinded. A future administration could, if it wanted, secretly instruct the escrow agents to deliver copies of the keys to an intelligence or law enforcement agency, or even White House þplumbers,þ thereby violating no law or regulation (the plumbers, though, would violate Title III when they used the information). Because the chip-unique keys were voluntarily disclosed to the government, the chip's owner might lack a þlegitimateþ (that is, enforceable) expectation of privacy in the information. If the intercepted communication were an e-mail or a file transfer, rather than a telephone call, the chip owner subject to an illegal or inadvertent disclosure by the escrow agents may be in a particularly weak position if the information ever makes its way to court: many Title III protections granted to voice communications do not apply to transfers of digitized data. Shortly before the 103d Congress adjourned, Congressman George Brown introduced the Encryption Standards and Procedures Act of 1994, which would have waived the sovereign immunity of the United States for þwillfulþ but unauthorized disclosures of key fragments by its officialsþand excluded liability in all other circumstances. In the absence of similar legislation, however, there may currently be no monetary remedy even for a þwillfulþ disclosure. 2. Private escrow agent -- contract accountability, tort, maybe bailee/trustee (dubious) If you want software key escrow today, you have to be your own escrow agent, or go to a private escrow agent because there is no government agency ready and able to act in this capacity (and few private bodies!) Given current liability rules, you would be better off with a private body than the government anyway (tradeoff: maybe more security in government agency (?) vs. more recourse against private party). The "son of clipper" trial balloon floated this fall suggested that export permission would be given to (relatively) strong (ie. 64 bit max) software cryptosystems, if those systems were designed to ensure that the keys were escrowed with an "approved escrow agent". NIST solicited comments in Sept. '95 as to a. what sort of bodies would be suitable, and b. what terms and conditions should govern the escrow agents. c. What procedures need to be developed for the storage and safeguarding of keys? d. Performance criteria (e.g., around-the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? e. Under what circumstances will key escrow agents in foreign countries be approved? f. Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? [The last point is potentially ominous...if access to digital signature infrastructure is conditions on using KE, then this makes export control hardball look like small beer] To date there has been no public feedback from NIST subsequent to the meeting except that they are revising the criteria in light of what they heard. [Can GG tell us more?] C. Government access to keys NB that government seems primarily interested in communications; business main focus is/should be DATA. Now with "Son of Clipper" (software KE), the government has relaxed the suggestion that keys be generated and escrowed via hardware (e.g. Fortezza), but has substituted onerous criteria it hopes it can persuade (threaten?) industry to apply to software, including: III. (Mostly specious) Arguments Against Commercial Key Escrow [with apologies to Marc Rotenberg, Electronic Privacy Information Center, who posted the quoted material to USENET several months ago] A. Bad for business 1. "Increased network vulnerability. The key escrow configuration necessarily increases the likelihood of communications compromise and improper interception by third parties. Computer crime will skyrocket." Very unrealistic and alarmist. While as a theoretical matter it is clearly true that the sharing the keys with the escrow agent must create an avenue of attack that did not exist before, the risk can be very greatly reduced by a. key splitting (never send the whole key to anyone at any time) b. secure communications with very secure algorithms between escrow agent and customer [NB that US government export policy implicates this to the extent it makes strong crypto non-exportable] 2. "Policy incoherence. The key management needs of business differ sharply from the real-time intercept plans of law enforcement. The latter has little to do with the former." Probably true, but irrelevant to the matter at hand: business needs escrowing for its own disaster recovery needs. 3. "Complexity. Has anyone really given thought to how many communications will be encrypted in 20 years and what the key management requirements will be to develop a unitary key escrow system to satisfy the government's concerns?" Maybe, maybe not. But businesses need CKE now. Keys don't live for ever, and a sound security plan will include provisions for retiring keys as they age. Age makes keys vulnerable a. technological change makes bruting longer keys possible b. the longer the key is out there the more time attackers have to brute (or otherwise compromise) the key B. Bad for civil liberties 1. "Emergency circumstances taps. The current wiretap law permits the initiation of a wiretap *without court order* upon a certification that emergency circumstances exist. If this procedure is built into the CKE procedure, then there will be *no judicial review* prior to the disclosure of keys." True. But these taps are currently rare, and limited to cases like kidnapping where lives are at stake. It's fairly unlikely that a business will ever encounter one of these. 2. "The future of PGP. Will PGP and other non-escrow schemes be permitted if CKE is adopted? What will be the implications for developers and companies in the communications industry?" Voluntary CKE in and of itself is not going to affect the legality of alternative un-escrowed crypto. The politics are hard to predict: one can imagine arguments that mandatory escrow is not needed because it's being done voluntarily; and also arguments that the increasing voluntary CKE means that there's less reason not to make it mandatory. My guess: no great effect one way or the other. The issue will be settled by larger things e.g. what's more scary -- Oklahoma City or Ruby Ridge? IV. Recent Developments in key escrow A. NIST initiatives NIST is currently putting "final touches" on draft export criteria, under auspices of inter-agency working group. NIST hopes to "notice" revised draft criteria in fed register, perhaps within the next month; then a 60day comment period, with a 1-day live meeting in DC sometime during the comment period. When NIST has final version of inter-agency recommendations set, they will be turned over to the state dept to implement; state can do what it likes. One possible model for State Dept. action is a change to the ITAR. V. Outstanding Issues A. Why would any foreign company use US govt approved crypto in light of new focus on economic intelligence, e.g. Japan spy case? Possible govt responses: 1. foreign govt might have copy of key? share key? 2. foreign-based, but US-approved, escrow agent might hold/share key B. MANDATORY CKE? 1. Legislation? 2. "milder variants" a. export control club (is 64 bits enough?) b. data vs. communications issue c. Digital signature infrastructure access club (informal talks suggest this is not likely, but not formally ruled out....) C. Enabling ("technical") legislation 1. Title III exemption for escrow agent 2. Authority to "certify" escrow agents 3. liability rules for escrow agents D. Enabling regulations 1. Care & feeding of escrow agents, a. eg. sample criteria for being approved and/or sample contract between government and escrow agent b. performance criteria for escrow agents e.g. response time E. Liability in the absence of legislation 1. First, find someone actually selling escrow services with an interoperable product. 2. Or, resign yourself to eg RSA keys. A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's hot here. And humid.

1 0

NOT_100
by John Young 17 Dec '03

17 Dec '03

The New Yorker of October 23 reports on the "Supernote," a perfect counterfeit $100-bill allegedly being used for economic terrorism. The Supernote had surfaced around 1990 and originated in the Middle East. It was no ordinary counterfeit. The workmanship was extraordinary. When a sample first arrived at the Secret Service's laboratory, a top technical analyst "examined it the way he has every other counterfeit note in the world, and called it genuine." Most alarming of all, the Supernote was so well engineered that it could fool currency scanners at the nation's twelve Federal Reserve banks. Today, the Supernote remains one of the longest unsolved counterfeiting cases in the modern history of the Secret Service, and it has begun to undermine international confidence in United States currency. The Treasury, taking its cue from the Federal Reserve, has a difficult time regarding counterfeiting, even on a very large scale, as a macroeconomic problem, because cash is a relatively small percentage of the total money supply. Wire transfers, checks, and credit-card transactions, after all, run into the trillions. Counterfeiting becomes significant to the Fed only if it undermines confidence in the dollar. Dozens of interviews with high-level insiders left the impression that the Federal Reserve and the Treasury don't fear the Supernote itself as much as they fear a confidence problem that might result if they publicly acknowledge it and countenance a large-scale investigation. (As one expert on international terrorism who has looked into the Supernote puts it, "If the note is that nearly perfect, it doesn't exist.") NOT_100 (30 kb in 2 parts)

1 0

Re: Using deterministic programs to select private RSA keys.
by Martin Diehl 17 Dec '03

17 Dec '03

norm(a)netcom.com(Norman Hardy) writes: Much has been said recently here about how to produce truly random primes. [snip] The protocol is to accept a sequence of key strokes for printable ASCII characters. [snip] I suggest that if you capture the time in microseconds between keystrokes and insert the least significant 8 bits between the corresponding characters (i. e. <letter1> <time2 - time1> <letter2> <time3 - time2> <letter3> ... <letter nnn> <time until double CR - time nnn>) and MD5 the set of values, the resulting "random" value will be different for both people who type different input texts as well as those people who type the same input text. It is important to be sure that you are accessing a true microsecond clock (or other high resolution clock). For example, in the IBM PC architecture, the clock tic (basic time interrupt) is one per 18.2 milliseconds or 55 interrupts per second. If you were using the clock tic rate and a highly trained typist with a regular typing rate, the interspersed time values might show a consistent set of values. On the other hand, use of a microsecond clock eliminates this problem. As regards the observation that MD5 produces only a 128 bit result, you could call MD5 after each nn values (at least 16) have been entered. In that way a few lines of input and associated timing values could easily generate a value of the same order of magnitude as the number of 1K primes. Martin G. Diehl

1 0

Re: Netscape rewards are an insult
by Westcan1＠softnc1.softnc.com 17 Dec '03

17 Dec '03

:: Request-Remailing-To: cypherpunks(a)toad.com Subject: Re: Netscape rewards are an insult > > Promoting the notion that hackers are earnestly attacking > > Netscape and reporting its bugs increases its credibility to > > the stock market porkers. Is that not why dear > > all-too-attentive Jeff has been assigned duty on this list, > > feeding peanuts to chimp hackers and champ newshacks? Whoa!! > I'm afraid you're a little out of line here. > I've worked with Jeff at a couple different companies > over the last 6 years. Besides being a very good programmer > he's also one of the people I consider the most resistant > to corportate bullstuff (beleive me, we both got a lot of it at MicroUnity). > I'm sure he's on this list because he thinks it's a good > idea to pay attention to it. Maybe he is, but I'd rather hear everyone speak for themself. You can speak for you. And you can let Jeff speak for himself. And I'd rather that Netscape speak for itself, too. Is Jeff or any of the other netscape posters here officially?? Or are they here, just out of personal curiosity (without their employers knowledge, I mean ...) cause they have a whole lot of spare time on their hands to learn about cryptography and security. I wish one of them (or Netscape) would make an official comment to make sure that the record is straight, and that there is no mis-reporting. > What the hell is wrong with you people? Up 'til a few months > ago, the oft-heard refrain on cipherpunks was "why won't the > software vendors listen to us?"... now they're listening, Yep, they seem to be listening. They just don't seem to be talking. Can someone say something, please?? Is it true that: - Netscape has known about this problem since last week's scathing public attack and demonstration of the problem which included sample code posted to the Internet?? - If you run and use a Netscape client, that any machine anywhere in the world if it's on the Net could retrieve all of the files off of your hard drive or LAN?? Or even worse ... erase files on your Hard drive and wipe you out?? - Even if your machine is behind a firewall or proxy server, that there is no protection?? That you can't do anything?? Can someone comment, please?? (Carbon copy sent to: postmaster(a)netscape.com, cypherpunks(a)toad.com, cert(a)cert.org)

11 22