1997-08-11 - North American Crypto Archive status

Header Data

From: Michael Paul Johnson <mpj@ebible.org>
To: coderpunks@toad.com
Message Hash: 3ab414bf2caa0644d934e4ef6a6e16737a23f738e9ee79ec410904872751ce38
Message ID: <3.0.3.32.19970810222548.00923ad0@teal.csn.net>
Reply To: N/A
UTC Datetime: 1997-08-11 04:28:45 UTC
Raw Date: Sun, 10 Aug 1997 21:28:45 -0700 (PDT)

Raw message

From: Michael Paul Johnson <mpj@ebible.org>
Date: Sun, 10 Aug 1997 21:28:45 -0700 (PDT)
To: coderpunks@toad.com
Subject: North American Crypto Archive status
Message-ID: <3.0.3.32.19970810222548.00923ad0@teal.csn.net>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----


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.)


-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBM+6USm+Iqt/O4EnZAQFVFgf+IQq7oZavZxgMwT2530w7LWPkNLqlbG5z
BSi1QGasmZrumAuMOG7M28prFZVg2hzExKUejlSXao7ywa3fnzLb0BF8WlDlFsS/
ysSQTB1NLzgjm3L8pqImdNGrP6ECFSFsTm3KOGxuu/NAVfEyBaoV5VEwxlUJmWBu
ifsmv7aBOOfY4g2xa9XQay4+rIx4QTr6k6OJenJ0f+eLnC/JjG7Dz3n3Mh0vbu6p
Vc9ib9jjkv+eawKv5+BnFUNc/hILsnw1yPQuomc7/G/YMJwbd7Ps/+LVRqmg0oxD
ECLfAI/BI6KxUh8EDGH91SnSXNHAYwtA1puIrQka1zkPPTr/psA/fw==
=9Zof
-----END PGP SIGNATURE-----


Michael Paul Johnson    mailto:mpj@ebible.org (aka mpj@csn.net)
PO Box 1151             http://www.ebible.org/bible        <- Holy Bible
Longmont CO 80502-1151  http://www.sni.net/~mpj/crypto.htm <- Crypto archive
USA       

PGP RSA key fingerprint (mpjA): 3E67 A580 0DFB D16A  6D52 D3A9 1C07 4E41

PGP DSS/DH fingerprint: 28AE B775 DD65 62C7 0717  ECDA 448F E0C7 17D7 47BB









Thread