December 2003 - cypherpunks-legacy

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

SSL Challenge: Are we in trouble?
by Peter Trei 17 Dec '03

17 Dec '03

Well, the server appears to be unable to serve cgi scripts - I get '500 - server error' whenever I try. I cannot report the ~500 segments I swept overnight, nor get new keyspace. I thing it's gotten to the point where the server is the bottleneck on this operation - we seem to have plenty of cpu for sweeps. This will damage our primary goal - to demonstrate how fast 40 bits can be swept. Piete, Adam, could you put a note on the /bute/ root page describing the server status? Thanks Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

4 4

spam-- a technological solution/proposal
by Vladimir Z. Nuri 17 Dec '03

17 Dec '03

for a long time conversation here has covered the possibility of "certificates" especially the cryptography and algorithms behind them. also, spam is a frequent topic. in fact I think the term "spam" was used on this mailing list almost before anywhere else. at the heart, spam is a fascinating question. the internet has been designed to survive a nuclear war through its decentralization, i.e. a threat from without. but what about a "threat from within" such that your own nodes can be corrupted? this is the case with spammers. it's an extremely difficult question to solve, and involves concepts like a body, "immune system", cancer, etc. after thinking about it for many moons, here is an interesting idea that I think could work on "spam prevention" using certificates. it's somewhat decentralized and has other nice "cyberspace friendly" features. a "spam-free certifying agency" is started. this is essentially a web site that allows people to download "spam-free certification". it parcels out new digital signatures to anybody who asks. the system works simply as follows: a person is spam-free until "the net" complains otherwise. the agency decides what threshold of complaints constitutes a loss of "spam-free certification". when it revokes a certificate, it sends out the revocation to the net. you'd need something like the DNS system today to carry all the spam-free certificates in a distributed fashion. everyone who reads their mail can have automated checkers that throw out mail from non "spam-free" certified emailers. this system requires people to put their spam-free certificates in their mail. the idea is that spammers could get intially certificates, but that complaints would be so numerous and so immediate that they couldn't get out that many letters before they lost their certification due to everyone immediately complaining. another interesting approach would be for internet providers not to allow too many mails to be sent after a new spam-free certification of a new email address. that is, tie in the email addresses themselves to the spam-prevention system. interestingly many of these ideas are similar to the credit-reporting agency techniques. you can get credit after you get a credit history. the more history, the more credit. perhaps a system that limited the amount of mail a person could send based on a "spam free history" could work well. I think you could have a system that had multiple spam-free certification agencies. you could have standards that try to juggle among multiple agencies and certificate schemes. a variety of schemes is better than none. of course, all the usual caveats apply here. it's patently obvious this system could be misused and manipulated. however I believe it's the most promising route of anything that's been tried. I personally think legislative/litigation solutions are a waste of time and potentially harmful. if anyone would like to help develop this, please send me email.

1 0

Wide Release (Re: PGPfone (BETA TEST) is released)
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

ftp host: net-dist.mit.edu, AKA bitsy.mit.edu 220 bitsy FTP server (Version wu-2.4(1) Thu Apr 14 20:21:35 EDT 1994) ready. USER ftp 331 Guest login ok, send your complete e-mail address as password. PASS ***** 230-Welcome, archive user! This is an experimental FTP server. If have any 230-unusual problems, please report them via e-mail to ftp-bugs@bitsy 230-If you do have problems, please try using a dash (-) as the first character 230-of your password -- this will turn off the continuation messages that may 230-be confusing your ftp client. 230- 230-Please read the file README 230- it was last modified on Sat May 28 19:19:36 1988 - 2643 days ago 230 Guest login ok, access restrictions apply. PWD 257 "/" is current directory. MACB E 500 'MACB E': command not understood. TYPE A 200 Type set to A. CWD /pub/PGPfone 250-Please read the file README 250- it was last modified on Fri Aug 25 15:52:05 1995 - 0 days ago 250 CWD command successful. PORT 199,117,100,36,7,146 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 29 -r--r--r-- 1 0 1001 4287 Aug 25 15:52 README drwxr-x--- 4 1 27 512 Aug 25 17:00 dist -r--r--r-- 1 0 1001 2172 Aug 24 22:02 mitlicen.txt -r--r--r-- 1 0 1001 19546 Aug 24 23:43 rsalicen.txt 226 Transfer complete. CWD /pub/PGPfone/dist 250 CWD command successful. PORT 199,117,100,36,4,177 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 2 drwxr-xr-x 2 435 27 512 Aug 25 15:24 U.S.-only-XXXX drwxrwxr-x 2 0 27 512 Aug 25 15:13 secret99 226 Transfer complete. CWD /pub/PGPfone/dist/secret99 250 CWD command successful. PORT 199,117,100,36,7,178 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 2271 -r--r--r-- 1 0 27 764444 Aug 25 15:12 PGPfone10.sea.Hqx -r--r--r-- 1 0 27 751220 Aug 25 12:50 PGPfone10.sea.Hqx.OLD -r--r--r-- 1 0 27 750964 Aug 24 23:30 PGPfone10.sea.Hqx.OLDER -r--r--r-- 1 0 27 2172 Aug 24 22:02 mitlicen.txt -r--r--r-- 1 0 27 19546 Aug 24 23:43 rsalicen.txt 226 Transfer complete. CWD /pub/PGPfone/dist/U.S.-only-XXXX 250 CWD command successful. PORT 199,117,100,36,6,161 200 PORT command successful. LIST 150 Opening ASCII mode data connection for /bin/ls. total 760 -r--r--r-- 1 0 27 764444 Aug 25 15:12 PGPfone10.sea.Hqx 226 Transfer complete.

3 3

random coincidences
by Sam Quigley 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- What are some of the more common "coincidences" and non-random correlations that ordinary random number generators (ones found in common computer languages that don't take extensive measures to be random) have? It seems that there's a lot of fuss about getting very random numbers, but unless the numbers produced by ordinary measures have very obvious coincidences, maybe it's a big fuss about nothing...? - -sq -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBMD12u1IP+Y8TPTdtAQECmwP/UTLcmOL1sKvOrtO7XcE5mNpr5gjou/Ht kWqIbobOroIsW3YtbL/KbdFmxBhPr9SrynYc76vlqRXG0vai5xOmqRdMyCXs+67U qWWRxlJRhEgbdGNaH2YgSU7MlEIGq64oEWW439wbABG+TMQtV225gzhOUsCEM9qg 3Bun1zOnJIc= =xhWT -----END PGP SIGNATURE-----

2 1

Over 500 'Munitions T-shirts' Shipped!
by dhenson＠itsnet.com 17 Dec '03

17 Dec '03

We have thus far shipped over 500 of the RSA/Perl Munition T-shirts. Orders are still pouring in. Don't be left out. Order your's today. (Read some comments of our customers at the end of this post.) Now you can wear a TSHIRT that has been classified as a MUNITION by the US Goverment. That's right! The US International Traffic in Arms Regulations (ITAR) makes exporting cyrptographic materials illegal. ITAR further defines export as providing cryptographic information to a non-US/Canadian citizen even if you are inside the US at the time. Providing information is further defined as telling or showing information to a non-US/Canadian citizen. The Munitions Tshirt has a Perl implementation of the RSA algorithm (the one used by PGP) printed on the front along with a bar-code of the same algorithm. What all the above means is that if you wear the Munitions Tshirt where a non-US/Canadian citizen can see it, even if it is inside the US, you have just exported cryptographic material (which is already freely available outside the US) and have become a criminal in the eyes of the US Government. Now you too can become an international arms dealer for the price of a tshirt (US$15.95 - US$29.95, depending on size) and the guts to wear it. If you are a non-US/Canadian citizen, you can still own a Munitons Tshirt by ordering the tshirt from a source that is outside the US. The email response to a request for info (see next paragraph) includes full instructions for ordering the tshirt no matter where you live. For more information on how to own this classic example of civil disobedience, just send email to wepinsto(a)colossus.net with the subject of 'SHIRT'. (You don't have to be a US/Canadian citizen to request the info.) Or, if you have WWW access, just point your Web browser to: http://colossus.net/wepinsto/wshome.html By the way, 25% of the profits from the sale of the tshirt (in the US/Canada) goes to the PHIL ZIMMERMANN LEGAL DEFENSE FUND to help defend the author of PGP from harassment and possible prosecution by the Fedgoons. And if you get arrested for wearing the Munitions Tshirt, we'll refund your purchase price. :-) ====++++====++++ Here are some testimonials from a few of our many satisfied customers: "Got mine this afternoon. Wooohhaah!! Already had some folks at Blockbusters point, mumble to themselves, and then ask me what the munitions warning meant. This is going to be fun!! I'm a cyphernerd for sure..." "Thanks for the great T-shirt. I'm making copies of your paper order form for others." "I think I'll have to wear the shirt over to Logan Airport and hang around the International Arrivals terminal a few times. <G>" "I received the T-shirt on 8/3. Thank you, it has been a pleasure dealing with you!" "The first thing that I did after it arrived was to don it and then go visit the office of one of our visiting researchers from Russia. :)~" ====++++====++++ Get your Munitions Tshirt now. Who knows how long they'll stay in production! Don Henson, Managing Director (PGP Key ID = 0X03002DC9) West El Paso Information Network (WEPIN) Check out The WEPIN Store at URL: http://colossus.net/wepinsto/wshome.html

1 0

distributed data store, a la eternity
by Ryan Lackey 17 Dec '03

17 Dec '03

PGP message

4 3

Progress so far
by Peter Trei 17 Dec '03

17 Dec '03

Well, we're now about 30 hours into the crack, and here are some very rough stats. We've swept a bit over 1/4 of the keyspace. Only 60% of requests have been ACKed so far - PLEASE check to make sure your acks have been recorded. The largest segments completed are a 128 (mine), and 4 100's (3 are mine :-) Over 9000 segments have been swept in 3-segment chunks, by far the most popular size. I count people from uk, at, se, ee, fr, ie, kr, nl, de, no, au, za, nz, fi, ca, be, is, and us, by a casual inspection - I'm sure there are more. It's pretty clear that the server is the bottleneck, though also looks like some people are biting off more than they can chew. I would have probably swept another couple hundred today if I could have obtained the key space. Since a lot of sweepers are not on the cpunk list, notices of updates and progress would be well put in the /brute/ page. I'm going away for a week and a half's vacation. I'll try to watch for results in sci.crypt, but I probably won't see the cpunk list until I'm back. Good luck! Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation trei(a)process.com

1 0