December 2003 - cypherpunks-legacy

Re: WTO an even worse possibility as Inet regulator.
by James M. Cobb 17 Dec '03

17 Dec '03

Friend, attila(a)primenet.com did the list a service when he sent his message, "WTO an even worse possibility as Inet regulator." Basing the message "on an article from the (London) Finan- cial Times," he states that a very credible white paper is circulating for the WTO to establish an internet CZAR to regualate the Internet... and he asks: personally, the Feds and the FCC are bad enough --now they want to have a **global** bureaucracy play god -??? That 11 29 95 Financial Times newsstory is headlined: Global regulator urged for information highway Who's doing the urging? The Royal Institute of International Telecommunications Policy put out a report written by a Shell man and a think- tank woman. As regards encryption, the RIITP people ...point out that issues such as...encryption...have global rather than national aspects. Then they contradict themselves: "Encryption, for example, raises tricky and emotive issues connected with...national security and cannot be treated simply as a business problem." Whatever works! They "encrypt" the ultimatums of the New World disorder in any...key. At the very end of the newsstory: Global Superhighways, Chatham House, 10 St James Square, London SW1Y 4LE I'm guessing Global Superhighways is the title of the RIITP report. As for Chatham House... In 1919 [a group of young men who became the dominant influence in British imperial and foreign affairs up to 1939] founded the Royal Institute of International Affairs (Chatham House) for which the chief financial supporters were Sir Abe Bailey and the Astor family (owners of The [London] Times). Similar Institutes of International Affairs were established in the chief British dominions and in the United States (where it is known as the Council on Foreign Relations). --Carroll Quigley [Clinton's mentor]. Tragedy and Hope. A History of the World in Our Time. Macmillan, 1966. P 132. RIITP is probably a front for RIIA. I conjecture, though, that the real publisher of the report has his house in Washington. I agree with jamesd(a)echeque.com who writes: The main threat to freedom is still internal, rather than external. Looked at from the inside, of course. Cordially, Jim

2 1

Re: Netscape, Corporations, and GAK Support
by carolann＠censored.org 17 Dec '03

17 Dec '03

I know I may be asking for this a second time, But just what is James Clark's E-Mail Address? Thanks! Happy Holidays! Carol Anne -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

Re: A "Warning Banner" for Netscape Navigator? Good idea! Re: A "Warning Banner" for Netscape Navigator? Good idea!
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- tcmay(a)got.net (Timothy C. May) wrote: >Oh, I don't have their home page enabled. What I meant, but perhaps wasn't >clear about in my post, is that the commercials pop up in Yahoo, Infoseek, >Deja News, Excite, and so forth. (OK, so it is inaccurate to say "Netscape" >puts them in.) > >Some of the ads are intertwined with the command boxes of the particular >service, and thus may be hard to excise, but others seem to be separate. > >Any ideas? > >--Tim May A while back, someone on comp.infosystems.www.* posted patches to CERN httpd allowing the proxy server to filter out url's based on regexp matching. Thus you could update a regexp file as new ads appeared. It should be fairly easy to implement something similar under Netscape 2.x using plug-ins. Anyone interested in collaborating? Wilhelm Busch -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBML/FZIiUi5SQtQ3tAQHeAAgAmtp2fF9/UzHpDIz0pOXQqZ/0U+1/vMjR jenuLn17jkgQQXAl6e617ZKMJ4h+vV8QBOh78CPaK7omV9oJyNfDRQweDBWtiFRl uEzyeUoYwGoXxkUH5ANM8AW3GaBSiQ4TCDnwZlAsJ1pYYGRgJhMtdEwPnNVAXW+l l0uODlH+ENi8hGwsM683j7gGws0cc4JcH7Ou2U9zmLZ2gHrdQsWWdw70PjhdlK7e 26aY7EGfI9pTH69mHKV60Qxj2FmSCt1v6MeHjUwRupajCNTGcnsw3FllvRJc7lug cYPApS2ychZSszUwBqoBMvJpAUSpWk+x/RfQTDeo0wsCSvwc66mhWA== =DnEr -----END PGP SIGNATURE-----

2 1

nsa and netscape
by Bob Bruen, MIT Lab for Nuclear Science 17 Dec '03

17 Dec '03

The following came from a government source. I thought it might be of interest. Bob -------------------------------------------------------------------------- At yesterdays FNC (Federal Networking Council) meeting it was mentioned in passing that NSA has given Netscape a grant of $5 Million (yes $5M) to beef up the security features of Netscape. More info will be forthcoming on this.

5 4

RE: Netscape gives in to key escrow
by Pete Loshin 17 Dec '03

17 Dec '03

JR wrote: >With regard to all this waving about Netscape giving in to key scrow... > >First one question, and then some considerations. The question: > >- How much of Netscape stock is in the hands of Netscape? I mean in the hands The original IPO was for 5 million shares. The vast majority of the stock is not on the market yet. It's owned/controlled by Clark et al, and presumably a healthy share for the VC's (though I have no knowledge of their participation). -Pete Loshin pete(a)loshin.com

1 0

CPunks in the news: St. Jude
by Jim Gillogly 17 Dec '03

17 Dec '03

Today's (1 Dec 95) LA Times has a writeup on female "hackers", and gives several sympathetic column-inches to St. Jude Milhon, a charter Cypherpunk. Evidently she has a new book coming out (Girls with Modems?). Jim Gillogly Sterday, 11 Foreyule S.R. 1995, 17:11

1 0

Re: "Got a subpoena?"
by alt＠iquest.net 17 Dec '03

17 Dec '03

At 06:57 PM 11/30/95 -0500, JHupp(a)Gensys.Com wrote: > And at that point, you shut down the remailer and log each and every >bounce. > > Now, they could get an order forcing you to run a remailer ~ but that >would open up a whole new can of worms i.e. can you be forced, under >court order, to commit a crime? That's not how they do it. They will tell you that unless you cooperate, you will be charged for the "crime" you have been committing. Where do you think confidential informants come from? They're just people who have been caught or set up by the cops, who are trying to save their own ass.

1 0

Media Advisory: GAK on Dec 5
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Reposted for background on the Netscape $5m IOUNSA for its insecure future: Note that Messrs. Clark and Andreeson can't sell their stock until two years post IPO. ------------------ Nov. 6, 1995 Contact: Anne Enright Shepherd (301) 975-4858 anne.shepherd(a)nist.gov MEDIA ADVISORY U.S. GOVERNMENT SEEKS PUBLIC COMMENT ON DRAFT EXPORT CRITERIA FOR KEY ESCROW ENCRYPTION Revised proposed export criteria for software encryption products using a key escrow mechanism are now available for public review. Public comment will be solicited at a Dec. 5 meeting to be held at the Commerce Department's National Institute of Standards and Technology. Key escrow encryption is part of the Clinton Administration's initiative to promote the use of strong techniques to protect the privacy of data and voice transmissions by companies, government agencies and others without compromising the government's ability to carry out lawful electronic surveillance and to execute search warrants for electronically stored communications. The exportability criteria being proposed are for an expedited licensing review process for software key escrow encryption products with keys up to 64 bits long. The U.S. Interagency Working Group on Encryption and Telecommunications, a body that develops recommendations on Administration encryption policies, solicits additional public comment on the revised criteria. Since the Clinton Administration's Aug. 17, 1995, announcement of proposed liberalization of export control procedures for key escrow software products with key lengths up to 64 bits, the working group has met with representatives of computer hardware and software manufacturers, industry trade associations and others interested in providing strong security for electronic data and transmissions. Based on comments received to date from industry, the criteria have been revised to better reflect commercial interests while balancing the needs of law enforcement and national security. These criteria do not replace or supersede any other licensing processes or criteria. Export applications for other types of products will use the existing licensing process. The Dec. 5 meeting, to be held from 9 a.m. to 5 p.m. at NIST in Gaithersburg, Md., is free and open to the public. Representatives from the interagency encryption working group will discuss the draft criteria and answer related questions. Those interested in attending the workshop can register before Nov. 30 by sending their name, organization, postal address, phone, fax number and e-mail address to Elaine Frye of NIST by fax: (301) 948-1784 or e-mail: elaine.frye(a)nist.gov. For additional information, call (301) 975-2819. Once public comments are received and the export criteria are given any necessary clarifications, the Department of State is expected to issue guidance incorporating the criteria in early 1996. Products will be reviewed by the State Department to verify that they satisfy the final criteria. Products meeting the criteria will be transferred to the Commodity Control List administered by the Commerce Department's Bureau of Export Administration, where they can be exported under a general license. The revised proposed export criteria are available on the World Wide Web at http://csrc.ncsl.nist.gov/keyescrow/. Reporters may also request a copy from Anne Enright Shepherd at NIST, (301) 975-2762, fax: (301) 926-1630, or e-mail: anne.shepherd(a)nist.gov. ------------------- Meeting Announcement Draft 64-bit Software Key Escrow Encryption Export Criteria On December 5, 1995, the Commerce Department's National Institute of Standards and Technology (NIST) will sponsor a meeting to discuss proposed exportability criteria (11/95 version) for 64-bit software key escrow encryption. This meeting continues the industry- government dialog of an earlier NIST-sponsored meeting held in September. At that meeting, officials of the U.S. Interagency Working Group on Encryption and Telecommunications (IWG/ET) met with industry representatives and other interested parties to discuss an initial draft of these criteria. In response to comments received, the criteria have been revised with the intent of achieving commercial acceptance within the flexibility permitted by law enforcement and national security constraints. Changes to the proposed criteria have been made, and a new draft is now available for public review and comment. At the upcoming meeting, representatives from the IWG/ET will discuss the draft criteria and answer related questions. Time will follow for industry representatives and other interested parties to comment on the criteria. Also, breakout sessions will be held to discuss each criterion in greater detail. At a minimum, Government representatives are scheduled to attend from the Office of Science and Technology Policy, National Security Council, the U.S. Department of State, the U.S. Department of Justice, the U.S. Department of Commerce, the National Security Agency, and the Federal Bureau of Investigation. The meeting will be held on Tuesday, December 5, 1995 from 9:00 a.m. to 5:00 p.m. at NIST in Gaithersburg, Maryland in the Red Auditorium of the Administration Building. Please register via e-mail (to "elaine.frye(a)nist.gov") or via fax (301-948-1784) before November 30, 1995. To register, please provide: 1) your name, 2) organization, 3) postal address, 4) phone, 5) fax number and 6) e-mail address. Alternatively, walk-up registration will be available on-site the day of the meeting. Directions from Washington, DC: from the Beltway (I-495) take I-270 North to Exit 10 (Clopper Road). At the first traffic light (Bureau Drive), turn left into the main entrance to NIST. Follow signs to the Administration Building parking lot. The receptionist at the entrance to the Administration Building can provide directions to the Red Auditorium. If you would like to make a presentation with your comments on the proposed criteria, you are asked to contact Elaine Frye at NIST via e-mail at "elaine.frye(a)nist.gov" or via telephone on 301- 975-2819 by November 30, 1995. The number of presentations as well as their length may be limited. Presenters (and others wishing to distribute material) are asked to bring 250 (attendance estimate) copies of their presentations to the meeting. ----------------- Draft Software Key Escrow Encryption Export Criteria (11/95 version) Export control jurisdiction for a software key escrow encryption product that meets the following criteria, as determined by the U.S. Department of State after a one-time review, will be transferred to the U.S. Department of Commerce for export licensing. These criteria do not alter existing licensing practices applicable to other encryption products or modes. Vendors must still submit other encryption to the U.S. Department of State for review and export licensing, or jurisdiction transfer as appropriate. Vendors contemplating the development of encryption products are encouraged to discuss their export objectives with the U.S. Government. Key Escrow Feature 1. The key(s) required to decrypt the product's key escrow cryptographic functions' ciphertext shall be accessible through a key escrow feature. 2. The product's key escrow cryptographic functions shall be inoperable until the key(s) is escrowed in accordance with #3. 3. The product's key escrow cryptographic functions' key(s) shall be escrowed with escrow agent(s) certified by the U.S. Government, or certified by foreign governments with which the U.S. Government has formal agreements consistent with U.S. law enforcement and national security requirements. 4. The product's key escrow cryptographic functions' ciphertext shall contain, in an accessible format and with a reasonable frequency, the identity of the key escrow agent(s) and information sufficient for the escrow agent(s) to identify the key(s) required to decrypt the ciphertext. 5. The product's key escrow feature shall allow access to the key(s) needed to decrypt the product's ciphertext regardless of whether the product generated or received the ciphertext. 6. The product's key escrow feature shall allow for the recovery of multiple decryption keys during the period of authorized access without requiring repeated presentations of the access authorization to the key escrow agent(s). Key Length Feature 7. The product's key escrow cryptographic functions shall use an unclassified encryption algorithm with a key length not to exceed sixty-four (64) bits. 8. The product's key escrow cryptographic functions shall not provide the feature of multiple encryption (e.g., triple- DES). Interoperability Feature 9. The product's key escrow cryptographic functions shall interoperate only with key escrow cryptographic functions in products that meet these criteria, and shall not interoperate with the cryptographic functions of a product whose key escrow encryption function has been altered, bypassed, disabled, or otherwise rendered inoperative. Design, Implementation, and Operational Assurance 10. The product shall be resistant to anything that could disable or circumvent the attributes described in #1 through #9. ------------------ Background Paper Changes to the Criteria Based on Earlier Public Input The government presented draft criteria (9/95 version) for the export of software-based key escrow encryption at an open meeting at NIST on September 6-7, 1995. Meeting participants suggested several changes to the criteria; the government re-drafted the criteria as described below. Industry's ideas and words were included when possible and given serious consideration consistent with the protection of fundamental interests (e.g., privacy and national security). General changes to the document: The document was re-structured to make it clearer. After the introductory text, related criteria are grouped into the following categories: a. key escrow feature b. key length feature c. interoperability feature d. assurances Changes to the introductory text: The wording has been clarified, and additional words have been included to encourage vendors that are considering building non-escrowed encryption products to discuss their export objectives with the government. Changes to the criteria: The criteria presented at the September 6-7 meeting have been modified in the following ways: Old Criterion 1. Moved to #7; wording clarified. Old Criterion 2. Moved to #8; wording clarified. Old Criterion 3. Split into #1 and #2 since the original criterion had two major points in it (the requirements for key escrow, and the requirement on when the keys are first escrowed); wording clarified. Old Criterion 4. Wording clarified; the notion of accessibility to authorized entities was modified to explicitly state that the required information must be available with a reasonable frequency. Old Criterion 5. Moved to #10; wording clarified, and the example was deleted so that implementors were not misled to believe that the example given was the only way of satisfying that requirement. Old Criterion 6. Moved to #9; wording clarified, and applicability of this requirement was scoped to address interoperability between a product's key escrow mode and a non-key escrow product. Old Criterion 7. Moved to #5; wording clarified. Old Criterion 8. Moved to #6; wording clarified because the term "repeated involvement" was perceived as being too broad. Old Criterion 9. Deleted. Old Criterion 10. Moved to #3; wording clarified, and requirement modified to not preclude the escrow of key by agents in addition to those required by these criteria. Note: The September (and November) version of the criteria is available electronically at: "http://csrc.ncsl.nist.gov/keyescrow/" ***************************************************** Elaine Frye Computer Systems Laboratory, NIST Bldg. 225/Rm.B154 Gaithersburg, MD 20899-0001 Voice: 301/975-2819 Fax: 301/948-1784 *****************************************************

1 0

[NOISE]Re: AUTHOR A VIRUS, GO TO JAIL
by RobL 17 Dec '03

17 Dec '03

At 10:08 PM 11/30/95, Michael Coates wrote: >Found this intersting too. US Position? > >AUTHOR A VIRUS, GO TO JAIL >A computer cracker last week became the first virus writer sentenced to a >jail term under Great Britain's Computer Misuse Act. The 26-year-old >perpetrator was sentenced to 18 months in jail after pleading guilty to 11 >charges connected with placing virus-infected programs on computer bulletin >boards. (Investor's Business Daily 29 Nov 95 A6) Gak.. glad I don't live in G.B. as I have had as many as 700 virii available for download on my BBS.. wonder how long it will be before the start to prosecute authors for writing buggy software ;) ------------------|----------------------------------------------------------- Rob Lowry | PO Box 288 | Rockford Wa 99030 | ral(a)otc.mhs.compuserve.com robl(a)on-ramp.ior.com

1 0

GAK, Netscape, CyberDog, and you.
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Hi Semper Fi-ers! I've been lurking on this list for a long time, and I haven't said much here primarily because I'm not a developer. I mean, I've hired developers, and sold the software I've had them build for me. Not very well, I might add, which is why I try do something else (talk and write) for a living now. Frankly, I couldn't code my way out of a paper bag, which, of course, is why I've not said much here. :-). Anyway, something has come up which I think makes the world very interesting, and I think you should know about it. Netscape has come out in favor of what the government calls "key escrow", but which most "cypher"-punks (and I seem to have become one over the last year and a half) call GAK, for Government Access to Keys. Here's the URL: http://www.cnet.com/Central/News/govt.html . This is a news report of a speech that Jim Clark gave at a trade show in Boston this week. Normally, as serious as this is in the rest of the world, that wouldn't really rate a mention here, except for the fact that this presents a very interesting set of opportunities for the *independent* Mac developer community in the form of CyberDog, Apple's set of OpenDoc parts for the internet. I'll get to that in a moment, but first, let me give you some background on the problem. Netscape's Jim Clark has quite a tightrope act going. He has a stock price which gives Netscape a P/E ratio of something like 7,000 (the S&P average right now is about 14), which means he really ought to get some revenue in the door, or his investors are going to have his hide. The next thing is, the government is a *really* big customer, and *they* want GAK, in case you haven't noticed. ;-). Couple this with the fact that Netscape is pretty much replicable by concentrated developer effort because its underlying technology is an open standard, *and* the fact that any significant attempt by them to create any real proprietary standards on the internet is practically impossible in the long run, unless they get a whole lot of very big customers in a hurry. Now, it looks like that's what happened already, because a lot of very large companies have signed on to using Netscape servers, but you can also see how really weak Netscape's position is when Uncle Sam knocks on their door and asks for a key escrow "bug" in every "secure" Netscape web session. This isn't the first time that Netscape has had problems with financial cryptography and the law. Netscape made the papers recently because the government-mandated SSL key-size in their export version was too small. (We won't talk about the cognitive dissonance between the words "export" and "internet" just yet...) The "export" version of Netscape Navigator got cracked by a French grad student in a university computer lab, who broke it just by running a bunch of background processes on his Sun workstations for a couple days over a weekend. The ITARs, the arms export laws covering this (cryptography is legally a munition, more cognitive dissonance), are a now problem for everybody who wants to do business securely and safely on the internet. More to the point, since digital bearer certificate technology, the most economical method for doing business on the net, is entirely based on digital signatures, which in turn are entirely based on very strong public key cryptography, all business on the internet will eventually require very strong cryptography. In other words, if you don't have unbreakable key sizes, you can't issue digital certificates to pay for things with. It would be like having paper money which is easy to forge. Lately, I like to say that "Digital Commerce *is* Financial Cryptography", and it's true. First Virtual has the only truly "out of band" internet transaction settlement mechanism, it's very well-designed, and very robust, but you have to remember that they did it *because* of the ITARs, and the complications for financial cryptography those regulations cause, no matter how much First Virtual itself likes to "dis" financial cryptography as a concept. Unfortunately, the transaction costs on such out-of-band methods are always going to be higher because of the inefficiencies of not instantly settling transactions, like you can with something like digital cash. When you buy something in the store for cash, you initiate, settle and clear the trade all at once, right there at the cash register, without an audit trail to maintain. Frankly, *any* credit card trade is really an "out-of-band" method, because it has to go off of the net to clear and settle, with audit trails, and the overhead of their offsetting book-entries. Fortunately, as governments start to figure this out, they will have to stand back and let the economic train go by, so to speak. So, having said all that, let's talk about OpenDoc and CyberDog. I hear that with CyberDog, building a secure Netscape-compatible browser in OpenDoc is now pretty simple. That adding economically useful -- and interchangable -- functionality like strong encryption, digital cash protocols and most of the tools of digital commerce is also pretty straightforward. That is, even though they have to be developed separately, because Apple justifiably doesn't want to have the ITARs limiting its export market for both OpenDoc and CyberDog. Again that cognitive dissonance between "export" and "internet". In addition to building utterly secure browser-server links, I see some interesting OpenDoc digital commerce applications coming out of a Netscape-compatible browser. My favorite "flash" on this was imagining the ability to drag Digicash ecash dollar bill icons out of a wallet and dropping them on a cash-register icon in a web page to pay for a transaction. That's certainly doable with OpenDoc and CyberDog. In addition, the IETF has just promulgated a secure link-level encryption standard called IPSEC, which allows for encrypted links between any two machines on the net, with any cryptographic method you want. That looks like a great Open Transport Streams Module project to me. And the wierd thing is, once IPSEC is out there, GAK in Netscape becomes moot, anyway. Netscape can only shoot itself in the foot here, and it looks like they already have, with a premature announcement of GAK. One final thing about Netscape. It's not their fault. There is no evil man-behind-the curtain in all of this. The government's doing what it thinks necessary for the preservation of order, and thinks it needs GAK to do that. Netscape is doing the best it can for its (newly rich) stockholders, and thinks it needs to comply with Uncle Sam, which it probably in fact has to do, or burst it's stock market price sooner, rather than later. Also, there is no reason why Netscape can't make a Navigator OpenDoc part, and I expect that they are planning to. I bet that Apple would really like that, and as a matter of fact, is probably courting Netscape to do exactly that. But I also know that by using OpenDoc and CyberDog, that the user can create a very easy to use, flexible, extensible, and *powerful* internet environment. Being there first with a Netscape-compatible browser, especially one that doesn't have GAK built into it, will be worth a whole lot in the marketplace for any enterprizing independent OpenDoc parts developer. I'm going to be giving a talk on Wednesday at noon at Apple's Town Hall, (4 Infinite Loop) in Cupertino about what I'm calling "geodesic" markets, that is, financial cryptography on the internet. The URL for a web page with all the details is http://thumper.vmeng.com/pub/rah/talk.html . In addition, if you want more stuff on financial cryptography, you might want to try my e$ home page, which is in my .sig, below. Finally, I've asked an *actual* financial cryptographer, Eric Hughes, who many of you may know from the cypherpunks mailgroup, and from the Clipper fight, to show up at the Cupertino talk and bail me out on the real hard questions. Well, that's about it. Oh. The talk is titled "Financial Cryptography for Dogs". I think you can see why, in light of the events of the last week, it's quite appropriate. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA (617) 958-3971 "Reality is not optional." --Thomas Sowell The NEW(!) e$ Home Page: http://thumper.vmeng.com/pub/rah/ >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0