<<

. 31
( 41 .)



>>




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

215
216 CHAPTER 31

and in¬‚uence over government
3.2
policy as well as some humorous 3
ones like “giving your computer a 2.8
hobby.” 2.6
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




May 20
May 18
May 16
May 14
May 12
May 10
May 08
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
school.
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
working.
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
system.
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
crash.
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
software crashes.
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.

<<

. 31
( 41 .)



>>