December 2003 - cypherpunks-legacy

Re: Florida Drivers Permits
by David K. Merriman 17 Dec '03

17 Dec '03

At 01:10 PM 8/25/95 -0400, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >- -----BEGIN PGP SIGNED MESSAGE----- > >[Welcome back, Professor] You posted: > > >>Will, starting next year, containg a digitized photo, plus the current >>info. > ><snip> > >>Anyone know any details about the technololgy? > ><snip> > >Not really. > I saw the same story. The name, address, age, & height mentioned >are already obvious on licenses, but this may preclude incorrect data entry >by FL cops, and counterfeiting (a problem here for *years*). I saw nothing >on the digitized photo, but we could be looking at different stories. >Phase-in in July, '96. The story I saw suggests that other data, such as >tickets, criminal violations (presumably convictions) and "other >biographical information" [welfare, credit info] could eventually be >included, depending on FL's state budgetary considerations. No author, >just "Associated Press," listed on the story, and the card uses a magnetic >strip "like those on credit cards" rather than a chip, which may be a >mistake [considering the renewal period & my experience with bank-cards]. >Story doesn't say it, but it sounds like FL *may* be the first state to do >this. Are any other states doing this already? Texas is now issuing similar cards - with the addition of a barcode on the back. Front is going to have UV-reactive writing, and be color-coded for class of license (commercial, chauffer, etc). Happily, I renewed just a couple months ago, so have plenty of time to figure out what I can do to the new DL when I get one :-) 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

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

ssl challenge
by David K. Merriman 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- It would be Really Nice if the next version of the brutessl software had a couple of features (particularly for us folks with mini-LANs) - > option to output results to a file (or files, so we can maintain local logging of results: ie, CHAL2a.dat, CHAL2b.dat, etc). > a Windows 3.1 variant (or even win32s) I've got 3 machines (386sx-33, 386DX-20, 486DX2-80), with an option on my roommates machine (386DX-40), all connected via Windows for Workgroups. All 4 are set up with win32s, so could do a *lot* better at keysearches if the software was available. There's plenty of support for Unix variants, and even NT/95, but us humble Win/DOS users are kinda left hanging a bit. Maybe next challenge, we can pre-allocate keyspace based on the results of this one: look at how fast folks are reporting results, and allocate chunks of space accordingly (maybe based on an 8-hour 'cycle'). Sure take some of the load off the poor server :-) Dave Merriman -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMD4E48VrTvyYOzAZAQGSMwP8DWxgb5NVDgvIFuw1BGf0E5TP0swHdyZ1 I4gfIGMtjd1AbtJHbxwILSPwb8+BcqZxZtGQXnYRnyoAkK7FltsiGulWApMXmNUU gtSUMr9xngW+Mwq5ju865Ff5wp7s8Bv3BBTqKGLmXWON1ILbEbjUNwqs4i8+wQU0 PCOgvJndj5M= =dyvQ -----END PGP SIGNATURE----- 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

2 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

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

SSL Challenge: Server problems
by Peter Trei 17 Dec '03

17 Dec '03

I can't contact the server to request keyspace anymore - I get a '500 Server error' It looks like 12 hours on a P5/90 are going to waste (could have done 90 segments) Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

6 8