While Washington debated the future of cryptographic policy, corpora-
tions and individuals all over the world continued to buy cryptography
products to protect themselves and their information against threats to
conļ¬dentiality and integrity. Among the American companies unhappy
to sit idle as foreign competitors continued to meet the worldwide de-
mand for cryptographic protection was Sun Microsystems, based in
Santa Clara, California.
Known as a pioneer in enterprise computing, Sun intended to ad-
dress this important global market. The Wall Street Journal reported
on May 19 that Sun would sell encryption software internationally
through a Russian supplier, Elvis+Co., founded by former Soviet rocket
scientists. Elvis+Co. would license the software from Sun and deliver
it to customers overseas.
Sun oļ¬cials said that they had not made the deal to subvert the
cryptography export restrictions, but to deliver solutions that its inter-
national clients needed.
Getting Word Out
Friday, May 23, 8:50 A.M.
Megasoft Online, Columbus, Ohio
Looking for still more ways to publicize DESCHALL, I considered ways
to reach people without relying on the Internet to get to them. Li-
braries, computer labs, and schools all seemed likely sources of poten-
tial participants, but we had no promotional material to hand out to
people who might want to know more and then join the eļ¬ort later.
Hoping to encourage some creative thinking for ļ¬‚yer designs to ļ¬t this
purpose, I wrote to the mailing list about my progress on developing
diļ¬erent designs for DESCHALL ļ¬‚iers to be printed on standard U.S.-
letter paper. I also added that I would post any good designs on my
Web site, where they would be found easily.
David E. Eison of Georgia Tech responsed to my note and men-
tioned he had a friend design a DESCHALL ļ¬‚yer, suitable for posting
anywhere. The ļ¬‚yer included a critical visualā”a pixelized version of
Georgia Techā™s mascot (a hornet named āBuzzā)ā”which would not
make sense for other sites. Nevertheless, he oļ¬ered a few design tips
that would prove useful for others making ļ¬‚yers of their own.
First, the text should actually be minimal, allowing for large and
clear letters to be used. Second, the handout should include a Web
address where interested people can go for more information; he also
suggested having some tear-oļ¬ tags along the bottom so people could
take one instead of having to remember the address. Third, Eison sug-
gested enumerating reasons for joining the eļ¬ort. He observed that
those reasons should include some serious incentives like cash reward
216 CHAPTER 31
and inļ¬‚uence over government
policy as well as some humorous 3
ones like āgiving your computer a 2.8
Later in the day, Brian Young, 2.4
an Internet systems administra- 2.2
tor at Oral Roberts University, 2
thought about our need to recruit 1.8
more participants. Looking over
the number of keys tested per
day in the past two weeks (Fig- Fig. 9. DESCHALL Key Testing Rate
ure 9), he noted that our progress (Billions per Second), May 7ā“21, 1997
wasnā™t anywhere near the rapid
pace that it had been earlier in
the month. In fact, our rate of keys tested per second actually de-
creased over the past week. He wondered if the decrease in peak search
rate might have something to do with university students being away
and not running the clients on as many machines when they werenā™t at
Yes, we were slowing, but Young also noticed something that was
more promising: we had passed the ten percent markā”more than 7.2
quadrillion keys had been tested by us so far. He suggested we consider
a post-ten-percent press release in order to recruit new participants and
inspire those who were already helping us.
Meanwhile, David Eison, who was also reviewing the most recent
statistics, noticed that Georgia Techā™s participation in DESCHALL had
dropped oļ¬ in the past few days. In response to Brian Youngā™s questions
about the general drop-oļ¬ in key testing rates, Eison noted that Georgia
Tech too had seen a decrease in its on-campus activity, although classes
were not scheduled to end for another two weeks.
Wondering why this might be the case, he suggested that initial
interest could be tapering oļ¬. Indeed, many people had, out of cu-
riosity, been willing to download some clients and run them on their
personal computers. Because their interest, Eison guessed, was more
casual, these participants wouldnā™t install a DESCHALL client into
their startup programs, and they wouldnā™t make any eļ¬ort to keep the
clients running. Thus, over time, as systems got rebooted, more and
more clients run by people who only had a passing interest stopped
Getting Word Out 217
Since I was running the mailing lists, I saw some important data
about interest in the project. In the week before May 23, I had seen
more than 200 returned e-mail messages, almost exclusively from people
at universities. Typically, mailing list administrators will see returned
messages when subscribers abandon their addresses and the abandoned
mailboxes become full, or when e-mail accounts used to read the mailing
list are closed. We had plenty of subscribers in both categories. Either
way, it looked like students had started to return home for the summer
and were not reading their e-mail.
In other cases, people were running large numbers of clients with-
out the knowledge or approval of their organizationā™s management or
system administration staļ¬. As system administrators at diļ¬erent in-
stitutions became aware of the DESCHALL clients, they were deciding
to ban the clients from their networks.
Something had to be done to ensure that DESCHALL clients would
keep running. Eison and others he knew at Georgia Tech intended to
organize a signiļ¬cant eļ¬ort to keep DESCHALL clients running on
campus and to spread the word about the project, hoping to counteract
the eļ¬ect of students going home for the summer. Eison hoped that
others would do the same at their own universities.
While we were considering possible causes for decreases in activity,
Eison noticed that no DESCHALL client was running at one of the
buildings on the Georgia Tech campus where he knew they were in-
stalled. The key search rate for the project overall as well as Georgia
Tech had been slowing in recent days, and this was something that
would not help to reverse that trend.
Eison did some checking into the problem soon found the culprit.
It turned out that one of the Sun machines had crashed while DES-
CHALL was running. Someone on the administrative staļ¬ there made
an executive decision to terminate all DESCHALL participation in the
building, believing that the DESCHALL program was responsible for
the systemā™s crash.
Unable to get any more details on what else was happening, Eison
posted to the DESCHALL mailing list to ļ¬nd out if anyone else had
experienced similar problems with their clients.
As Nelson Minar at MIT read David Eisonā™s e-mail, he shook his
head at the idea of a whole building full of computers unable to run
DESCHALL because someone thought that a user process can crash a
Sun machine. Incredible.
218 CHAPTER 31
Operating systems like OS/2, Unix, and Windows are programs,
Minar knew very well, but theyā™re a little diļ¬erent from most other
kinds of programs. The primary purpose of operating systems isnā™t
for the sake of users, but for the sake of other programs. Operating
systems provide an interface to the hardware for other programs, so
that applications like word processors and web browsers donā™t need to
know lots of intimate details about things like your video card, hard
drive, and other components of your computer.
Another special property of operating systems is that they actually
run other programs inside of them. So your word processor is actually
a program that is running inside of another programā”your operating
Programs do crash sometimes, when something happens and they
reach some kind of situation that the designers never imaged. The āY2K
bugā that spooked computer users in 1998 and 1999 is a good example.
If a program is designed to represent a year with two digits, that might
be written as 97. Suppose that the program then has to perform a
calculation that adds three to the year. Performing the simple addition
of 3 to 97 will result in 100, which is obviously three digits long. If a
program was written so that it could handle only two digits, putting a
three-digit number into that part of the programā™s memory would cause
a condition the programmer never foresaw, and the program would
When people encounter something that they didnā™t expect, they
might get confused, but they tend to recover quickly. For example,
someone adding 3 to 97 would get 100, but would not try to put a
three-digit number in place. A mistake like that by a person would be
amusing, but that would be the extent of the āproblem.ā
This diļ¬erence between people and software is critical, and an excel-
lent way to demonstrate how brittle most of the software built today
really is. Obviously, programs that are written properly should not
crash. Never crashing at all really isnā™t a practical goal for software
developers, but we can eliminate enough problems in software that the
mean-time between failures (MTBF) is so large that some other prob-
lem (like hardware failure) is likely to take the system down before our
Operating systems tend to be especially robust software. If anything
is supposed to be well-debugged and tested to be sure that MTBF is
a āreally long timeā (months or years) it will be the operating system.
Getting Word Out 219
Most Unix-based operating systems had achieved quite a signiļ¬cant
level of stability and correctness by 1997, with many being able to
run for years without a reboot or a crash. IBMā™s OS/2 tended to be
pretty good about stability at this time. Like Unix, OS/2 had protected
memory, where programs could not write into parts of the computerā™s
memory used by other programs.
To understand protected memory, letā™s reconsider the example of
our program that added 3 to 97 and tried to store it in a place where
only two digits were reserved. In an operating system without protected
memory, the program would put the digits 100 into memory, starting at
a given location. The 10 would ļ¬t, but then the next 0 would get writ-
ten into the next section of memoryā”which might be used by another
program. So now instead of having one program with a nonsensical
value in memory, the program running next to it now was also com-
promised. The damaged portion of the program might not have been
a number at all, but a letter, or a symbol. When that program tries to
get that value back, itā™s going to get a 0 where something else used to
be, possibly causing that program to crash as well.
Working under an operating system with protected memory, the
buggy program that tried to put a three-digit value into a two-digit
memory slot might crash, but it would not be able to make any other
programs, or the operating system itself, crash.
Appleā™s MacOS could be wildly variant in stability, depending on
which applications were running, since it didnā™t oļ¬er protected memory.
Microsoftā™s Windows 3.1 was notorious for its instability, often requir-
ing daily reboots, and sometimes more, frequently because an error in
a program that the user was running would overwrite another part of
memory, one used by the operating system itself. Once that happened,
only restarting the system would correct the problem.
Sunā™s computers ran Solaris, a robust implementation of the Unix
operating systemā”one with protected memory that could not be
crashed because of any program that a user would run on the system.
Bearing all of this in mind, Minar posted the following response to
the DESCHALL mailing list later in the afternoon:
Itā™s amazing how DESCHALL reveals what people donā™t un-
derstand about how computers work. Wearing out CPUs. Low
priority processes pigging machines. And now, user processes
crashing operating systems.
220 CHAPTER 31
The idea of DESCHALL crashing the operating system is
ridiculous. If a user process as simple as DESCHALL can crash
a Unix kernel [the core of the operating system] then that Unix
is severely broken. Unix isnā™t Windows. [On the other hand],
if the Unix system is truly that broken and I were [the system
administrator] I would probably try to get people not to run
programs on it, either.
As we considered how DESCHALL client software impacted the
systems running it, one of our participants noticed a problem with how
the client worked.
Friday, May 23, 9:43 A.M.
University of Oregon, Portland
Chris Schleicher decided to put some Sun machines running Solaris
and some SGI machines running IRIX to work running DESCHALL
clients during their idle moments. The Sun clients worked smoothly, but
Schleicher noticed something a little diļ¬erent with the IRIX machines.
On several occasions, when someone tried to use the computer, the
DESCHALL client didnā™t yield the processor the way that he expected,
or the way that was happening on other Unix implementations. This
was a problem because if DESCHALL took processing time away from
users, Schleicher would not be able to run DESCHALL clients on those
systems. If it was a problem with the client, he wouldnā™t be the only
one who would have to pull the plugā”other participants would have
the same problem and probably have to quit running the client. Before
we got to that point, we had to ļ¬gure out why the client insisted on
running when IRIX user programs had something to do.
The operating systemā™s process scheduler is designed to work with
the processor so that for each cycle (or, ātickā) of the processor, the
process scheduler will decide which program gets to be on the processor.
Remember, a 200 MHz machine has some 200 million cycles per second;
itā™s this fast moving among diļ¬erent programs that actually gives the
user the illusion of running multiple programs at once. The process
scheduler should be looking to see which programs want time on the
processor and letting the DESCHALL client run only when no other
program wants the processor.