CHALL would gain an additional 150 or so clients in exchange for a
Beanie Baby. We had no idea how many deals like this were made to
allow us access to additional machines to run the key-search clients,
but what we do know tells us that the users who were running our
clients and recruiting more volunteers were a dedicated lot. The will-
ingness of users to engage in horse-trades like this with people who
had much-needed computing power was testimony to the dedication of
DESCHALL participants, and a critical part of growing our computing
People working on our projectā”and competing projectsā”understood
that we were not just trying to ļ¬nd a needle in a haystack, but that we
were attempting to complete a huge computationā”maybe the worldā™s
largest to date. Our āsupercomputerā was unique because instead of
having many processors tied closely together, it was made up of thou-
sands of computers that were collaborating via the Internet. Sun Mi-
crosystems had been declaring, āThe Network Is the Computerā since
the early 1980s: the slogan was literally true in our case.
Itā™s important to remember what the Internet connecting all of these
thousands of computers was like in 1997. Ease of use greatly improved
with the ļ¬rst graphical Web browsers from 1993 and 1994 led to rapid
acceptance of Internet technology by mainstream computer users. At
the end of 1994, there were roughly 38 million Internet users; 50.6 mil-
lion by January, 1997; and 101 million by January, 1998. All of those
users were supported by an ever-growing number of computer systems
connecting to the Internet: just over 3 million in 1994 grew to 12.9
million in mid-1996, which grew to 19.5 million in mid-1997.18 Internet
service providers (ISPs) struggled to keep up with the demand in the
face of this growth. Consider that to get a high-speed telecommunica-
tions circuit to connect a few hundred users to the Internet could take
anywhere from thirty to ninety days to come online after an order was
placed. With 1997ā™s growth, that could mean that just in the time that
the service provider waited for a circuit, the number of users would
have increased anywhere from just under ten percent to twenty-ļ¬ve
percent. In some places, the circuits simply could not be put into place
fast enough to keep up with the demand for connections.
140 CHAPTER 19
While the network providers struggled to accomodate the ever-
increasing traļ¬c, DESCHALL participants, like many other Internet
users, felt the eļ¬ects. Throughout the course of the project, for ex-
ample, we had repeated reports that the keyserver was down. In most
cases, the outage wasnā™t a problem with the DESCHALL keyserver or
even its connection to the Internet but simply due to ISPs having more
traļ¬c on the network than the infrastructure could support. Internet
traļ¬c jams were unfortunately common during hours of peak demand.
These hiccups were certainly a frustration for all involved, but the sit-
uation was not entirely unexpected, given the state of the technology
available. When those exchange points were badly overloaded, what
should have felt like one, seamless Internet became a visible amalgam
of diļ¬erent networks; users on one part of the Internet could commu-
nicate with each other, but they would experience delays of minutes or
even hours when trying to get data to users with diļ¬erent providers.
Connectivity problems were not limited to the exchange points. At
the time, many homes and small oļ¬ces relied on dial-up modems to
get online. Dedicated circuits that provided continuous and high-speed
Internet access were thousands of dollars monthlyā”and therefore only
economical when serving dozens or hundreds of users. Reliable Internet
connections were essentially limited to a rate of 28.8 kBps per second.
Even then, most ISPs would hang up on connections that had gone
idle for more than a minute or twoā”unless they were ādedicated dial-
upā lines that cost ļ¬ve times as much as standard dial-up service. If
your ISP hung up on you while you were reading a Web page, when
you clicked a hyperlink, youā™d need to wait for your system to dial up
again, hope that you didnā™t get a busy signal, and then wait for the
connection to be reestablished. Staying online for most individual users
and even small oļ¬ces was an arduous task. This was the Internet that
we used as the basis for our distributed DES key-cracking computer.
Friday, April 11
Yale University, New Haven, Connecticut
Jensen Harris knew what the problem was right away. He was reading a
request for help posted to the DESCHALL mailing list by Josh Weage,
a mechanical engineering student at Michigan Technological University.
Weage had just heard about the DESCHALL project and decided that
he wanted to help, so he went to the North American Cryptography
Archive to download a client for his personal Pentium machine. He
then decided to run the DESCHALL client software on one of Michi-
gan Techā™s Sun machines running the Solaris operating environment
on a SPARC processor. Like he did earlier in the day, he went to the
North American Cryptography Archive, downloaded a client for the
Solaris/SPARC platform and started it up.
The program wrote some text to the screen, but didnā™t seem to be
doing any work. Weage posted what the client wrote to his screen along
with his request for help:
DES Violation Client v1.0
(C) Copyright 1997 the DES Violation Group
gethostbyname: Error 0
Obtaining keyspace from keyserver.des.violation.net.
Error connecting to server.
Waiting 2 minutes....
142 CHAPTER 20
Having made the same mistake himself, Harris immediately recog-
nized that Weage was not running the DESCHALL client but the DES
Violation Group client. It was an easy mistake to make: both DES-
CHALL and DES Violation Group distributed their client software
from the same site and both projectsā™ clients had ļ¬le names starting
with āDES.ā Users just hearing about DESCHALL were bound to get
confused. Most would simply hear about cracking DES keys, go to the
client download site they heard about, and download the ļ¬rst package
in the list that seemed to be about DES key cracking. Such users could
hardly be expected to know that there were multiple projects.
Harris posted a response back to the mailing list, pointing out ex-
actly which ļ¬le to download, and then arguing the need for a separate
archive strictly for DESCHALL client software. He made the same mis-
take when he ļ¬rst joined the DESCHALL project, and no doubt many
others did as well. All of our eļ¬orts to promote the DESCHALL project
could be rendered useless if people heard about our project and then
started running DES Violation Group clients.
Harris didnā™t need to argue his case stronglyā”DESCHALL partici-
pants and coordinators all knew that he was right.
Saturday, April 26, 4:09 P.M.
The Ohio State University, Columbus, Ohio
Justin Dolske ļ¬nished his program for handling client distribution for
DESCHALL and decided it was ready for testing. He built the software
around the basic requirement that it be easy for new clients to be
uploaded by project coordinators and easy for eligible users to download
the right clients. Part of the challenge for Dolske to teach the software
to diļ¬erentiate the eligible users from the ineligible ones. To address
these concerns, we employed a combination of policy and technology.
Michael Paul Johnsonā™s system for the North American Cryptog-
raphy Archive apparently worked for its intended purpose, so Dolske
built a system that would work in a similar, but not identical fashion.
Once Dolskeā™s system was in place, users wishing to download the
software ļ¬rst had to answer three questions, based on the questions for
the North American Cryptography Archive but slightly modiļ¬ed by
1. Are you a citizen or national of the United States, a person
who has been lawfully admitted for permanent residence in
the United States under the Immigration and Naturalization
Act, or a Canadian citizen?
2. Do you agree not to export the DESCHALL client software
in violation of the export control laws of the United States of
America? Or, if you are a Canadian citizen, are you obtain-
ing the DESCHALL client software for end-use in Canada
by Canadian citizens, or return to the United States, in a
manner permitted by Canadian law?
3. Do you assert that you have answered all of these questions
If all three questions were answered aļ¬rmatively, the software then
checked the visitorā™s IP address to determine if the computer making
the request is actually located inside of the U.S. or Canada. Two dif-
ferent testing mechanisms were used: one based on the domain name
system (DNS) that maps computer system names to IP addresses and
the other based on the data from the registrars that manage domain
The test based on DNS was the simplest case. It had two parts that
worked together. The ļ¬rst part was a DNS query by IP address to ļ¬nd
the name of the userā™s computer. The second part was to query the DNS
for the name from the ļ¬rst part to ļ¬nd its IP address. So, if I attempted
to download the software from my computer called gatekeeper, Dolskeā™s
software would see that my computerā™s IP address was 220.127.116.11.
The ļ¬rst DNS test would be to look the name up by address; that would
determine that the name of my computer was gatekeeper.megasoft.com.
The second part would look up the IP address of 18.104.22.168 to
ļ¬nd it name, which would be gatekeeper.megasoft.com. This was a
good test, because it would mean that two diļ¬erent sets of network
managers (those who manage IP address space, and those who manage
the domain name space) either agreed on the name and IP address
of a system or independently delegated naming authority to the same
person, which would also mean that person could name the machines
whatever he wanted.
This DNS test would prevent āspooļ¬ngā attacks where managers of
IP address space could make their systems look like they were really
inside of the United States. For example, take a hypothetical company
in France called Cā™est Vrai with the domain name of cest-vrai.fr, and
a network manager (letā™s call her RenĀ“e) whose computer is called foo.
RenĀ“e might go to the DESCHALL client archive running Dolskeā™s
144 CHAPTER 20
software and answer āyesā to all three questions on the questionnaire.
Dolskeā™s software would perform its DNS lookups and see that RenĀ“eā™s e
machine asking to download the software is coming from the address
of 192.168.254.11, which is known as foo.cest-vrai.fr. The second part
of the test would show that foo.cest-vrai.fr really is 192.168.254.11. At
that point, Dolskeā™s software would then notice that the domain name
is part of ā.fr,ā the country code for Franceā”and display this message
Error code: Export check 1 failed.
Sorry. Based on your answers and/or other information, you
are not eligible to download the DESCHALL client software. If
you believe you have received this message in error, please mail
us a note containing:
ā¢ The time and day you received this denial (so that we may
check why the server denied you access).
ā¢ The hostname of the computer you were using.
ā¢ A short note explaining that although you double-checked
your answers on the form, you should still have access and
Being clever (and somewhat naughty, as network administrators
frequently are), RenĀ“e might decide that Dolskeā™s DESCHALL client
archive software could tell she was coming from France based on the
mapping of IP addresses to domain names, and that she could work
around that since she had authority to change the address-to-name
mappings. RenĀ“e would want change the address-to-name mapping so
that 192.168.254.11 gives an answer that suggests it is in the U.S.,
After making such a change, RenĀ“e could go back and try again.
This time through, Dolskeā™s software will look up the address and get
foo.cest-vrai.us. The second part of that DNS test would try to ļ¬nd
the address for foo.cest-vrai.us, which would not exist. RenĀ“e would be
denied access a second time, seeing the same message with a diļ¬erent
error code: āExport check 2 failed.ā The only way that RenĀ“e would be
able to get around this system would be to ļ¬nd someone in the U.S. or
Canada who was willing to modify their own DNS records to allow her
machine to look like it was part of their network, and this was unlikely.
If double-checking in the DNS showed us that the computer was part
of a domain in the U.S. or Canada, Dolskeā™s software would present a
list of clients that could be downloadedā”but the user only had ļ¬fty
minutes before the page wouldnā™t work anymore and the questionnaire
and tests would have to be performed again. The domains that were
obviously in the U.S. or Canada were ā.edu,ā ā.gov,ā ā.mil,ā ā.us,ā and
ā.ca.ā Other domains, like ā.org,ā ā.com,ā and ā.netā could be from
anywhere, so for these cases, Dolskeā™s software would go to a second
test: the registrar for Internet domains.
Return to the example of me trying to get the software from gate-
keeper.megasoft.com. Since a ā.comā domain could be from anywhere
in the world, Dolskeā™s software would query the domain name registrar
to determine the address of the domain manager. The registrar would
show that āmegasoft.comā belonged to a company in Freehold, New
Jersey, clearly inside of the U.S., and therefore grant me access. Any-
one from Canada or any of the ļ¬fty states would be granted access. Not
knowing whether allowing a download to a U.S. territory (like Puerto
Rico or the U.S. Virgin Islands) counted as āexportā under the regula-
tion, Dolske decided to play it safe and deny requests from those areas.
The rest of the world, of course, would be denied.
The system wasnā™t perfect, but since we were working on a project
that would last months (not years) and people requesting the client