[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
North American Crypto Archive status
-----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 [email protected].
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 ([email protected])
(Note that my RSA key uses [email protected] 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:[email protected] (aka [email protected])
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