December 2003 - cypherpunks-legacy

brutessl web keyservice
by David K. Merriman 17 Dec '03

17 Dec '03

Feh. I've been trying to get allocated some more keyspace from the brutessl web page, and keep getting timeouts. Last time, I requested 8 segments, got issued *3*. Dave Merriman This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th of the PGP executable. See below for getting YOUR chunk! ------------------ PGP.ZIP Part [015/713] ------------------- M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8@X'HB_9H#&\X MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3 M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/ <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> My web page: http://www.geopages.com/CapitolHill/1148

1 0

Attend Windows NT Intranet Solutions!
by announce＠lists.zdnet.com 17 Dec '03

17 Dec '03

----------------------------------------------------------------- ZDNET ANNOUNCEMENT 8/6/97 ----------------------------------------------------------------- Are you looking to evaluate the latest Windows NT products? Attend Windows NT Intranet Solutions August 11-15. What: Windows NT Intranet Solutions August 11-15 Where: Moscone Center -- San Francisco, CA When: August 11-15 Windows NT Intranet Solutions, the NT Event, features a conference and expo program focused on all the major NT issues: - Integrating Unix/NetWare and NT - Migrating applications to NT - NT scalability and clustering - Managing and securing NT networks and much more. The expert-led Conference program, co-sponsored by PC WEEK, Inter@ctive Week and Windows Sources, runs August 11-15 and the 3-day Expo, featuring all the leading vendors and the latest NT products and solutions, runs August 13-15. To register free for the Expo and get complete conference info, call (888)800-8920 or visit the Windows NT Intranet Solutions on the Web at: http://www.wintis.com Windows NT Intranet Solutions is presented by SOFTBANK Forums, the producers of NetWorld+Interop and Seybold Seminars. _______________________________________________________________ ZDNet Announcements are periodic notices of new features, special events and free offers available to members of ZDNet. --To subscribe to ZDNet Announcements, please send mail to: announce-on(a)lists.zdnet.com You can leave the subject and body blank. --To unsubscribe to ZDNet Announcements, please send mail to: announce-off(a)lists.zdnet.com You can leave the subject and body blank. _______________________________________________________________ Powered by Mercury Mail: http://www.merc.com

1 0

Re: Cypherpunk Brute Squad [Re: SSL Challenge: Server problems]
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> current requirements > ==================== > > PLEASE ensure that you are using a brclient of at least 0.14 > ("grep comment.inffo brclient" to discover what you are using) > You can updare brclient while brloop is running. > Some people are still running old versions, and this is hammering the server. > > It also helps to run at least brloop 0.05 ("grep BRLOOPCOMMENT brloop"). > Unfortunately the web page under "Socket based key doler" points at brclient 0.13 and brloop 0.04. Could you fix this please:) Thanks, Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

3 2

for perl experts: brclient problem
by Lou Poppler 17 Dec '03

17 Dec '03

I sent this originally only to Piete, but as I suspect he is already somewhat busy, I am now also forwarding a copy to the list. I just upgraded to brclient version 0.16. I tried to use it with this command: brclient -Ltssl -a'2977 6284 390a 3 no' I got this result: Use of uninitialized variable at ./brclient line 457, <COMMAND> line 1. Failed: 0 <No DATA> I am totally perl.clueless, so I merely refer this to you. :::::::::::::::::::::::::::::::::::::: :: Lou Poppler <lwp(a)mail.msen.com> :: No animals were harmed in the :: http://www.msen.com/~lwp/ :: production of this message. ::::::::::::::::::::::::::::::::::::::

1 1

adults only
by cindy＠mail1.mail-prom.com 17 Dec '03

17 Dec '03

TRY US OUT FOR FREE!!! See and talk to a live person on your computer screen. Not a video! Not prerecorded! This is live!!! Our models will obay your every cummand, we're willing to prove it by giving you a free 5 minute preview. Give it a try, it's free! - CLICK HERE

1 0

Costitutional Crisis
by Apache 17 Dec '03

17 Dec '03

5 Aug 1997 ========== Canberra AUSTRALIA The High Court of Australia in a land mark case today found that billions of dollars of taxes imposed every year on fuel, alcohol and tabacco which increases the prices of these products by up to several hundred percent were illegal and unconstitutional. The court found that the states had no legal right under the constitution to impose such taxes. The federal government has offered to help the states collect the revenue and pass it back to the states by way of grants. Calls have been made for the imposition of consumption taxes to replace the lost revenue. None of the state premiers made any comments regarding the return of the multi-billions in illegally collected assets to taxpayers. The illegal taxes continue to be collected even after the High Courts ruling. The finding has resulted in some panicing state premiers saying the High Court seemed to be intent on making the states ungovernable. The federal government worried about the possibility that taxpayers could sue the states for repayment of mult-billions of dollars in unconstitutionally collected taxes has announced it plans to introduce a 100% 'Unjust Windfall Tax' to confiscate the proceeds of winning claims. Legal experts believe such action by the federal government may in itself may be in breach of the constitution. -- Death to Tyrants Help Austalians re-instate the constitution

1 0

PGPfone (BETA TEST) is released
by Jeffrey I. Schiller 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- MIT is pleased to announce that it is now distributing the BETA TEST release of PGPfone. "PGPfone (Pretty Good Privacy Phone) is a software package that turns your desktop or notebook computer into a secure telephone. It uses speech compression and strong cryptography protocols to give you the ability to have a real-time secure telephone conversation." The Beta Test is only currently available for people with Macintosh computers. A Windows 95 version is also in the works. We are distributing PGPfone in the U.S. and Canada via anonymous FTP and via the World Wide Web. Anonymous FTP users should get the file "/pub/PGPfone/README" from net-dist.mit.edu. It provides instructions on how to download PGPfone. Web Users should go to the PGPfone Home Page at: http://web.mit.edu/network/pgpfone -Jeff -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMD4xcMUtR20Nv5BtAQGUqwQAmaOxhnbTyqdC5RicIEmiad8UbzdeJEXZ vfdzCZl4qm94JlohYAby/hDIFqo6cPW504o7CSoWPiEGDi7AYMEX0tq3wdAIdklR 2d/AqW45YWtPrfSdLjF8+xwI41kp/lYSqF9V9ZXycguENjdhd8bnI89tT3Ah20JF kL4q193/2O8= =9pv/ -----END PGP SIGNATURE-----

1 0

Re: "Voluntary Censorship" vs. Govt Legislation
by John Smith 17 Dec '03

17 Dec '03

Ryan Anderson writes: >The second thing, and most important, is that web search engines need >to >index *every* page, and allow the topical/categorization system as a >way >to further limit searchs. You can't make the web search engines do that. It's a free country. What you can do is to avoid the ones which have policies you don't like. If Altavista starts listing only rated sites, you can use a different search engine. Realistically, the percentage of rated sites is probably going to stay low for some time. The big ones will rate, though. So the question will be whether most people are happy with the "top 1%" sites, or whether they want access to the whole web. It seems to me that if you are using a search engine, you probably need access to more than just the big commercial sites. Rogue indexes which don't block unrated sites may have an advantage just in terms of usefulness, even aside from the politics. "John ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Approved Escrow Agents (forget GAK Motel)
by Jim Gillogly 17 Dec '03

17 Dec '03

Here are some discussion papers for the upcoming NIST-sponsored conference on 6-7 Sep 95 in DC. Note the footnote in the 2nd paper: (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. I'd been working on some GAK slogans based on Roach Motel... into the dumpster with "Keys go in, but they never come out!" -- too bad. Jim "GAK Motel" Gillogly Sterday, 3 Halimath S.R. 1995, 20:32 ___________________________________________________________________________ Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? - - - --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-mail: carlton(a)micf.nist.gov. 8/25/95 ___________________________________________________________________________

1 0

NIST Key Escrow Papers
by Dave Banisar 17 Dec '03

17 Dec '03

fyi... ---- August 25, 1995 MEMORANDUM FOR Registrants for the Sept. 6-7, 1995 Key Escrow Issues Meeting From: NIST - Ed Roback Subject: Discussion Papers Attached for your information are two discussion papers for the upcoming September 6-7, 1995 Key Escrow Issues Meeting to be held at NIST. If you have any questions on this material, you may reach me on 301-975-3696. I look forward to seeing you in September. Attachments ------------------------ Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #1 Issues -- Export of Software Key Escrowed Encryption On August 17, 1995, the Administration announced its proposal to permit the ready export of software encryption provided that the products use algorithms with key space that does not exceed 64 bits and the key(s) required to decrypt messages/files are escrowed with approved escrow agents. Under the proposal, products will be reviewed to verify that they satisfy the criteria and, if so, they will be transferred to the Commodity Control List administered by the Department of Commerce where the products can be exported under a general license (in much the same way that 40-bit RC2/RC4 encryption is licensed today). We are working toward creating broadly stated criteria that are in the nature of performance specifications. To meet these criteria, encryption products will need to implement key escrow mechanisms that cannot be readily altered or bypassed so as to defeat the purposes of key escrowing. The criteria, when finalized and published, will state the objectives, but not the exact technical method(s), by which those objectives are satisfied. This is to provide software publishers the flexibility to design methods for meeting our stated objectives in a manner that is compatible with the design of their products. There are, therefore, a number of questions we must work together to answer in order to draft effective criteria. These questions are: * Avoiding multiple encryption -- How can the product be designed so as to prevent doubling (or tripling, etc.) the key space of the algorithm? * Disabling the key escrow mechanism -- How can products be made resistant to alteration that would disable or circumvent the key escrow mechanism? How can the "static patch" problem be avoided? How can this be tested? * Access to escrow information -- What mechanisms must be designed into encryption products to allow authorized access to escrowed keys? This likely includes the identity of the key escrow agent(s) and a serial number for the key escrow agent to use to identify the key(s)/component(s) necessary to decrypt the message. What other information will be necessary to be provided to the escrow agent to identify the necessary key(s)/component(s)? Are there other comparable viable approaches? * Non-escrowed use -- How can products be made so that they do not function with non-escrowed products (or tampered escrowed products)? How can this be tested? * Limiting surveillance -- How can products be designed so that information both sent and received by the user can be decrypted without release of keys of other users? * Practical Key Access -- How can mechanisms be designed so that repeated involvement of escrow agents is not required for decryption for multiple files/messages during the specified access period? * Assurance that keys are escrowed -- How can it be assured that key escrow products are indeed satisfactorily escrowed? For example, products could be required to be escrowed at time of manufacture or be made inoperable until properly escrowed. * Ability to re-escrow keys -- How can products be designed so that new keys can be escrowed at the user's discretion with a U.S. Government approved escrow agent? * Certified escrow agents -- Can products be designed so that only escrow agents certified by the U.S. government (domestic, or under suitable arrangements, foreign) are utilized? What should be the criteria for an acceptable U.S. escrow agent? -------------- With your input, we are hopeful that this effort will lead to definitive criteria, which will facilitate the development of exportable products and help minimize the time required to obtain export licenses. The Administration seeks to finalize such criteria and make formal conforming modifications to the export regulations before the end of 1995. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e- mail: carlton(a)micf.nist.gov. 8/25/94 ----------------------------- Key Escrow Issues Meeting, September 6-7, 1995 Discussion Paper #2 Discussion Issues: Desirable Characteristics for Key Escrow Agents In the government's recent announcement of its intent to allow the export of 64-bit software key escrow encryption products, one stipulation was that the keys would be escrowed with an approved key escrow agent.(*1) Exactly what qualifications/considerations are appropriate for approval as a key escrow agent have not been defined. Some of the issues which need to be discussed and resolved include the following: * What kinds of organizations should be excluded from consideration as approved key escrow agents? * What sort of legal agreement between the government and the key escrow agent is necessary to stipulate the responsibilities of the agent? Should this include the terms and conditions under which release of a key is required? * How will liability for unauthorized release of key be handled? * Should, for example, intentionally misreleasing or destroying a key be criminalized? Should this include other actions? * How can the government's needs for confidentiality of key release be handled? * Should approval of key escrow agents be tied to a public key infrastructure (for digital signatures and other purposes)? * What procedures need to be developed for the storage and safeguarding of keys? * What are the acceptable performance criteria (e.g., around- the-clock availability, accessibility, reliability, etc.) for approved key escrow agents? * Under what circumstances will key escrow agents in foreign countries be approved? * What process will be used to approve escrow agents? Costs/who pays? --------- (*1) "Approved," for the purposes of this discussion, means that the government (or its agent) has formally granted permission for an organization to hold keys for exportable encryption products. Note: These issues will be discussed at the Key Escrow Issues Meeting to be held September 6-7, 1995 (9:00 a.m. - 5:00 p.m.) at the National Institute of Standards and Technology (Gaithersburg, Maryland). The meeting will be open to the public, although seating is limited. Advance registration is requested, please contact Arlene Carlton on 301/975-3240, fax: 301/948-1784 or e-mail: carlton(a)micf.nist.gov. 8/25/95 _________________________________________________________________________ Subject: NIST Key Escrow Papers _________________________________________________________________________ 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://epic.org Washington, DC 20003 * ftp/gopher/wais cpsr.org

1 0