December 2003 - cypherpunks-legacy

Revisionist History of the US....:( (fwd)
by chen＠intuit.com 17 Dec '03

17 Dec '03

Jim choate <ravage(a)bga.com> writes: > I am not going to name names but I would like to address the comment that > several folks have made (or agreed with) that the US has gone 200 years > w/o a major upheaval. > > Maybe I am taking a alternate History than you folks but I believe the > Civil War can be considered a major internal upheaval and it occured > 4 score and 7 years (87 years) after the birth of our country. Since then > we have also had the civil rights upheaval (if you don't want to consider > deaths of folks like MLK major that is your business) in the late 50's and > early 60's as well. Especially when you consider the political and social > turmoil that occured because of the Vietnam War. We might also add Shay's Rebellion, Bacon's Rebellion, the Hudson River Renters' Uprising, the Pullman Strike, the Homestead Strike, the Ludlow Massacre, the Lawrence Textile Strikes, etc., etc. Many of these were full-scale insurrections. This country's "progress" is really just a series of grudging concessions made by authoritarian power structures to various nearly catastrophic crises. > What I find most interesting about this chronology is that the > upheavals occur approximately every hundred years since our > founding. The fact that the present problems we are having w/ the > administration recognizing and the general populace demaning their > civil liberties/rights is apparently early by approximately 70 > years. Perhaps the present administration is really as progressive > as they claim...:) Take care. Good observation about periodicity, Jim, but I'd say that the typical span is much shorter than 100 years. - Mark - -- Mark Chen chen(a)netcom.com 415/329-6913 finger for PGP public key D4 99 54 2A 98 B1 48 0C CF 95 A5 B0 6E E0 1E 1D

2 1

Toll Free 800# Internet Access for $19.95 mo
by 05378440＠d.com 17 Dec '03

17 Dec '03

******************************************************************************* Market toll-free 800# high speed 56k Internet access to customers priced at $19.95 per month - flat rate - with no hidden fees. ********************************************************************* * Toll free connection great for travelers & rural residents. * All accounts include 5 megs of webspace. * Marketing Partners given 15 megs of web space. * Partners needed to market. Only $29.95 to become Marketing Partner. * Fast Start Bonus of $18 for each new subscriber you sign-up, paid weekly, plus downline royalties of 3% to 8% paid monthly. To receive instant information on toll free Internet access, send us an email at: 800intrnet(a)answerme.com Click Here ------>> mailto:800intrnet@answerme.com <<------ Click Here Put the word " Internet " in the subject and click send, you will immediately receive details. Or visit our Web Site at: http://205.152.38.41/800access.htm To hear plan through voice message (24 hours), call 901-664-6886 --------------------------------------------------------------------------------------------------------------------------- To remove from mailing list send an email to: details1(a)savetrees.com Click Here --->> mailto:details1@savetrees.com <<--- Click Here Put the word " Remove " in the subject and click send Disregard that the address says details1, it is only for removing from list --------------------------------------------------------------------------------------------------------------------------

1 0

Re: Alt.Gvmt.Immorality
by blancw＠pylon.com 17 Dec '03

17 Dec '03

Responding to msg by Michael Conlen: The United States is made up of ignorant people who know what they need to get by in life, and do not want to take the time to do what it takes to improve themselves, ie. vote. As for morality, I feel it is somthing that we all wish to be but find it hard to be. I know I find it hard to be moral. ........................................................ On the note, I offer this quote which is always amusing to me: "The only claim made for any organized ideas of human nature is that everybody everywhere needs them in order to tell what is human, what is natural, what is worth knowing, what is worth having and how to get it, and all the other information necessary for getting through the day, week, year and lifetime. .....That is human nature - to organize the data of human nature into a body of knowledge or working model. That is what a working model or organized idea of human nature does: it gives you the story about where everything belongs, and how and when and why it belongs there. And as for people who wear comfortable shoes and assume nothing, they are usually killed very young while trying to cross the street. Such people have no idea whatsoever about where anything belongs, or how and when and why it belongs there. That makes it very difficult to stay alive, let alone to locate the real fact. People who assume nothing have no working model of human nature to begin with and thus no way to assemble even the true story with its moral about what to pay attention to. ..... So that is how a working model of human nature works. It provides you with a frame of meaning and puts you in the picture. And once you are there, you can see where you stand on such diverse issues as life and death. You can find your point of view about taxes and clothing. You can fix your position with regard to the schoolhouse, the alehouse, the whorehouse, the courthouse, and the electric chair. In other words, a working model of human nature makes things visible, and you visible as well." - from "The Human Nature Industry", by Ward Cannel and June Macklin Blanc

3 2

Re: Re:I have had ENOUGH of this government bullshit!!
by CST Administration Dept 17 Dec '03

17 Dec '03

>And you can get PGP outside the US borders from ftp.ox.ac.uk >or any other ftp://ftp.pgp.net/pub/pgp mirror, >and also in the US at www.pgp.com or pgp.mit.edu. > That is true, but with the MIT setup, you have to certify that you are a US citizen and that you won't export it. Also, there are lots of folks who have trouble with the overseas downloads. I just plan on making it available for those in the US that want an independent site with out all the rig an mirole. Besides, I guesss this is just my own way of showing MY government who I worked for for 8 years that I won't take it anymore. This is my way of firmly placing myself in the Pro-Encryption camp. That means that their enemies are mine now. And if the government wants to be my enemy, then it is their choice. I served 8 years in the Army protecting our interests. One of them was our Consitution and our Bill of Rights. This is ALSO my my of letting them know that I will not tolerate them walking all over those core items anymore without a fight.

1 0

Needed for a computer ethics class
by Patrick Juola 17 Dec '03

17 Dec '03

Does anyone have a concise, citeable statement about why anonymous remailers are a good thing? Some sort of position statment by Julf would be ideal. Similarly, if anyone has something for the *other* side of the coin, I'd love to see that. I'm in the process of writing a course on computer ethics for the University of Colorado at Boulder and I think anonymous remailers would be a good subject for an essay assignment, but I need enough material (ideally, primary source material) to lay the groundwork first. Patrick

2 1

sober reflection
by Zooko Journeyman 17 Dec '03

17 Dec '03

A million monkeys operating under the pseudonym "Bill Frantz" typed: > A similar approach could evolve for network sites. A sign saying that we > follow the US Chamber of Commerce's code on fair information practices > could easily evolve. My questions are, what should that code contain? > And, how many different codes do we need? See "http://www.truste.org/", "TRUSTe", although I thought it used to be called "eTrust"? Zooko Journeyman [WE INTERRUPT THIS ARTICLE FOR A SPECIAL ARTICLE RATING: Hey, Dmitri M. Vulis! The article entitled "Spawn of Vulis" was not a flame or insult. If you deleted it without reading it, I encourage you to go retrieve it again and read it.]

1 0

EPIC Alert 4.11 (fwd)
by Declan McCullagh 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Thu, 24 Jul 1997 08:10:31 -0400 From: Dave Banisar <banisar(a)epic.org> ============================================================== @@@@ @@@@ @@@ @@@@ @ @ @@@@ @@@@ @@@@@ @ @ @ @ @ @ @ @ @ @ @ @ @@@@ @@@ @ @ @@@@@ @ @@@ @@@ @ @ @ @ @ @ @ @ @ @ @ @ @@@@ @ @@@ @@@@ @ @ @@@@ @@@@ @ @ @ ============================================================== Volume 4.11 July 23, 1997 -------------------------------------------------------------- Published by the Electronic Privacy Information Center (EPIC) Washington, D.C. http://www.epic.org/ ======================================================================= Table of Contents ======================================================================= [1] AOL to Sell Subscriber Telephone Numbers [2] Search Engine Rating Scheme Touted at White House [3] Another House Committee Approves SAFE Crypto Bill [4] FTC Acts on Kids' Privacy [5] Cellular Phone Group Asks FCC to Set Wiretap Standards [6] New Bills in Congress [7] New at the EPIC Bookstore [8] Upcoming Conferences and Events ======================================================================= [1] AOL to Sell Subscriber Telephone Numbers ======================================================================= In a quiet change to its privacy policy, America Online will soon be adding subscriber phone numbers to the list of personal information that it sells to direct marketers. The company may also match member lists against "publicly available third-party data" to develop lists for outside direct mail opportunities. Previously, AOL's privacy policy prevented the disclosure of subscriber telephone numbers, while allowing the company to sell member names and addresses. The new policy, which is to take effect on July 31, can be found in the relatively obscure "Terms of Service" area of the online service. No notice of the new policy has been provided on the "Welcome" screen where new AOL features are typically announced. The revised policy states that We make our mailing list (name and address) available to select independent companies that offer products and information we think may interest you. Additionally, we may make the list with telephone numbers available to companies with which AOL, Inc. has contractual marketing and online relationships for the purpose of permitting such companies to offer products and services over the telephone. AOL, Inc. may also match the Member lists against publicly available third-party data (demographic information, areas of interest, etc.) to develop lists for use by these companies. The new policy, which is to take effect on July 31, also points out that AOL discloses individual information in an aggregated form in order to describe its services to prospective partners, advertisers and other third parties. AOL may also use publicly available third-party data such as demographic information and areas of interest to assist AOL in their "programming, editorial research and to offer special opportunities to our Members." While AOL will generally not disclose "navigational" or "transactional" information (such as where you go or what you buy through AOL) to third parties, it may use such information to develop member lists for companies with which AOL has a contractual marketing relationship. For years (and most recently before the Federal Trade Commission), industry has argued that self-regulation and not legislation is the only way to ensure that businesses protect individual privacy in electronic media. If AOL's new privacy policy is representative of industry's vision of what self regulation entails, users may have real cause for concern. More information on online privacy is available at: http://www.epic.org/privacy/ ======================================================================= [2] Search Engine Rating Scheme Touted at White House ======================================================================= Leading industry groups suggested on July 16 that they may exclude material from widely used search engines unless the authors agree to attach subjective rating labels to all web pages and other online information. Less than three weeks after the Supreme Court struck down the Communications Decency Act, a far more sweeping proposal to restrict information available on the Internet -- "filtering," "blocking" and rating online content -- was touted at a White House summit meeting. Announcing the Administration's "Strategy for a Family Friendly Internet," President Clinton described the private sector initiative that will presumably preclude the need for new content-control legislation: For ["family-friendly"] controls to work to their full potential, we also need to encourage every Internet site, whether or not it has material harmful for young people, to label its own content as the Vice President described just a few moments ago. To help to speed the labeling process along, several Internet search engines -- the Yellow Pages of cyberspace, if you will -- will begin to ask that all Web sites label content when applying for a spot in their directories. I want to thank Yahoo, Excite and Lycos for this important commitment. You're helping greatly to assure that self- labeling will become the standard practice. And that must be our objective. While such an approach might seem preferable to CDA-type legislation at first glance, it raises the specter of an Internet where only the equivalent of "PG" rated content could be found through the search engines users have come to depend on. EPIC is encouraging users to contact the search services and oppose such rating requirements as fundamentally at odds with free speech principles. More information on filtering/blocking/rating, and contact information for the major search engines, is available at: http://www.epic.org/free_speech/censorware/ ======================================================================= [3] Another House Committee Approves SAFE Crypto Bill ======================================================================= The House International Relations Committee approved the SAFE encryption bill on July 22. The legislation, which had already been approved by the House Judiciary Committee, would substantially relax U.S. export controls on encryption. By a vote of 22-13, the committee rejected an amendment offered by Chairman Benjamin Gilman (R-NY) that would have permitted the President to maintain strict controls on the technology upon a finding that "the export of such items would adversely affect the national security." The Committee's rejection of Gilman's amendment was particularly significant, given that top officials from the FBI, National Security Council and the Drug Enforcement Agency took the unusual step of appearing before the panel to warn that use of encryption by criminals would hamper their ability to fight crime. Secretary of Defense William Cohen also transmitted a written appeal to the Committee members in which he urged rejection of the SAFE bill. While encryption reform efforts have moved forward in the House, prospects in the Senate are less promising. On June 18, the Senate Commerce Committee approved the Secure Public Networks Act (S. 909), which was introduced by Sens. Bob Kerrey (D-NE) and John McCain (R-AZ). That bill contains a number of coercive measures that would force widespread domestic adoption of key escrow encryption techniques The SAFE bill will now be considered by the Commerce, National Security, and Intelligence committees in the House, which are expected to vote on the legislation by early September. More information on the SAFE bill is available at: http://www.epic.org/crypto/ ======================================================================= [4] FTC Acts on Kids' Privacy ======================================================================= The Federal Trade Commission has found that a web site which collects data from kids and then sells it without notice is engaging in a deceptive business practice in violation of the Federal Trade Commission Act. The Center for Media Education brought the complaint against KidsCom on May 13, 1996, charging that the popular children's Web site was using deceptive and unfair practices to market to children. CME filed the petition in an effort to address the growing problem of deceptive and unfair marketing practices targeting children on the Web. The Commission's action marks the first formal articulation of policy by the agency's Bureau of Consumer Protection regarding what is permissible when marketing to children online. The FTC letter sets out broad principles that apply generally to online information collection from children. The FTC stated that: A practice is unfair under Section 5 if it causes, or is likely to cause, substantial injury to consumers which is not reasonably avoidable and is not outweighed by countervailing benefits to consumers or competition.(11) We believe that it would likely be an unfair practice in violation of Section 5 to collect personally identifiable information, such as name, e-mail address, home address or phone number, from children and sell or otherwise disclose such identifiable information to third parties without providing parents with adequate notice, as described above, and an opportunity to control the collection and use of the information. Because KidsCom changed the operation of its website after the CME complaint was filed, the FTC said that it would take no enforcement action. The FTC letter concluded: We will continue to monitor KidsCom, as well as other commercial Web site operators, to ascertain whether they may be engaged in deceptive or unfair practices. Hereafter, staff may recommend law enforcement proceedings against marketers who engage in deceptive information practices, or who unfairly use personally identifiable information collected from children. FTC Letter Ruling is available at: http://www.ftc.gov/os/9707/cenmed~1.htm CME Statement is available at: http://tap.epn.org/cme/ftc716.html ======================================================================= [5] Cellular Phone Group Asks FCC to Set Wiretap Standards ======================================================================= The Cellular Telephone Industry Association (CTIA) on July 16 asked the Federal Communications Commission to step in to help develop the standards for wiretapping under the Communications Assistance for Law Enforcement Act (CALEA). The telephone industry and the FBI have been quietly meeting for two years to develop the new standards required by the law. The CTIA is objecting to additional FBI demands not included in the law such as that cellular phones function as tracking devices. In a July 15 letter to FBI Director Louis Freeh, the head of CTIA, Thomas Wheeler, called the FBI position "intractable" and detailed how FBI and law enforcement objections prevent an industry-sponsored standard from being adopted. In response, the Bureau called the CTIA action a "short circuit" of the standards process and denied that it was seeking additional powers. Both the industry position and the FBI demands are problematic from a privacy perspective, as both would facilitate easier wiretapping and the collection of transactional information. CALEA requires that all telecommunications providers redesign their systems by October 1998 to make wiretapping of new communications technologies easier. Phone companies are eligible to receive $500 million from the FBI to implement the new systems. More information on CALEA and wiretapping is available from: http://www.epic.org/privacy/wiretap/ ======================================================================= [6] New Bills in Congress ======================================================================= H.R. 2180. On-Line Copyright Liability Limitation Act. Would limit liability for online service providers that are not aware that copyrighted materials are going over their networks. Introduced by Rep. Coble (R-NC) on July 16. Referred to the Committee on the Judiciary. H.R.2198. Genetic Privacy and Nondiscrimination Act of 1997. Would limit use and disclosure of genetic information by health insurance companies; prohibit employers from attempting to acquire, or to use, genetic information, or "to require a genetic test of an employee or applicant for employment" or to disclose the information. Introduced by Rep. Stearns (R-FL) on July 17. Referred to the Committee on Commerce, and in addition to the Committees on Government Reform and Oversight, Education and the Workforce, and Veterans' Affairs. An up-to-date list of pending legislation is available at: http://www.epic.org/privacy/bill_track.html ======================================================================= [7] New at the EPIC Bookstore ======================================================================= The EPIC Bookstore includes a wide range of books on privacy, cryptography and free speech that can be ordered online. Many of the books are available at up to 40 percent off list price. New titles include: "Protect Your Privacy on the Internet" by Bryan Pfaffenberger "Digital Cash" by Peter Wayner "Contested Commodities" by Margaret Jane Radin Other popular titles: "The Right to Privacy" by Ellen Alderman & Caroline Kennedy "Who Knows: Safeguarding Your Privacy in a Networked World" by Ann Cavoukian & Don Tapscott "Applied Cryptography, 2nd Edition" by Bruce Schneier We are also now featuring _The Tin Drum_ by Gunther Grass. The novel, a bizarre but extraordinary diary of a young boy who refuses to grow up during the rise and fall of Nazi Germany, is considered by some the greatest German novel written since WWII. In 1979, the film version of the Tin Drum received an Academy Award for Best Foreign Film. However, in recent months, groups that oppose "pornography" have persuaded the Oklahoma City Library to remove copies of the film from the public library. For this reason, we are now making the book available at the EPIC Bookstore. Support the Freedom to Read. Check out the EPIC Bookstore at: http://www.epic.org/bookstore/ ======================================================================= [8] Upcoming Conferences and Events ======================================================================= Hacking In Progress. August 8-10, 1997. Almere, Netherlands. Sponsored by Hac-Tic. Contact: http://www.hip97.nl/ Beyond HOPE. August 8-10, New York City. Sponsored by 2600. Contact: http://www.2600.com. TELECOM Interactive 97. September 8-14, 1997. Geneva, Switzerland. Sponsored by the International Telecommunications Union. Contact: telecom-interactive(a)itu.int or http://gold.itu.int/TELECOM/int97/ Cryptography and The Internet: Developing Privacy and Security Policy for the European Information Society. September 15, 1997. Brussels, Belgium. Sponsored by Privacy International. Contact: ast3(a)privacy.org. http://www.privacy.org/pi/conference/brussels/ 19th Annual International Privacy and Data Protection Conference. September 17-18, 1997. Brussels, Belgium. Sponsored by Belgium Data Protection and Privacy Commission. Email privacy(a)infoboard.be International Conference on Privacy. September 23-26, 1997. Montreal, Canada. Sponsored by Lavery, de Billy (corporate law firm). http://www.confpriv.qc.ca/ Managing the Privacy Revolution '97. October 21-23, 1997. Washington, DC. Sponsored by Privacy and American Business. Contact: http://shell.idt.net/~pab/conf97.html RSA'98 -- The 1998 RSA Data Security Conference. January 12-16, 1998. San Francisco, CA. Contact kurt(a)rsa.com or http://www.rsa.com/conf98/ (Send calendar submissions to alert(a)epic.org) ======================================================================= The EPIC Alert is a free biweekly publication of the Electronic Privacy Information Center. To subscribe, send email to epic-news(a)epic.org wih the subject: "subscribe" (no quotes) or use the subscription form at: http://www.epic.org/alert/subscribe.html Back issues are available at: http://www.epic.org/alert/ ======================================================================= The Electronic Privacy Information Center is a public interest research center in Washington, DC. It was established in 1994 to focus public attention on emerging privacy issues such as the Clipper Chip, the Digital Telephony proposal, national ID cards, medical record privacy, and the collection and sale of personal information. EPIC is sponsored by the Fund for Constitutional Government, a non-profit organization established in 1974 to protect civil liberties and constitutional rights. EPIC publishes the EPIC Alert, pursues Freedom of Information Act litigation, and conducts policy research. For more information, e-mail info(a)epic.org, http://www.epic.org or write EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington, DC 20003. +1 202 544 9240 (tel), +1 202 547 5482 (fax). If you'd like to support the work of the Electronic Privacy Information Center, contributions are welcome and fully tax-deductible. Checks should be made out to "The Fund for Constitutional Government" and sent to EPIC, 666 Pennsylvania Ave., SE, Suite 301, Washington DC 20003. Individuals with First Virtual accounts can donate at http://www.epic.org/epic/support.html Your contributions will help support Freedom of Information Act and First Amendment litigation, strong and effective advocacy for the right of privacy and efforts to oppose government regulation of encryption and funding of the National Wiretap Plan. Thank you for your support. ---------------------- END EPIC Alert 4.11 ----------------------- .. ------- David Banisar (Banisar(a)epic.org) * 202-544-9240 (tel) Electronic Privacy Information Center * 202-547-5482 (fax) 666 Pennsylvania Ave, SE, Suite 301 * HTTP://www.epic.org Washington, DC 20003 * PGP Key http://www.epic.org/staff/banisar/key.html

1 0

Reference.Com wants to pay listowners to send ads to their lists
by dlv＠bwalk.dm.com 17 Dec '03

17 Dec '03

One of my many hats is the owner of a very technical mailing list with about 400 subscribers. I received the following unsolicited e-mail from reference.com, which I'm reposting without comment: ]Received: (from eansender@localhost) ] by bilbo.reference.com (8.8.5/8.8.4) ] id GAA15443 for DLV(a)DM.COM; Thu, 24 Jul 1997 06:15:14 -0700 (PDT) ]Date: Thu, 24 Jul 1997 06:15:14 -0700 (PDT) ]From: ean(a)reference.com ]Message-Id: <199707241315.GAA15443(a)bilbo.reference.com> ]To: DLV(a)DM.COM ]Subject: InReference Email Ad Network Information ] ]Dear List Owner, ] ]As a listowner, you may have heard about us. We're InReference, Inc. We're ]the developers of Reference.COM, the Internet's most comprehensive resource ]for accessing Internet forums. We allow business and home users to easily ]search, find, browse and participate in more than 150,000 worldwide web ]forums, USENET newsgroups and email lists. Even though you're not currently ]archiving your list with Reference.COM, we thought we'd let you know about a ]new service from InReference that may be of interest. We understand the ]pressures on your time, so thanks in advance for hearing us out. ] ]During the past year, we've been approached by numerous list owners ]asking for help finding sponsors for their lists. While a few lists are ]already funded, others would benefit from additional financial support. ]The reasons are many. Perhaps the listowner needs helps supporting day-to-day ]operations. Or perhaps there's a desire to grow the list. ] ]We've also been approached by many would-be sponsors, socially-responsible ]companies that wanted to do email advertising the right way--with the ]cooperation and support of the list owner. ] ]To address this need, we've started the InReference email ad network (EAN). ]Basically, we match you up with advertisers fitting a preference profile that ]you create. We handle ad sales, insertion, auditing, billing, and so on. It ]costs nothing to sign-up, and can generate $0.01-0.05/ad/subscriber depending ]on the list. As a list owner, you choose the type of ad (whether banner or ]standalone) and the frequency of ad insertion. You also have the right to veto ]any ads before they can be sent out. ] ]A more detailed description of EAN can be found at the following URL : ] http://www.inreference.com/ean ]Should your interest warrant it, details on signing up can be found at : ] http://www.inreference.com/ean/listinfo.html ] ]Regards, ] ]Jack Zoken ]President ]InReference, Inc. ] ]PS: Regardless of whether you sign-up for EAN, we'd welcome the opportunity to ]archive your list at Reference.COM. See __________ to submit your list for ]inclusion.

2 1

No Subject
by Mix 17 Dec '03

17 Dec '03

Timmy May's 16Kb brain's single convolution is directly wired to his rectum for input and his T1 mouth for output. That's 16K bits, not bytes. Anal intercourse has caused extensive brain damage. o o Timmy May o \_/

2 1

Re: Attorneys: RSA patent invalid
by Michael C Taylor 17 Dec '03

17 Dec '03

At 05:29 PM 23/07/97 -0700, you wrote: >$25K upfront is prohibitively expensive for freeware and >for garage-shop programmers. It's a drop in the bucket for a >large project such as Netscape that wants to add some security, >but in a 3-person-month email widget it's excessive. > >On the other hand, it's now possible to license RSAREF for a much >more reasonable fee from Concentric; I think it's just per-copy >rather than a big up-front hit. As of March, 1997 Consensus Development (www.consensus.com) stopped licensing RSAREF for a very reasonable amount (~$200 US + 2-3% range I think it was??) Consensus' "SSL Plus" toolkit requires licensee to also license BSAFE from RSADSI. Maybe too many people were using commerical RSAREF licenses rather than the BSAFE toolkit. -M

1 0

Revisionist Reinterpretation
by chen＠intuit.com 17 Dec '03

17 Dec '03

Blanc writes: > Responding to msg by Jim choate, quoting another: > > >> We might also add Shay's Rebellion, Bacon's > >Rebellion, the Hudson > >> River Renters' Uprising, the Pullman Strike, the > >Homestead Strike, the > >> Ludlow Massacre, the Lawrence Textile Strikes, etc., > >etc. Many of > >> these were full-scale insurrections. This country's > >"progress" is > >> really just a series of grudging concessions made by > >authoritarian > >> power structures to various nearly catastrophic > >crises. > > I have a hard time comparing any of these histricaly > important but comparatively minor events to the half a > million dead of the Civil War or the 50,000+ dead of > Vietnam. Perhaps you have extended the analogy a > little too far?... > .......................................................... > > I think he was talking about the Principle of the deal, Jim - > about what this means regarding the relationship of the > citizenry to the big G. > Put all of those insurrections together and what do they spell? > > F _ _ _ _ _ F Blanc is right. You are correct, Jim, in that in terms of destruction, the wars you mention surpass in magnitude the other events that I listed (though I'll point out that if we count Indochinese dead, Vietnam's cost was far higher than 55,000, even if we add in the more than 60,000 who committed suicide in the aftermath). What I am really saying is that we are not, even in "normal" times, the slightly rambunctious but contented citizenry that popular mythology makes us out to be. This country has serious problems, and it always has. I think that we may be in agreement on this. Another good point that you've made elsewhere is the importance of economics as a motivator. I believe that you are exactly right. I'd like to add more, and also to say something about the perceptive comments from John Young, but I think I have a flu, so I'll go home and pick this up again on Monday. Meanwhile, wishing you all a good weekend. . . . - Mark - -- Mark Chen chen(a)netcom.com 415/329-6913 finger for PGP public key D4 99 54 2A 98 B1 48 0C CF 95 A5 B0 6E E0 1E 1D

1 0

Re: your mail
by nobody＠soda.berkeley.edu 17 Dec '03

17 Dec '03

What do you put in the Subject: line of an encrypted or anonymous message? We need something standard to prevent traffic analysis on this field. My suggestion is always to put "Subject: Re: your mail", since so much mail already has that, due to a feature of the popular mailer elm. If there is no standard, one could correlate Subject: patterns with people. Notice this message has been sent through "fmt" (and almost through "spell") to remove more nuances. Next we need an English-to-bland-English translator that smooths over individual language features (unless you're practicing stegonagraphy, then you want one that inserts them!)

2 1

Gopher access to Federal Register
by gnu 17 Dec '03

17 Dec '03

Gopher to gopher.internet.com, port 2002, and you will find the Federal Register online. For most documents, you can only get the first 100 lines, but the use of the indexes is free, and many documents are useful in this form. You can pay them for access to the full documents, but they prohibit republishing online -- though you're free to print the documents out. What heart these guys have! John

2 1

Source code
by David Colston 17 Dec '03

17 Dec '03

In case any one is interested, I have the source code for a non-RSA public key system. I wrote it in Microsoft PDS 7.1, which is a version of quick basic. It does 1024 bit keys and I can out run PGP in Basic<G>. If anyone out there is a semi-mathematical type, I will also furnish a paper on the subject. Since this is non-RSA and I'm sure everyone reading this is in the U.S., I don't think I'm involation of ITAR<G>. Uncle Dave

1 0

Re: Standard Headers for Anonymous Remailers
by Eli Brandt 17 Dec '03

17 Dec '03

> From: gtoal(a)an-teallach.com (Graham Toal) > Actually it wasn't the content of the articles that narked me, it was > that I actually wanted to *reply* to the authors. However the subjects > were way too off-topic to be worth responding to in public, which is > the only option the anonymous remailers allows. Though it's a bit clunky to use, the present remailers do support return addressses. I will admit that I haven't seen anybody supply one. Eli ebrandt(a)jarthur.claremont.edu

1 0

Bidzos on PGP and ITAR verbatim
by L. Detweiler 17 Dec '03

17 Dec '03

Bidzos comments on PGP related to ITAR, from sci.crypt a while ago (not sure of date). Essential argument: it was illegally exported, and ITAR prohibits re entry of things illegally exported, therefore it is illegally imported. Relevant section, Software export: Section 123.2 of the ITAR reads: >"123.2 Imports. > >No defense article may be imported into the United States unless (a) >it was previously exported temporarily under a license issued by the >Office of Munitions Control; or (b) it constitutes a temporary >import/intransit shipment licensed under Section 123.3; or (c) its >import is authorized by the Department of the Treasury (see 27 CFR >parts 47, 178, and 179)." There is a section on `illegal export of unclassified technical data to foreign nationals' (paraphrase) and Bidzos claims it applies to PGP export. But he appears to me to be using a bit of sleight of hand to conflate this category with *cryptographic software* mentioned elsewhere (sections also as quoted also by H. Finney). I'll let others pick it apart for the loopholes. ===cut=here=== Date: Mon, 20 Sep 93 19:31:08 PDT Message-Id: <9309210231.AA16113(a)RSA.COM> To: ld231782(a)longs.lance.colostate.edu In-Reply-To: "L. Detweiler"'s message of Mon, 20 Sep 93 19:57:35 -0600 <9309210157.AA04992(a)longs.lance.colostate.edu> Subject: PGP & ITAR Here's the ITAR part. (This was posted in 1992, so I don't know, since pgp has changed since then I understand, how it would apply.) Also, the ITAR has changed recently, and I haven't studied the changes to see how they would affect these comments. Risks of using pgp One should be careful about assuming that the documentation in electronically distributed software is accurate, especially where law is concerned. There are a few things the documentation for a program called "pgp" does not tell you about patent and export law that you should be aware of. Further, there are a number of claims and offered interpretations of patent and export law that are simply false. pgp seems to be an attempt to mislead netters into joining an illegal activity that violates patent and export law, letting them believe that they run no serious risk in doing so. EXPORT LAW pgp leads users to believe that it has circumvented export controls "...since it is not illegal to import..." You are led to believe that since you didn't import it, it's legal to use it. The "no import restrictions" claim has been made so many times, many people probably believe it. One would be well advised not to accept this legal opinion. While stated as if it were a well-known fact, the claim that "there are no import restrictions" is simply false. Section 123.2 of the ITAR (International Traffic in Arms Regulations) reads: "123.2 Imports. No defense article may be imported into the United States unless (a) it was previously exported temporarily under a license issued by the Office of Munitions Control; or (b) it constitutes a temporary import/intransit shipment licensed under Section 123.3; or (c) its import is authorized by the Department of the Treasury (see 27 CFR parts 47, 178, and 179)." Was pgp illegally exported? Was pgp illegally imported? Of course. It didn't export or import itself. pgp 1 was illegally exported from the U.S., and pgp 2, based on pgp 1, is illegally imported into the U.S. Is a license required? According to the ITAR, it is. 125.2 Exports of unclassified technical data. Paragraph (c) reads: "(c) Disclosures. Unless otherwise expressly exempted in this subchapter, a license is required for the oral, visual, or documentary disclosure of technical data to foreign nationals in connection with visits by U.S. persons to foreign countries, visits by foreign persons to the United States, or otherwise. A license is required regardless of the manner in which the technical data is transmitted (e.g., in person, by telephone, correspondence, electronic means, telex, etc.)." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What is "export?" Section 120.10, "Export," begins: "'Export' means, for purposes of this subchapter: ...(c) Sending or taking technical data outside of the United States in any manner except that by mere travel outside of the United States by a person whose technical knowledge includes technical data; or..." Crypto software is controlled by the ITAR. See Part 121, the Munitions List, includes Category XIII, of which paragraph (b) reads, in part, "...privacy devices, cryptographic devices and software (encoding and decoding), and components specifically designed or modified therefore,..." A further definition in 121.8, paragraph (f) reads: "Software includes but is not limited to the system functional design, logic flow, algorithms, application programs, ..." pgp encourages you to post it on computer bulletin boards. Anybody who considers following this advice is taking quite a risk. When you make a defense item available on a BBS, you have exported it. pgp's obvious attempts to downplay any risk of violating export law won't help you a bit if you're ever charged under the ITAR. Penalties under the ITARs are quite serious. The ITARs were clearly designed to put teeth into laws that make exporting munitions illegal. It's unfortunate that cryptography is on the munitions list. But it is. pgp is software tainted by serious ITAR violations. ------- End of Forwarded Message

7 8

GOPHER: now on port 70
by Karl Lui Barrus 17 Dec '03

17 Dec '03

Cypherpunks, Chael has made the necessary changes, and the cypherpunks gopher now listens to port 70 as standard gophers do... So 'gopher chaos.bsu.edu' or 'gopher 147.226.53.28'. I will look into announcing the site to the gopher list maintainers at UMN; perhaps some sites that are able to look up chaos.bsu.edu consistently will consider including a pointer to us! Karl Barrus <klbarrus(a)owlnet.rice.edu>

1 0

Why RSA?
by derek＠cs.wisc.edu 17 Dec '03

17 Dec '03

Is there some reason that we shouldn't pick a different public key encryption algorithm than RSA to use as a freely-available standard? The PGP docs imply that "almost" all practical such schemes are patented, implying that some are not. The legitimacy problems of PGP are a major roadblock to widespread use of encryption, IMO. Let's get something in the public domain! derek

3 3

jarthur is running pgp 2.3
by Eli Brandt 17 Dec '03

17 Dec '03

Just tested a 2.3-encrypted message through here, and it seems to be working. Share and enjoy. Eli ebrandt(a)jarthur.claremont.edu

1 0

Master Key: A Clipper Story
by remailer＠netcom.com 17 Dec '03

17 Dec '03

MASTER KEY ~~~~~~ ~~~ by Infocalypse an36586(a)anon.penet.fi September 21, 2002 This file contains important information regarding the Skipjack standard encryption system. Please read this file through before coming to any conclusions. Please do not ask me who I am. I have no intention of revealing my identity. I will start at the beginning. The Skipjack encryption system, initially known as Clipper, was first publicly announced in mid- 1993. After an initial storm of controversy died down, escrow agents were selected and the chip went into production in early 1994. Several major hardware vendors used Skipjack, and sales began to accelerate in the third quarter of 1994 as business users recognized the advantages of the convenient, inexpensive, and highly secure system. By the first quarter of 1995, Mykotronx could no longer keep up with the orders, and demand was still increasing rapidly. Several other electronics companies came forward, arguing that they could manufacture Skipjack chips more cheaply than Mykotronx, in larger volume, and with at least equal security. The NSA hesitated to give more companies its classified algorithm, but at the same time, they certainly did not want Skipjack to die from lack of available hardware just as it was becoming a standard. After a delay and threats of restraint-of-trade lawsuits, NIST released a set of security requirements. Any company which met them could receive the classified algorithm and make Skipjack chips. Numerous companies jumped in immediately. By Christmas 1995, the price of Skipjack chips had fallen sharply. Secure telephones were rapidly becoming a consumer product, just as the telecom companies started their Christmas advertising drive. Remember these slogans? "This Christmas, Give The Gift Of Privacy. AT&T Secure Telephones!" "Motorola Secure Cellular Network. Because It's Nobody's Business But Yours!" The promotion worked - secure phones were the hottest-selling product of the season. At the start of 1996, there was an installed base of over ten million, with no end in sight. Companies were making secure faxes, secure modems, secure LAN's, and secure microwave systems. The long-awaited crypto revolution had begun, and NSA was thrilled. Skipjack would soon be used for all types of business communications as well as telephones - everything which needed protection could be taken care of with a single solution. At the time, I was a senior in college and working evenings for a company which had just received its security clearance. I did not have access to any classified data; my job was to operate and maintain their front-end system, which took orders, kept track of stock, etc. There was a separate, isolated LAN for the classified work of designing and programming chips. The company tried to follow all of the technical rules, but the people were hackers and businesspeople, not spooks. And most security problems are people problems. My boss did have a security clearance. He was working late one Friday on one of the classified machines used to write microcode. When everyone else had left, he asked me to fix a problem with the network. That was a violation of security, but I did know more about networks than he did, and all the classified data was supposed to be locked up for the weekend. The safe had a time lock, which could not be opened until Monday. My boss had made a mistake while he was logged in as root, and he did an excellent job of hosing the file server. He was not supposed to have the root password at all. He'd had an argument with his supervisor about computer access. The supervisor refused to give him the password, so he stole it. Now his ass was on the line - if the file server wasn't fixed by the next morning, he was history. He didn't exactly admit it all at once, but that's what happened. We took a look at the damage, and began the long, slow job of recreating the filesystems, reinstalling Unix, restoring the data from backup tapes, and, most importantly, hiding the evidence. By 8 o'clock, we were both starved. I was doing most of the work - he was watching, reading manuals, and sweating bullets - so he decided to go for food. While waiting for a backup tape to run, I opened the desk drawer out of boredom, and - whoops! - there was a manual stamped SECRET. Some programmer was using it to write the microcode for a new low- power CMOS Skipjack chip, and he hadn't locked it up. After all, this is a secure building. Nobody without a security clearance is even allowed in this room, right? So what's the big deal? People problems! I couldn't resist taking a look, and there was a complete description of the Skipjack algorithm, among other things, with each page marked SECRET at the top and bottom. I had about 20 minutes until my boss returned. There was a Xerox machine, warmed up and ready to go, in the next room. What would you do? So I stood there, turning pages and hitting the button, listening to my heart pound, waiting for the click of the outer door as my boss walked in. I wasn't hungry any more. If I heard that click, I had just enough time to toss everything behind the copier, run back to the workstation, and hope to put the manual back later. But there was no click. By the time my boss returned with a pizza, the copies were in my car and the manual was in the drawer. My appetite returned with a vengeance as the adrenaline wore off. By 2 am, the machine was restored to normal. My boss shook my hand and thanked me, and then I went home and passed out cold. The next day, I woke up around noon and took a look at my loot. The algorithm strongly resembles DES. It's a highly improved DES, of course, but the structure is similar. It uses 32 rounds, and an 80- bit key, and they process the key before using it to eliminate weak keys. I started coding it at home in C to hack around with, not having any particular plans as to what I'd do with it. I was just enjoying the thrill of having something few others had. The program worked, but it was horribly slow. Skipjack is optimized for a pipelined hardware implementation, using 32 processing elements, one for each round. Even a good software implementation is almost uselessly slow. Once I had the basic electronic-codebook function working, I started implementing the rest of the Skipjack protocol around it. After a month of on-and-off hacking, I had a complete software clone of a Skipjack chip, which could be assigned any serial number and device-unique key. Without the family key, however, there was no way to create a proper LEAF. The version of Skipjack in this file is much improved, but similar in structure, to the original. For a long time, that was all I did with it. Without hardware, it wasn't fast enough for a no-LEAF secure telephone. I scanned the copies I'd made, encrypted the image files, and made a bonfire with the paper copies. Not the kind of thing one should keep around. Then I started experimenting with a programming technique called genetic algorithms. These are algorithms which evolve their outputs by creating successively better results. Multiple results are generated and evaluated, the best are copied, the rest erased. The remaining ones are then "crossed", simulating sexual reproduction, and the cycle repeats. Looking for an application, I decided to see how far a genetic algorithm could go in attacking Skipjack. At the time, I'd have been thrilled if it broke one round. What happened next - I didn't do it! I didn't know then and don't know now how it works. Using keys as the strings my algorithm would create was no good. Genetic algorithms make incremental progress; with crypto, if one bit is off, it's useless. Instead, my strings were programs written in a little interpreted language, specifically designed for cryptography. The genetic algorithm would evolve programs. This approach has been used for various things in the past. I started out with less than a round, with only the first transformation of the first round. The genetic algorithm wrote a program to solve that, no problem. But as I made it harder, using more of the round, it failed to progress. So I tried something new: there are programs which clean up spaghetti code, making readable and usable code out of it. They are used to make 30-year-old Cobol maintainable. I used one to take the most successful programs which evolved, clean them up, and add them to the language itself as new commands. When it got to the second round, the blocks out of which those programs were built included the most successful methods used against the first round. This way the program could build on its own successes. The computer ran 24 hours a day, and it progressed as far as the fifth round. I was surprised that it worked at all, but I didn't know if five rounds was good or bad. There has never been any public research with Skipjack, but DES is much easier to break if fewer rounds are used, so I assumed I hadn't really done much. Before leaving for a weekend, I made several changes to the program: improvements to the crossover routines, removing old, nonuseful commands added by the evolver, and code which increased the difficulty, one piece of one round at a time, each time the programs were successful. There were a few other changes. There were also several bugs in the program, including at least one wild pointer which scrambled some of the evolved functions. How these bugs affected the ultimate outcome, I don't know. Something like Frankenstein's lightning, I suppose. When I got back Sunday evening, I turned on the monitor and couldn't believe it. It had gone through all 32 rounds - cracked the code! Impossible, had to be a program bug. So I encrypted some text using the function I'd written, fed it in, and went to bed. The next morning, I expected the program to be crashed. Instead, there was the key. Somehow, I don't have a clue how, the algorithms evolve to fit each piece of ciphertext. They go down, like a diver taking treasure from a sunken ship, and pull those patterns to the surface. I've never been able to trace it. All the data looks random, but the solution emerges in the end. Much like neural networks: they can solve a problem, but they can't tell you how they did it. That's one reason why people don't trust neural nets. The next day, I kept trying it with different pieces of text. Imagine opening your trunk and finding it stuffed with cash - I kept opening it and looking to see if the money was really there. Sometimes it was faster than others, but it always worked as long as there was a pattern to the plaintext. I started acquiring equipment and components. 32 RAM-based logic array chips, similar to PAL's but using SRAM instead of ROM. One for each round. These I connected to form the equivalent of a Skipjack chip, equally fast but fully controllable. A used minivan. Nonmetallic composites are popular for car bodies - they may stop a bullet, but radio signals go right through them. No need for visible antennas on the outside. A new 8-gigabyte hard drive. Plenty of RAM for a disk cache. A software encryption program - I wasn't about to use Skipjack, and my hard drive would need encrypting. A small microwave dish and receiver - they've replaced cable, carrying TV and all kinds of data transmissions. Encrypted with Skipjack, of course. By this time, mid-1997, Skipjack had already gone global. Most of the money transferred around the world moves by Skipjack. Almost all large corporations use it for their voice, data, and fax networks. It has been designed into the lowest levels of the new Information Superhighway under construction, and has replaced RIPEM as the official privacy standard on the Internet. Each country keeps escrows for all chips manufactured and used within its borders. These are used for national law enforcement. The United Nations has a master escrow, containing all of the keys in the world. This is used to police international terrorism, arms and drug trafficking, etc. There are, of course, very strict rules governing when and to whom the UN will release keys. This system works very well. It has put the squeeze on drug money like nothing that came before it, because the large cash transaction stands out in a world of electronic money. All major crimes are difficult - the Mafia is nearly extinct. ATM and credit card fraud are almost a thing of the past - the Skipjack smart card has replaced the mag stripe and the card number. New phones have a slot, rather than a built-in chip, allowing people to carry their identities wherever they go. I didn't counterfeit electronic money - that would eventually be noticed, and besides, I'm not a thief. Nor did I secretly transfer money to myself. I just drove to New York, one of many places where information worth billions of dollars moves everyday over microwave beams. Then I parked in the path of one, turned on my inverter - connected to four marine batteries; running out of power during a hot intercept is highly annoying - and powered up my scanner. Having cracked the family key, I could quickly extract the serial number from each transmission. The hardest part is deciding what, out of the gigabytes flowing by, to tap. Once I choose a transmission, I feed it to the genetic algorithm. If I get anything interesting, I keep that serial number, and I know to tap that chip again when I see the serial number. Perhaps I intercept the draft of your lousy quarterly earnings report, bouncing from one suit to another as they try to cover their asses. Then I sell your company short. Or if I intercept good sales figures, I buy your stock. Sometimes I buy options, although it's easier to lose your shirt that way. They aren't all winners - the market reacts strangely sometimes - but enough of them are to make me a millionaire in a couple of years. Besides, it wouldn't work if all my picks were accurate. Someone would get suspicious. I've really made very poor use of my luck. A corporation could have practically taken over the world. But it would have been detected eventually. By keeping it small and being careful, I've been successful. For the last five years, I've lived as a parasite, feeding on information and using it to my advantage. For a while, I went through a voyeuristic phase, driving down the freeway, tapping phone calls at random. That didn't stay interesting for very long; most phone calls are boring. So why am I revealing this now? Why would I give up my master key? Not willingly, I assure you. But I feel that I have no choice. Recently, there have been two unexplained crimes: large amounts of money have been electronically transferred from corporate accounts, simply vanishing. In both cases, the police have suspected an inside job. MIS and finance managers were arrested - and released, because there was absolutely no evidence against them. There was, in fact, no evidence at all. The money was just gone. The police may suspect an inside job, but I think otherwise. I am very familiar with such crimes, because I spent much of that first year planning them, thinking about how they could be accomplished. Someone else, I am convinced, has discovered the master key. I would suspect an organization, not an individual. Either they have corrupted the escrow system, or they have cracked the code too. And they do not intend to stop at personal wealth. From an offshore base, they could, in one day of frantic activity, hold the world economy hostage. Or they could drain us more slowly, over a period of a few weeks. The thefts were intended to provide them with capital and experience for what could be the greatest heist in the history of money. So what can I do to prevent this? I could go to the NCPI - the National Cryptography and Privacy Institute, formerly the NSA - and show them my system. They might throw me in the slammer for espionage and securities fraud. More likely, they would make me a deal - my freedom for my silence - and begin the long process of designing a new encryption algorithm. But they would not believe me when I told them that someone else had also cracked the code. The idea is almost too horrible for them to contemplate - the whole world runs on Skipjack - and without convincing evidence, there is no way they would believe me. I don't have any convincing evidence. Action has to be taken now, before it's too late, and there's only one way to cause that. Tell the secret. Publish the algorithm, publish the method of breaking it, and of course, publish this file, so people will understand why I did what I did. I will be flamed, called every name in the book and some that will be made up for the occasion. They may try to hunt me down. There will be chaos for a few days, maybe a few weeks. The world financial system will grind to a halt, as programmers work frantically around the clock. Software cryptography will have to be quickly installed, until a new hardware system can be designed. For now, incompatibility will return, efficiency will be reduced, and a lesson will be learned. Hopefully, the NCPI will not make the same mistake twice. Hopefully, they won't classify the algorithm next time. --==<< Infocalypse >>==-- (Binary file transmission follows this message)

3 2

MAIL: anonymous, positive reputations
by Karl Lui Barrus 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Earlier, Graham mentioned some concerns about anonymous mail; specifically it isn't easy to respond to the author, most messages are off topic, etc. (hopefully not referring to my posts sent through remailers :-) on topics like the cypherpunks gopher and caching remailers...) And some people are asking about marking anonymous mail (gopher plug: check the article "Why Mark Anonymous Mail?" at the gopher site in the "Anonymous Mail" section, contributed by Hal Finney sometime ago). Currently, I sign my posts sent through anonymous remailer, sometimes including my address at the bottom of the post itself. I know others do this as well - Hal Finney, probably others I can't think of. I am working on (and off as time constraints crop up) a positive reputation scheme for anonymous mail. My stab at this is somewhat modest: a program that sifts through elm mail folders (similar to the elm frm command) and produces a formatted list containing message number, email address of author (frm sometimes reports name and I like email addresses instead), and subject. BUT, instead of printing email address, if the message is pgp signed, report the signature instead. Under this program, the fact that an anonymous remailer was used is somewhat transparent since you would see who signed the document sent through a remailer. This would allow somebody to build up a positive reputation attached to a pgp signature (which could be fairly anonymous) and possibly help guide anonymous mail kill file users. Naturally, it would be best if it were easy to respond to an anonymous mail, if this were incorporated into mail programs, etc. but I have two problems: time constraints, and disk quota (I can't lay out the source code for elm, pgp, whatever else). I'm to the point where the script I include below does what I want expect check for digital signatures on letters. Since there isn't a pgp library (yet), the next step will be difficult since I'd rather not pipe the message through pgp just to get the signature, although for testing I'll implement something in the next few weeks. Here is the script: if anybody has input, speak up! I named it scan after the mh command it is a poor imitation of. Usage: 'scan foldername returns a formatted list of mail in the folder "foldername" Ug, I see an improvement I will make tonight: using getenv() to get my home directory instead of plugging it in directly: - ----------8< cut here >8---------- #!/usr/local/bin/perl #report email address and subject of messages in an elm folder #frm sometimes reports name and not email address - not that I # guarantee this works in all cases #simple version of mh scan command #Karl L. Barrus <klbarrus(a)owlnet.rice.edu> chdir "/home/klbarrus/Mail" || die "Can't cd to ~/Mail\n"; while (@ARGV) { $file = shift @ARGV; if (-T $file) { if (-z $file) { #zero length folders with no messages print "Folder $file has no messages\n"; } elsif (!open(FOLDER, "/home/klbarrus/Mail/$file")) { print STDERR "Can't open $file\n"; } else { $state = 1; #Look for a new message $num = 0; while (<FOLDER>) { if (/^From[^:]/) { #Delimits a new message $num++; $from = ""; $subject = ""; $state = 2; #Look for From: and Subject: } if ($state == 2) { #Already found a message; looking for headers /^Subject: (.*)/ && ($subject = $1); #match subject /^From: (.+)/ && ($from = $1); #match "From: add" /^From: (.+) <(.+)>/ && ($from = $2); #match "From: name <add>" /^From: (.+) $(.+)$/ && ($from = $1); #match "From: add (name)" if ($from ne "" && $subject ne "") { #found both headers $state = 1; #go back to looking for message delimiter write; } } } } } elsif (-d $file) { print STDERR "$file is a directory\n"; } } exit; format STDOUT_TOP =

1 0

Re: crypto import
by smb＠research.att.com 17 Dec '03

17 Dec '03

> if a law was broken. And Sternlight is right -- if they decide to i ndict, > they may throw in charges of importing IDEA ... THERE IS NO LAW AGAINST THE IMPORT OF CRYPTOGRAPHY! How many times does this idiocy have to be squashed? Perhaps not now, but the statutory and regulatory provisions exist: >From the ITAR: 120.1 -- General authorities and eligibility. (a) Section 38 of the Arms Export Control Act (22 U.S.C. 2778) authorizes the President to control the export and import of defense articles and defense services. 120.5 -- Relation to regulations of other agencies. If an article or service is covered by the U.S. Munitions List, its export is regulated by the Department of State, except as indicated otherwise in this subchapter. For the relationship of this subchapter to regulations of the Department of Commerce, the Department of Energy and the Nuclear Regulatory Commission, see ^U 123.20 of this subchapter. The Treasury Department controls permanent imports of articles and services covered by the U.S. Munitions Import List from foreign countries by persons subject to U.S. jurisdiction (31 CFR part 505). 123.2 -- Import jurisdiction. The Department of State regulates the temporary import of defense articles. Permanent imports of defense articles into the United States are regulated by the Department of the Treasury (see 27 CFR parts 47, 178 and 179). etc. I confess that I don't happen to have a copy of the Munitions Import List. Are you certain that crypto gear isn't on it? Are you certain it wasn't added last week? Or next? But the same authority -- dubious though it may be -- that lets them ban export of crypto would let them ban import if they chose to try. John PS: I heard a rumor it's against the law to breathe. Only if there's a coded message in the timing.

1 0

NIST Comment Deadline
by Dave Banisar 17 Dec '03

17 Dec '03

NIST Comment Deadline The September 28 deadline for the submission of comments on NIST's proposal to establish the "Skipjack" key-escrow system as a Federal Information Processing Standard (FIPS) is rapidly approaching. The full text of the NIST Federal Register notice follows. CPSR is urging all interested individuals and organizations to express their views on the proposal and to submit comments directly to NIST. Comments need not be lengthy or very detailed; all thoughtful statements addressing a particular concern will likely contribute to NIST's evaluation of the key-escrow proposal. The following points could be raised about the NIST proposal (additional materials on Clipper and the key escrow proposal, including comments already submitted to NIST, may be found at the CPSR ftp site, cpsr.org /cpsr/crypto/clipper): * The potential risks of the proposal have not been assessed and many questions about the implementation remain unanswered. The NIST notice states that the current proposal "does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys." The key escrow configuration may also create a dangerous vulnerability in a communications network. The risks of misuse of this feature should be weighed against any perceived benefit. * The classification of the Skipjack algorithm as a "national security" matter is inappropriate for technology that will be used primarily in civilian and commercial applications. Classification of technical information also limits the computing community's ability to evaluate fully the proposal and the general public's right to know about the activities of government. * The proposal was not developed in response to a public concern or a business request. It was put forward by the National Security Agency and the Federal Bureau of Investigation so that these two agencies could continue surveillance of electronic communications. It has not been established that is necessary for crime prevention. The number of arrests resulting from wiretaps has remained essentially unchanged since the federal wiretap law was enacted in 1968. * The NIST proposal states that the escrow agents will provide the key components to a government agency that "properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted." The crucial term "legal authorization" has not been defined. The vagueness of the term "legal authorization" leaves open the possibility that court- issued warrants may not be required in some circumstances. This issue must be squarely addressed and clarified. * Adoption of the proposed key escrow standard may have an adverse impact upon the ability of U.S. manufacturers to market cryptographic products abroad. It is unlikely that non-U.S. users would purchase communication security products to which the U.S. government holds keys. Comments on the NIST proposal should be sent to: Director, Computer Systems Laboratory ATTN: Proposed FIPS for Escrowed Encryption Standard Technology Building, Room B-154 National Institute of Standards and Technology Gaithersburg, MD 20899 Written submissions must be received by September 28, 1993 (CPSR asked NIST that provisions be made to allow for electronic submission of comments, but the agency recently rejected that suggestion). Please also send copies of your comments on the key escrow proposal to CPSR for inclusion in the CPSR Internet Library, our ftp site. Copies should be sent to <clipper(a)washofc.cpsr.org>. ================================================================= FEDERAL REGISTER VOL. 58, No. 145 DEPARTMENT OF COMMERCE (DOC) National Institute of Standards and Technology (NIST) Docket No. 930659-3159 RIN 0693-AB19 A Proposed Federal Information Processing Standard for an Escrowed Encryption Standard (EES) 58 FR 40791 Friday, July 30, 1993 Notice; request for comments. SUMMARY: A Federal Information Processing Standard (FIPS) for an Escrowed Encryption Standard (EES) is being proposed. This proposed standard specifies use of a symmetric-key encryption/decryption algorithm and a key escrowing method which are to be implemented in electronic devices and used for protecting certain unclassified government communications when such protection is required. The algorithm and the key escrowing method are classified and are referenced, but not specified, in the standard. This proposed standard adopts encryption technology developed by the Federal government to provide strong protection for unclassified information and to enable the keys used in the encryption and decryption processes to be escrowed. This latter feature will assist law enforcement and other government agencies, under the proper legal authority, in the collection and decryption of electronically transmitted information. This proposed standard does not include identification of key escrow agents who will hold the keys for the key escrow microcircuits or the procedures for access to the keys. These issues will be addressed by the Department of Justice. The purpose of this notice is to solicit views from the public, manufacturers, and Federal, state, and local government users so that their needs can be considered prior to submission of this proposed standard to the Secretary of Commerce for review and approval. The proposed standard contains two sections: (1) An announcement section, which provides information concerning the applicability, implementation, and maintenance of the standard; and (2) a specifications section which deals with the technical aspects of the standard. Both sections are provided in this notice. DATES: Comments on this proposed standard must be received on or before September 28, 1993. ADDRESSES: Written comments concerning the proposed standard should be sent to: Director, Computer Systems Laboratory, ATTN: Proposed FIPS for Escrowed Encryption Standard, Technology Building, room B-154, National Institute of Standards and Technology, Gaithersburg, MD 20899. Written comments received in response to this notice will be made part of the public record and will be made available for inspection and copying in the Central Reference and Records Inspection Facility, room 6020, Herbert C. Hoover Building, 14th Street between Pennsylvania and Constitution Avenues, NW., Washington, DC 20230. FOR FURTHER INFORMATION CONTACT: Dr. Dennis Branstad, National Institute of Standards and Technology, Gaithersburg, MD 20899, telephone (301) 975-2913. SUPPLEMENTARY INFORMATION: This proposed FIPS implements the initiative announced by the White House Office of the Press Secretary on April 16, 1993. The President of the U.S. approved a Public Encryption Management directive, which among other actions, called for standards to facilitate the procurement and use of encryption devices fitted with key-escrow microcircuits in Federal communication systems that process sensitive, but unclassified information. Dated: July 26, 1993. Arati Prabhakar, Director.(NIST) ---------------------------------------------------- Federal Information Processing Standards Publication XX 1993 XX Announcing the Escrowed Encryption Standard (EES) Federal Information Processing Standards Publications (FIPS PUBS) are issued by the National Institute of Standards and Technology (NIST) after approval by the Secretary of Commerce pursuant to section 111(d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. Name of Standard: Escrowed Encryption Standard (EES). Category of Standard: Telecommunications Security. Explanation: This Standard specifies use of a symmetric-key encryption (and decryption) algorithm and a Law Enforcement Access Field (LEAF) creation method (one part of a key escrow system) which provide for decryption of encrypted telecommunications when interception of the telecommunications is lawfully authorized. Both the algorithm and the LEAF creation method are to be implemented in electronic devices (e.g., very large scale integration chips). The devices may be incorporated in security equipment used to encrypt (and decrypt) sensitive unclassified telecommunications data. Decryption of lawfully intercepted telecommunications may be achieved through the acquisition and use of the LEAF, the decryption algorithm and escrowed key components. To escrow something (e.g., a document, an encryption key) means that it is "delivered to a third person to be given to the grantee only upon the fulfillment of a condition" (Webster's Seventh New Collegiate Dictionary). A key escrow system is one that entrusts components of a key used to encrypt telecommunications to third persons, called key component escrow agents. In accordance with the common definition of "escrow", the key component escrow agents provide the key components to a "grantee" (i.e., a government agency) only upon fulfillment of the condition that the grantee properly demonstrates legal authorization to conduct electronic surveillance of communications which are encrypted using the specific device whose key component is requested. The key components obtained through this process are then used by the grantee to reconstruct the device unique key and obtain the session key (contained in the LEAF) which is used to decrypt the telecommunications that are encrypted with that device. The term, "escrow", for purposes of this standard, is restricted to the dictionary definition. The encryption/decryption algorithm has been approved for government applications requiring encryption of sensitive unclassified telecommunications of data as defined herein. The specific operations of the algorithm and the LEAF creation method are classified and hence are referenced, but not specified, in this standard. Data, for purposes of this standard, includes voice, facsimile and computer information communicated in a telephone system. Telephone system, for purposes of this standard, is limited to systems circuit-switched up to no more than 14.4 kbs or which use basic-rate ISDN, or to a similar grade wireless service. Data that is considered sensitive by a responsible authority should be encrypted if it is vulnerable to unauthorized disclosure during telecommunications. A risk analysis should be performed under the direction of a responsible authority to determine potential threats and risks. The costs of providing encryption using this standard as well as alternative methods and their respective costs should be projected. A responsible authority should then make a decision, based on the risk and cost analyses, whether or not to use encryption and then whether or not to use this standard. Approving Authority: Secretary of Commerce. Maintenance Agency: Department of Commerce, National Institute of Standards and Technology. Applicability: This standard is applicable to all Federal departments and agencies and their contractors under the conditions specified below. This standard may be used in designing and implementing security products and systems which Federal departments and agencies use or operate or which are operated for them under contract. These products may be used when replacing Type II and Type III (DES) encryption devices and products owned by the government and government contractors. This standard may be used when the following conditions apply: 1. An authorized official or manager responsible for data security or the security of a computer system decides that encryption is required and cost justified as per OMB Circular A- 130; and 2. The data is not classified according to the National Security Act of 1947, as amended, or the Atomic Energy Act of 1954, as amended. However, Federal departments or agencies which use encryption devices for protecting data that is classified according to either of these acts may use those devices also for protecting unclassified data in lieu of this standard. In addition, this standard may be adopted and used by non- Federal Government organizations. Such use is encouraged when it provides the desired security. Applications: Devices conforming to this standard may be used for protecting unclassified communications. Implementations: The encryption/decryption algorithm and the LEAF creation method shall be implemented in electronic devices (e.g., electronic chip packages) that can be physically protected against unauthorized entry, modification and reverse engineering. Implementations which are tested and validated by NIST will be considered as complying with this standard. An electronic device shall be incorporated into a cyptographic module in accordance with FIPS 140-1. NIST will test for conformance with FIPS 140-1. Cryptographic modules can then be integrated into security equipment for sale and use in an application. Information about devices that have been validated, procedures for testing equipment for conformance with NIST standards, and information about obtaining approval of security equipment are available from the Computer Systems Laboratory, NIST, Gaithersburg, MD 20899. Export Control: Implementations of this standard are subject to Federal Government export controls as specified in title 22, Code of Federal Regulations, parts 120 through 131 (International Traffic of Arms Regulations -ITAR). Exporters of encryption devices, equipment and technical data are advised to contact the U.S. Department of State, Office of Defense Trade Controls for more information. Patents: Implementations of this standard may be covered by U.S. and foreign patents. Implementation Schedule: This standard becomes effective thirty days following publication of this FIPS PUB. Specifications: Federal Information Processing Standard (FIPS XXX)(affixed). Cross Index: a. FIPS PUB 46-2, Data Encryption Standard. b. FIPS PUB 81, Modes of Operation of the DES c. FIPS PUB 140-1, Security Requirements for Cryptographic Modules. Glossary: The following terms are used as defined below for purposes of this standard: Data-Voice, facsimile and computer information communicated in a telephone system. Decryption-Conversion of ciphertext to plaintext through the use of a cryptographic algorithm. Device (cryptographic)-An electronic implementation of the encryption/decryption algorithm and the LEAF creation method as specified in this standard. Digital data-Data that have been converted to a binary representation. Encryption-Conversion of plaintext to ciphertext through the use of a cryptographic algorithm. Key components-The values from which a key can be derived (e.g., KU sub 1 + KU sub 2). Key escrow -A process involving transferring one or more components of a cryptographic key to one or more trusted key component escrow agents for storage and later use by government agencies to decrypt ciphertext if access to the plaintext is lawfully authorized. LEAF Creation Method 1-A part of a key escrow system that is implemented in a cryptographic device and creates a Law Enforcement Access Field. Type I cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting classified information. Type II cryptography-A cryptographic algorithm or device approved by the National Security Agency for protecting sensitive unclassified information in systems as specified in section 2315 of Title 10 United State Code, or section 3502(2) of Title 44, United States Code. Type III cryptography-A cryptographic algorithm or device approved as a Federal Information Processing Standard. Type III(E) cryptography-A Type III algorithm or device that is approved for export from the United States. Qualifications. The protection provided by a security product or system is dependent on several factors. The protection provided by this standard against key search attacks is greater than that provided by the DES (e.g., the cryptographic key is longer). However, provisions of this standard are intended to ensure that information encrypted through use of devices implementing this standard can be decrypted by a legally authorized entity. Where to Obtain Copies of the Standard: Copies of this publication are for sale by the National Technical Information Service, U.S. Department of Commerce, Springfield, VA 22161. When ordering, refer to Federal Information Processing Standards Publication XX (FIPS PUB XX), and identify the title. When microfiche is desired, this should be specified. Prices are published by NTIS in current catalogs and other issuances. Payment may be made by check, money order, deposit account or charged to a credit card accepted by NTIS. Specifications for the Escrowed Encryption Standard 1. Introduction This publication specifies Escrowed Encryption Standard (EES) functions and parameters. 2. General This standard specifies use of the SKIPJACK cryptographic algorithm and the LEAF Creation Method 1 (LCM-1) to be implemented in an approved electronic device (e.g., a very large scale integration electronic chip). The device is contained in a logical cryptographic module which is then integrated in a security product for encrypting and decrypting telecommunications. Approved implementations may be procured by authorized organizations for integration into security equipment. Devices must be tested and validated by NIST for conformance to this standard. Cryptographic modules must be tested and validated by NIST for conformance to FIPS 140-1. 3. Algorithm Specifications The specifications of the encryption/decryption algorithm (SKIPJACK) and the LEAF Creation Method 1 (LCM-1) are classified. The National Security Agency maintains these classified specifications and approves the manufacture of devices which implement the specifications. NIST tests for conformance of the devices implementing this standard in cryptographic modules to FIPS 140-1 and FIPS 81. 4. Functions and Parameters 4.1 Functions The following functions, at a minimum, shall be implemented: 1. Data Encryption: A session key (80 bits) shall be used to encrypt plaintext information in one or more of the following modes of operation as specified in FIPS 81: ECB, CBC, OFB (64) CFB (1, 8, 16, 32, 64). 2. Data Decryption: The session key (80 bits) used to encrypt the data shall be used to decrypt resulting ciphertext to obtain the data. 3. Key Escrow: The Family Key (KF) shall be used to create the Law Enforcement Access Field (LEAF) in accordance with the LEAF Creation Method 1 (LCM-1). The Session Key shall be encrypted with the Device Unique Key and transmitted as part of the LEAF. The security equipment shall ensure that the LEAF is transmitted in such a manner that the LEAF and ciphertext may be decrypted with legal authorization. No additional encryption or modification of the LEAF is permitted. 4.2 Parameters The following parameters shall be used in performing the prescribed functions: 1. Device Identifier (DID): The identifier unique to a particular device and used by the Key Escrow System. 2. Device Unique Key (KU): The cryptographic key unique to a particular device and used by the Key Escrow System. 3. Cryptographic Protocol Field (CPF): The field identifying the registered cryptographic protocol used by a particular application and used by the Key Escrow System (reserved for future specification and use). 4. Escrow Authenticator (EA): A binary pattern that is inserted in the LEAF to ensure that the LEAF is transmitted and received properly and has not been modified, deleted or replaced in an unauthorized manner. 5. Initialization Vector (IV): A mode and application dependent vector of bytes used to initialize, synchronize and verify the encryption, decryption and key escrow functions. 6. Family Key (KF): The cryptographic key stored in all devices designated as a family that is used to create the LEAF. 7. Session Key (KS): The cryptographic key used by a device to encrypt and decrypt data during a session. 8. Law Enforcement Access Field (LEAF): The field containing the encrypted session key and the device identifier and the escrow authenticator. 5. Implementation The Cryptographic Algorithm and the LEAF Creation Method shall be implemented in an electronic device (e.g., VLSI chip) which is highly resistant to reverse engineering (destructive or non- destructive) to obtain or modify the cryptographic algorithms, the DID, the KF, the KU, the EA, the CPF, the operational KS, or any other security or Key Escrow System relevant information. The device shall be able to be programmed/personalized (i.e., made unique) after mass production in such a manner that the DID, KU (or its components), KF (or its components) and EA fixed pattern can be entered once (and only once) and maintained without external electrical power. The LEAF and the IV shall be transmitted with the ciphertext. The specifics of the protocols used to create and transmit the LEAF, IV, and encrypted data shall be registered and a CPF assigned. The CPF shall then be transmitted in accordance with the registered specifications. The specific electric, physical and logical interface will vary with the implementation. Each approved, registered implementation shall have an unclassified electrical, physical and logical interface specification sufficient for an equipment manufacturer to understand the general requirements for using the device. Some of the requirements may be classified and therefore would not be specified in the unclassified interface specification.

1 0

REMAIL: policy
by catalyst＠netcom.com 17 Dec '03

17 Dec '03

What follows is the policy for the remailer running at catalyst(a)netcom.com as of 21 Sept 1993: - 1 - I don't normally keep logs because (a) I lack the time to examine them; (b) I lack the space to keep them; and (c) frankly, I would rather _not_ know. If some exceptional situation requires it, I will temporarily log to resolve that situation. - 2 - I will block remailing to a given address on request and proof of identity by the owner. I run a remailer because I believe privacy is an inaliable human right. However, "Your right to swing your fist ends where my nose begins!". I will not condone, promote or aid the violation of other human rights in the name of privacy. Because I don't keep logs, I can do no more than block (nor would I wish to), although, see - 1 -. - 3 - I do not own the machine my remailer is running on. In fact it is a commercial system. Be nice. If they ask me to stop running my remailer on their system... I will. Additionally, you implicitly accept all the risks associated with trusting somebody elses machine. - 4 - I don't read mail that goes through my remailer _BUT_ it is my personal account, and personal mail addressed to me passes through it, therefore, if a message doesn't look like it contains remailer commands, the remailer assumes it must be to me and I get it. I read all mail that is addressed to me. The consequence is that poorly addressed messages intended to be remailed will be read by me. I will throw these messages away without responding, correcting, or forwarding them, as soon as I realize they were to have been remailed. Be aware that this can happen. I'm sure there is some threshold beyond which the content would force me to action in some way. What the content, threshold and possible actions are, I do not know. Protect yourself from this result by using multiple remailers and encrypting at each stage. - 5 - I am an engineer. I like to play. I probably cannot stop myself from constantly tweaking and growing the remailer code. It is, after all, an expermental system. The remailer you use today may not be the same one you get tomorrow. - 6 - I am a human being and suffer from all the associated frailties. When someone points a gun (actually or metaphorically) at me or my family, I must almost certainly comply with that entities wishes. I do NOT advocate law breaking and will comply with the law to the extent required and enforced; e.g., if the FBI comes to my door and says: "start logging your remailer, or shut it down" ("shut it down" might only be inferred <and, _no_, I didn't mean 'implied'>), then it is likely that I will comply to the extent required and enforced. - 7 - As with my kids: I reserve the right to change the rules at any time and for any reason; though I seldom exercise this right to explicitly revoke previously explicitly granted freedoms. - 8 - I run this remailer as a personal activity. It is in no way associated with my place of employment, my employer or the activities I engage in on the behalf of my employer. I run it out of a personal account on a commercial system that I pay for with my own money. If you have problems with the remailer, please talk to me first. If we can't resolve it, of course you can always report it to NetCom. - 9 - Finally, be aware that I am not _providing_ privacy. I am allowing it. That is, _you_ are the caretaker of your rights and must actively seek to protect them. I will help, but that is all I can do. If you wish to protect your privacy, I urge you to learn how and why these remailers (and other associated tools) work so that you can use them to the best advantage. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 5 Infinite Loop, MS 305-2B Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024:669687 catalyst(a)netcom.com

1 0

Re: Why RSA?
by derek＠cs.wisc.edu 17 Dec '03

17 Dec '03

First, the ViaCrypt version: I realize that it is legal. It's also very expensive when compared to the price of email readers/composers that people normally use (often weighing in at about $50 / seat). A $200 add-on is not likely to be universally accepted. It's as if somebody had patented car door locks and claimed that $40,000 was a reasonable price to have them included on a $10,000 car. I'm not complaining about the price; people can charge whatever they want for their products. However it does seem kind of high, creating market pressure... that market pressure surfaces in messages like this one and hopefully someday competing products from somebody. Perry Metzger: > All are patented in so far as one of the patents covers ALL public key > schemes. Some, like Rabin's scheme, have possible technical advantages > over RSA. I am just beginning to study the mathematics behind public key crypto (got Simmons's _Contemporary Cryptology_ from the library this morning), but I haven't seen anything about what exactly this means (that is, I haven't been able to "look it up"). I was under the impression that many people participated in the development of P.K.Crypto... how can somebody patent all of their work? Don't these kind of patents apply only to specific algorithms? Begging the indulgence of this list, two more questions: * is there a reference I can read that covers the scope of public key crypto patents? * in broad terms, what would I have to do to develop an algorithm that works from a user's perspective like p.k.c. (ie public/private keys, the central functional point of all the wonderful schemes based on pkc) but doesn't violate patents? Thanks! derek

4 3