----- Forwarded message from Michael Paul Johnson -----
From cpunks Mon Aug 11 00:38:22 1997 Message-Id: <3.0.3.32.19970810222548.00923ad0@teal.csn.net> X-Sender: mpj@teal.csn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 10 Aug 1997 22:25:48 -0600 To: coderpunks@toad.com From: Michael Paul Johnson <mpj@ebible.org> Subject: North American Crypto Archive status Sender: owner-cypherpunks@toad.com Precedence: bulk
-- Start of PGP signed section. WHAT HAPPENED TO THE NORTH AMERICAN CRYPTO ARCHIVE? The North American Crypto Archive at http://www.sni.net/~mpj/crypto.htm is rather limited right now. I have deleted everything except the few files that I contributed to the site. This was to save money, since I suddenly lost some sponsors (who wish to remain anonymous, but I appreciate them greatly) who were paying for the costs associated with the site. I am still planning to resurrect the North American Crypto Archive, but this will likely take a while. I think that almost all of the files were successfully rescued before the site went down by at least one person. Note that much of what was there can be found by following the links at http://www.sni.net/~mpj/freecrypt.htm or by using appropriate search utilities. WHY RESURRECT THE NORTH AMERICAN CRYPTO ARCHIVE? 1. To provide a place for U. S. and Canadian citizens to freely and openly exchange cryptographic information, papers, programs, etc., without fear of government reprisals. 2. To provide a friendly central repository for cryptographic libraries, code, and papers, thus making it easy to find and use such information. 3. To provide a reasonably high bandwith connection for North Americans. 4. To exercise "freedom of the press" and press towards a constitutional EAR. HOW MUCH SPACE WILL THIS TAKE? My total archive space was at about 125 megabytes, but it had been trimmed from what I would like to have. For example, downlevel versions of software were generally deleted, and some things that are historically and cryptographically interesting were not carried. I forsee usage of around 500 megabytes or more in the near future if we can make room for it. The storage need not all be at the same site, however. HOW MUCH BANDWIDTH WOULD IT TAKE? I'd like to see at least ISDN connectivity. I've seen as many as 425 files downloaded in a day from the current archive. Again, the storage and loading need not all be at the same site. WHAT DO YOU MEAN BY NOT HAVING ALL THE STORAGE AT ONE SITE? I envision a new plan for running the archive such that one master index page (like the "export controlled" one at http://www.sni.net/~mpj/na) points to hidden directories all over the continent, wherever free space can be gleaned. The only requirements on the remote sites to maintain the "export controlled" status would be to maintain a cron job that changed the name of the hidden ftp directory containing the files on the same schedule and using the same key as used at the index site. For now, http://www.sni.net/~mpj/na can remain as the password-controlled index site. This does require a slight change to the architecture of the "export control" system in that the directory name would be a function of the current time (UTC) and a secret key, instead of being truly random like it is, now. The relative loss of security in this change is inisgnificant relative to the (obvious) weak links of the system. (Yes, I know that it can be defeated, but I also believe that the system complies with the EAR as well as most do, anyway.) The gain in this approach, of course, is that the index and ftp site need not reside on the same server, as long as the system clocks are reasonably well synchronized (within a few minutes). One other advantage of having several sites is that popular files can be placed on several different servers to lower the average traffic from any one server and to make the system more robust against failures and overloads. The archive would still have a single point of failure (at least initially) in the index site, but that could also be replicated fairly easily as long as users don't mind obtaining a separate password from each index site. WHAT REMOTE SITES DO YOU PLAN TO USE? I've had several people make inquiries or make offers, some of which sound better than others. I hope that this one open letter answers all of the questions that I got. I am looking for sites that: 1. Are *nix-based (at least for now). 2. Have some free disk space and bandwidth that can be used for this cause. 3. Have GNU C++ installed (or at least are identical to a host that I have access to that does). 4. Grant me access to a shell account and an ftp account to maintain the site. 5. Grant me access to cron so that I can have the hidden-directory renaming program run at the right schedule. 6. Are likely to be available for a reasonably long term. 7. Are in the USA or Canada and controlled by a U. S. or Canadian citizen. WHAT MAKES PEOPLE THINK THAT YOU WILL GET ALL OF THESE FREE RESOURCES? The same thing that makes me think that people will donate otherwise idle CPU resources for the fun of cracking a DES key or factoring very large numbers. HOW DOES THE "EXPORT CONTROL" SOFTWARE WORK? Ahh... here is the meat of the message that keeps it on topic for coderpunks and sci.crypt: First of all, it is important to understand the design restraints. The EAR states that mere posting of cryptographic software on the internet is not an export if guests must affirm a couple of things (see the regulations) and if there is some kind of check that the "address of the receiving computer is verified to be in the USA." Strict compliance with the latter is impossible, but if the guest's email address is in a domain not commonly used in the USA and Canada (.gov, .com, .org, .edu, .mil, .net, .us, or .ca), then I suspect the guest of lying and deny access. Naturally, this is imperfect, but it is honestly the best I could figure out how to do on a normal ISP shell account that gives me no CGI script access. This really boils down to the honor system. That is OK with me if it is OK with the U. S. Government, and the way I interpret the law, it is. Given that, here is the process: 1. http://www.sni.net/~mpj/usa is an html form that asks 3 "magic" questions to verify eligibility to legally access the strong cryptographic software, as well as the guest's email address. The 3 questions all default such that the user must change each answer to be granted access. The email address must be correct, because the user name and password are sent back via email, not as a web page. The "submit" button sends this data to cgiemail, an application that Colorado SuperNet does allow me to use. This form also invites nonqualified guests to explore most of the same data via http://www.sni.net/~mpj/freecryp.htm (links to crypto sites outside of North America). 2. When cgiemail gets the data from the above form, it simply formats the data using a template I supplied and mails it to me at mpj@csn.net. 3. I have an incoming mail filter that checks for any automated messages from cgiemail (which all have a rather long fixed hexadecimal number for a subject line), and processes them. If the guest answered all 3 questions properly, and the email address given doesn't "look foreign," then a form letter is filled in with a valid user name and password and mailed to the given email address. (There are some other checks, like limiting the email address to one destination, etc.) Noncompliant requests are simply discarded (since the "thank you" message from the submission form really already answered them). I thought about a courteous denial letter, but most of the bogus submissions also have bogus email addresses, so I decided not to do that. 4. If our guest can spell his or her email address right (among other things), then the email message directs him or her to http://www.sni.net/~mpj/na with a valid user name and password. 5. http://www.sni.net/~mpj/na is password protected using the security features of the Apache web server (as slightly tweaked by Colorado SuperNet). This is the index of the files in the archive, which are in a subdirectory of a hidden directory with a non-obvious name. 6. The hidden directory names are changed periodically to discourage the use or posting of a copy of the page at http://www.sni.net/~mpj/na without password protection. The idea is that by the time the cheater posted it and anyone found it, the hidden directory names would have changed again, invalidating the renegade index. The index is altered on the same schedule to the same new names by a companion program. (Right now the same program does both tasks, using a truly random number based on the arrival times and CRCs of all of my mail, but this would have to change in the new distributed archive model). IS THAT REALLY GOOD ENOUGH? I think so. It is the best export control model that I have seen that doesn't lock out U. S. and Canadian citizens in the U. S. A. and Canada. I saw a little more elaborate system on a Microsoft web site for distributing some 128-bit RC2 software, but it locked me out because it didn't like the way Colorado SuperNet registered their "whois" information. It also locked me out from work, since SSL connections can't get past our firewall. My model is much less likely to lock out a duly qualified guest, and it is much better than my old "warning message only" model that I used before crypto export regulations passed from the ITAR to the EAR. WHAT ABOUT CRYPTO SITES OUTSIDE OF NORTH AMERICA? Please keep them up, and be ready to mirror any information that might suddenly become legal to export from the USA on short notice. I say this because the EAR is being challenged in court, and it is likely that cryptographic software export regulations may be struck down. It is also likely that the U. S. Government may quickly move to replace those regulations with others in a very short amount of time after the EAR is struck down. I don't want to encourage anyone to violate currently active regulations, however. If you have a good cryptographic software site outside of North America, and it isn't on my list at http://www.sni.net/~mpj/freecrypt.htm, please let me know. WHAT IS YOUR PGP KEY? RSA key for PGP 2.6.x: ftp://ftp.csn.net/mpj/mpjkey.asc (mpjA) DH/DSS key for PGP 5.0: ftp://ftp.csn.net/mpj/mpjdhkey.asc (mpj@ebible.org) (Note that my RSA key uses mpj@csn.net for an address. That old address still works.) -- End of PGP signed section, PGP failed! ----- End of forwarded message from Michael Paul Johnson -----