<<

. 16
( 41 .)



>>

that instead of searching for particular messages, the opposite approach
Architecture 103

be taken. Messages that participants would recognize and know they
could safely ignore should be thrown away, and all other client messages
should be reported.


Saturday, April 12, 12:40 P.M.
Rutgers University, Piscataway, New Jersey

Some users were interested in seeing more detailed information from the
logs than whether the key had been found. The same basic principle
of creating and reading log ¬les could be used to review client status
reports on number of keys tested and aggregate them for a participant
with a large number of clients to review easily. In his dorm room, Scott
McIntyre had several Pentium machines running DESCHALL. He was
already wondering just how much he was contributing to the project
overall when he noticed some others on the mailing list talk about how
many keys they were testing in a day.
McIntyre did not know how the participants with Unix clients were
creating their log ¬les, so he looked at his Windows-based client for
a function to create a log. Not ¬nding one, he thought logging might
be a feature in the Unix clients not present in the Windows client, or
that someone had a program to capture and to aggregate the on-screen
output from the client.
Expressing his desire to see what his clients were doing like some
of the participants with Unix clients were, he posted a message to the
mailing list asking for ideas on how to collect the DESCHALL client
output under Windows.


3:43 P.M.
Austin, Texas

Like many other participants, Carol Harris was redirecting the output
of the DESCHALL client to a ¬le to create a log that kept a record
of the client™s activity. Unlike most of the users who did this, she was
running the DESCHALL client on a Windows system. Interestingly,
she was gathering the client™s output the same way that participants
with Unix clients were.
The Windows operating system has a long history of borrowing fea-
tures that were implemented ¬rst in other operating systems. Windows
had with it a command line interpreter (usually started by running
104 CHAPTER 14

COMMAND or CMD), which was essentially the same as the old DOS com-
mand line. Improvements made to the DOS command language over
the years were made by people who understood Unix and were inspired
to bring some of the Unix command language features to DOS. Redi-
rection of program output was one of these features, thus allowing the
DESCHALL client to have its output sent to a plain text ¬le instead
of appearing on the screen. That ¬le could then be reviewed, searched,
and otherwise manipulated at the user™s leisure.
Harris used the Windows command interpreter on her 166 MHz
Cyrix “686” machine to send the DESCHALL client™s output to a ¬le,
just like was being done by some of the Unix users. Seeing McIntyre™s
question on the list, Harris responded, showing exactly what she typed
to the command interpreter to get the desired behavior.
As more participants joined in the DESCHALL project, partici-
pants continued to help each other to overcome the obstacles they were
facing. E¬orts of earlier participants to manage and to monitor the
DESCHALL client software also helped newcomers to get their sys-
tems participating more quickly.


Wednesday, April 9, 8:19 P.M.
University of New Brunswick, Canada

While one group of participants dealt with getting their clients to start
and to stop on predetermined schedules and to report client activ-
ity, another worked on strategies for participating with only dial-up
modems for Internet connectivity. Je¬ Gilchrist, a student in the coop-
erative higher education program at the University of New Brunswick
in Eastern Canada was just such a participant.
Gilchrist was running the DESCHALL client on his modest 75 MHz
486DX4 system. Running Windows 95, the system was able to test
keys without any problems, but frequently had di¬culty communicat-
ing with the keyserver. Gilchrist noticed that his system would ¬nish
checking a block of keys, then it would wait to talk to the keyserver.
Since the system was not connected to the Internet all the time, it had
to wait for Gilchrist to connect to his ISP via dial-up modem. Once
online, the system would wait for several minutes before reporting its
progress to the keyserver and getting the next block of keys.
As explained on page 67, clients would need to request a block of
keys to test from the keyserver. Once the client ¬nished testing the
Architecture 105

block of keys, it would need to report the results and to request another.
If the computer was o¬„ine, it obviously couldn™t send the message to
the server. If a client needed to communicate with the server and could
not, it would sit there and wait until a connection was established, thus
wasting time that could otherwise be spent on testing keys.
Earlier in the day, someone using the name “Icepick” posted a mes-
sage to the DESCHALL mailing list in which he mentioned a pro-
gram called freeDUM, a free “dial-up manager.” By running the free-
DUM program, DESCHALL participants could perform their usual
non-DESCHALL work, and the machine would connect to the right
Internet provider on a pre-determined schedule, set to ensure that the
system would be online about the time that the DESCHALL client
needed to communicate with the keyserver. Once the line has gone idle
for some period of time, freeDUM will hang up the line, all automat-
ically. Con¬guring freeDUM to make its connections every half hour
worked well, since that was about the amount of time it would take for
the DESCHALL clients to work their way through a key block.
Windows users weren™t the only ones trying to manage the problems
of participating in the project e¬ectively via dial-up modem.


Thursday, April 10, 10:08 A.M.
Pennsylvania State University
University Park, Pennsylvania

IBM™s OS/2 operating system was well represented in the project. Not
only was the keyserver itself running on OS/2, but many clients were
being run on OS/2 machines. Rodney R. Korte was running some of
these clients on systems whose only Internet connection was a dial-up
modem.
Korte developed a program for OS/2 users with modems that would
help them to avoid any wasted time waiting for an Internet connection.
Implemented in IBM™s REXX programming language”like the DES-
CHALL keyserver itself”the program would watch the DESCHALL
client program™s output. When it saw the “Key not found” message
followed by a message that the keyserver could not be reached because
the network was down, it would run a program to get the machine
connected to the Internet.
106 CHAPTER 14

Other OS/2 users began making use of Korte™s program, thus mak-
ing sure that their machines weren™t wasting cycles that could be spent
looking for keys.


10:36 P.M.
Loveland, Colorado

Rocke Verser sat at his computer, quietly reading messages posted to
the DESCHALL mailing list. Heartened by the way that the spirit of the
project was catching on, Verser read messages posted by participants
for whom the quest to ¬nd unused computing power to harness for
DESCHALL had become almost an obsession.
As accounts of how DESCHALL was brought to computer labs
¬‚owed in, a picture began to emerge. Enthusiastic participants were
happy to install and run the client on the computers they could reach,
but in many cases, there were obstacles to overcome.
Consider a computer lab with ¬fty regular desktop computers. Sup-
pose the computers are relatively new, have 200 MHz Pentium pro-
cessors, and are running Windows 95. The main obstacle to putting
DESCHALL clients on these sorts of machines is that they are running
Windows 95. As a result it isn™t always easy to add software such as
the DESCHALL client in a way that does not interfere with what a
user sitting in front of the system is trying to do. Even if the program
could run without generating pop-up Windows and the like, at the very
least, the system wanted to clutter the taskbar with the icon for the
DESCHALL client and any other software that might be running to
manage any logs being created.
Computers”sometimes even entire labs of computers”like this all
over the country were being used only for a regular eight-hour workday,
sitting idle for the other sixteen hours. If only these systems could run
DESCHALL clients outside of normal working hours, a tremendous
amount of computing power could be harnessed for our project.
Thinking about how to address this problem, Verser quietly tapped
on his keyboard, writing a message that would be sent to the DES-
CHALL mailing list.
Verser™s short note simply asked if anyone had created “DESCHALL
boot disks,” ¬‚oppy diskettes that would have just enough of an oper-
ating system to boot the system, get it connected to the local area
network (which, in turn would have Internet connectivity), and then
Architecture 107

to run the DESCHALL client software. Such diskettes could easily be
created to run the Linux or FreeBSD versions of the client, explained
Verser. People could use their computers normally, then just before
leaving the lab for the day, they could put in the DESCHALL boot
disk, and reboot their system.
When the machine booted from the ¬‚oppy disk, it would come on
the network, start the client with the correct parameters, and start
testing keys. Anyone who needed to use the machine would just eject
the DESCHALL disk and reboot the machine. The system would come
up in its usual environment, completely free of the DESCHALL client.
In a lab of ¬fty new Pentium machines, if we could use these ma-
chines for twelve hours per day, we would be able to test an additional
864 billion keys per day. That would account for roughly ¬ve percent
of the daily total project activity in the ¬rst week of April. Adding
twenty such labs would double the number of keys we could test per
day. How many such labs were in the country would be anyone™s guess.
Thousands, maybe tens of thousands. If we could harness even a small
percentage of these networks, we could test keys at a blindingly fast
rate.




In early April, I spent a lot of time thinking about how to harness
the power of systems that operated behind network ¬rewalls. The ba-
sic architecture of clients communicating with the keyserver via UDP
datagrams simply wasn™t working”the ¬rewalls were preventing those
messages from ¬‚owing normally. We didn™t really expect that we could
convince most sites to make changes to the way that their ¬rewalls
worked to allow more free access between their internal systems and
the public Internet. After all, those ¬rewall systems had been put in
place for a reason.
In the ¬rst years of the Internet™s existence as a research project
in the 1960s and 1970s, practically all Internet users knew each other.
As the network grew in popularity among researchers, the community
became less heavily interwoven, but there was still a high level of trust
among Internet users in general, since all had a vested interest in mak-
ing the Internet itself work. By 1997, though, those days were long
gone: the Internet was no longer an academic or scienti¬c curiosity. As
108 CHAPTER 14

the global network of networks became easier to use without highly
specialized knowledge of arcane languages and computer technology,
throngs of new users joined the Internet population. In time, the Inter-
net population as a whole started to look less and less like the technical
wizards who invented it and more like the general population, with its
share of people with both good intentions and bad.
When communities are ¬rst settled, locks on the doors and windows
are uncommon. As communities grow, along with inability to know
and to trust people nearby, the use of locks increases. No one in New
York City seriously considers keeping an apartment unlocked. Likewise,
computer administrators lock up their networks (with ¬rewalls) to deny
access from unauthorized individuals.
A ¬rewall is simply a barrier that separates one major unit (like
the engine compartment of a car) from another (e.g., the passenger
compartment). The idea of creating the separation is to avoid exposing
the entire system to a threat a¬ecting one unit or another.
When it comes to computer systems, ¬rewalls on networks do the
same thing: they separate one logical unit, or “zone” (e.g., the public In-
ternet), from another (e.g., an internal network). Generally, this works
by having a special computing and networking device have two network
connections: one to the Internet and one to the internal network. With
no other connection between the Internet and the internal network,
any attempts to get tra¬c from one network to the other would need
to pass through the ¬rewall. Instead of allowing everything to pass”as
happens with usual networking equipment”the ¬rewall will look at the
data to see if the policy programmed in by the administrator will allow
the tra¬c to pass through.
With a few important exceptions, most ¬rewalls would not allow
UDP datagrams to pass. So, while our lab machines at universities and
on networks directly connected to the Internet were able to talk to
the keyserver, machines protected by ¬rewalls would have their UDP-
based messages to the keyserver blocked. The keyserver would never
see the messages from the clients, simply as a matter of network policy
forbidding tra¬c that the ¬rewall administrators didn™t know about
from ¬‚owing between zones.
A lot of participants whose computers were behind ¬rewalls were
asking for details on how the DESCHALL clients talk to the keyserver,
so they could approach their ¬rewall administrators and ask for the
con¬gurations to be changed to allow DESCHALL tra¬c. Many users
Architecture 109

had made similar requests for other things, such as streaming audio, so
¬nding at least a few sympathetic ¬rewall administrators didn™t seem
out of the question. For participants who had administrative control
over their organizations™ ¬rewalls, enabling DESCHALL tra¬c to pass
was easy enough to do. Since I had authority over my company™s ¬re-
walls, I was able to make the changes needed to allow a some of our
machines to participate without opening the entire internal network to
threats that the company wanted to avoid.
In most cases, though, the DESCHALL participants were not the
same people who were responsible for their network ¬rewalls. Going
through the process of getting a change made”¬nding the right person,
explaining what DESCHALL was about, and waiting for approval on
a new policy”would take far longer than most participants would be
willing to invest. In many cases, even if participants could make their
cases to ¬rewall administrators, their companies might decide not to
participate as a matter of policy.
Firewall systems were becoming increasingly popular, and the num-
ber of networks where people could participate in a project that could

<<

. 16
( 41 .)



>>