<<

. 26
( 41 .)



>>

keyserver, allowing the malicious participant to keep all of the prize
money.
Of course, after the fact, the keyserver would show that the key
had been given out for testing, but the results were never returned, a
fact that would raise more than a few red ¬‚ags. A little investigation
would turn up where the key came from”though there is probably
178 CHAPTER 26

some legitimate question about whether that kind of evidence would
be enough proof for RSA to refuse to award all of the money to the
client operator.
While Rocke Verser, Justin Dolske, and I wrestled with these po-
tential problems, some of our participants were dealing with issues of
their own.


Tuesday, May 6, 2:22 A.M.
Western Michigan University, Kalamazoo, Michigan

A student named Jay, going by the alias “A Psychedelic Psychopath,”
was working with a few other students to run DESCHALL clients on
some fairly powerful computers. Having access to two groups of Sun
SPARC 5/20 systems they decided to put some of those machines™
cycles to work for the project.
Then two system administrators noticed their e¬orts. One killed
o¬ the programs, claiming that the DESCHALL client programs were
putting too much load on the systems, and the other disabled the stu-
dents™ accounts and reported Jay and his friends to the dean of students.
Nothing serious happened to the students, but the incident did get us
thinking about how to deal with system administrators who ran the
powerful systems that so many participants wanted to use for testing
keys.
Prompted by the report of what happened, Colin L. Hildinger asked
if it might make more sense to give the program a more academic-
sounding name. Some participants thought this was a good idea and
favored giving them names like “lab3,” at least in departments where
students were given assignments to write programs. In that case, in-
stead of system administrators seeing that students were running DES-
CHALL software on school systems, the clients would look like home-
work.
Vincent Fox, a system administrator at Georgia Tech, weighed with
some helpful advice to anyone who might be trying to ¬nd a way to
work around system administrators. “Better to go to your admin,”
wrote Fox to the DESCHALL mailing list, “and enlist their aid in this
project in the ¬rst place.”
“I know of very few who wouldn™t actively help out if asked to
be a part of the project rather than having it in¬‚icted on them. You
might ¬nd that they can in fact toss more resources and butt-covering
Threats 179

your way than you can possibly imagine. We [administrators] usually
have access to more hardware than you [students] do, and [have] less
accountability.”
Fox was right, as we would see repeatedly. People taking the time to
enlist the help of administrators were much more successful in getting
more systems to be used for key testing than those who tried to be
more covert. Nevertheless, getting cooperation was simply not possible
everywhere. Some organizations would actively encourage participation
in this kind of project, while others wouldn™t allow it for a moment.
In general, large, highly formal organizations like a bank would not al-
low DESCHALL or similar projects, while more dynamic organizations
with highly-empowered employees would encourage it.
Most were somewhere in between, and DESCHALL participants
quickly learned just where.


Tuesday, May 6
IBM Almaden Research Center, San Jose, California

That cryptography had gone mainstream was clear, thanks to regular
news stories on the progress of the DES Challenge contest and pub-
lic policy debates. IBM was about to test just how closely the media
wanted to follow developments in the ¬eld.
IBM™s public relations machine put the word out on a paper that
IBM computer scientists Mikl´s Ajtai and Cynthia Dwork presented
o
at the Association for Computing Machinery™s Symposium on The-
ory of Computing. Scienti¬c papers are presented at computing theory
conferences all the time without fanfare, but the implications of this
particular paper were apparently too great for IBM to resist drawing
greater attention to it. The result was a lesson for DESCHALL coor-
dinators that getting the story wrong and missing the point were two
very real possibilities if the information did not get presented to the
press just so.
Prompted by the public relations behind the Ajtai-Dwork paper, PC
Week Online ran a story that began, “Researchers at IBM™s Almaden
Research Center Lab in San Jose, Calif., claim they have discovered
public key encryption that is uncrackable, solving a problem that has
de¬ed mathematicians for 150 years.”
The Ajtai-Dwork system was not “uncrackable,” as the media would
claim it was, but it was an interesting new system for encrypting data
180 CHAPTER 26

based on a di¬erent mathematical basis from those used in other cryp-
tosystems. The “uncrackable” part of the story came from a mathe-
matical proof included in the paper that demonstrated that a random
attempt to guess the key is the equivalent of the hardest possible case.
In other words, with the Ajtai-Dwork system, it™s not possible to pick
a weak key by accident, thus making decrypting a message easier than
it should be.
Using a mathematical proof of security was a bold step, very dif-
ferent from how cryptosystems are usually presented to the scienti¬c
community. The way that it usually works is that someone will come
up with a new cryptographic algorithm and publish it in a paper, so
others can study it for weaknesses. Over a period of several years, the
algorithm will be attacked in various ways, and cryptographers will see
how resistant the algorithm is to the attacks that are used against it.
Over that period of time, con¬dence in the algorithm will increase, be-
cause the longer than an algorithm is studied by the world™s smartest
cryptographers without a break, the less likely that such a break will
be found before computer technology progresses to the point where
messages encrypted with the system could be broken by brute force.
This method tends to work pretty well, albeit slowly, and has re-
sulted in the development of some very good algorithms, including DES.
The problem is that if someone were to ¬nd a brand new kind of at-
tack against a technique used in well-established algorithms, it could
be a nasty surprise for everyone. New attacks that work against real ci-
phers don™t come to light every day, but they are discovered frequently
enough to keep cryptanalysts all over the world looking for more. Some-
times, systems are in use for years before a practical attack is found
against them. On a few occasions, systems being presented at scienti¬c
conferences have been broken while the paper is still being presented.
Building and breaking ciphers is hard work and full of uncertainty. We
have many systems that are “probably secure” and many others that
were “probably secure” until someone ¬gured out how to break them.
Using a “provably secure” cryptosystem”one whose correctness was
supported by a formal mathematical proof”was another matter en-
tirely. In a provably secure system, each possible way to decrypting the
ciphertext is represented mathematically. Then proving which is the
easiest way to deduce the corresponding plaintext will prove the actual
strength of the cipher. This is somewhat like proving the strength of
Threats 181

each link in a chain. Finding the weakest link will prove the strength
of the chain as a whole.
The problem with provably secure systems is that they have to
make a lot of assumptions about the world around them. For example,
someone who accidentally lets someone else discover a key would open
up an avenue of attack that would be very practical in the real world,
but would not ever make it into a mathematical model. Provably secure
is a long way away from unbreakable.
By the time the media was putting the discovery in front of people,
IBM had invented an unbreakable cryptosystem. Not provably secure,
but unbreakable. DESCHALL coordinators would take seriously the
lesson of how esoteric scienti¬c discoveries can take on lives of their
own once in the hands of the media. While wanting to use the media
to get an important story to potential participants, we did not want
the attention at the expense of accuracy in what we were doing. When
it came time to talk to the press, we would take great care to ensure
that we were being both as precise and clear as possible.
The lesson came at an apropos time: media coverage of DESCHALL
was increasing.




MIT™s student newspaper, the Tech, carried an article about DES-
CHALL and the e¬orts of MIT students there to help with the search
for the key. The next day Nelson Minar told the DESCHALL mailing
list that, within ¬fteen hours of the paper™s release, 120 new machines
at MIT joined in the DESCHALL project”an increase of ¬fty percent.
Three days later, Michael Nelson informed the list that the Utah
State University student paper, the Statesman, ran a front-page article
on DESCHALL. Although the article jumbled signi¬cant technical de-
tails, they correctly quoted Nelson: “I think we should push past BYU
[Brigham Young University]. It is a good way to show that BYU isn™t
the only university in the state.”
As more students started to join the e¬orts going on at their schools,
rivalry began to grow”and this competition would work to our advan-
tage.
When Nelson Minar reported the increase in activity due to the
article in MIT™s the Tech, he also predicted that MIT would overtake
182 CHAPTER 26

the University of Illinois at Urbana-Champaign (UIUC) in the total
number of machines participating and perhaps even in number of keys
tested per day.
Forty-¬ve minutes later, UIUC Unix systems engineer Joe Gross
responded with a post back to the DESCHALL mailing list. “We™ll
have to see about that,” wrote Gross, before describing the ¬fty high-
end UltraSPARC machines from Sun Microsystems that had just been
brought online and were about to start running DESCHALL clients.
Gross added, that “once ¬nals end next Friday,” UIUC would start
running DESCHALL clients on 300 high-end workstations.
Back at MIT, Nate Boyd wrote, “That just ain™t fair. The NCSA
is de¬nitely contributing big!” NCSA”National Center for Supercom-
puting Applications, located on the UIUC campus”had lots of horse-
power available, and was, coincidentally, where Marc Andreessen and
friends wrote Mosaic, the ¬rst graphical Web browser. As it turned
out, Gross was not talking about getting any of the supercomputers
to run DESCHALL, but the idea that the university was making such
a big contribution was enough to turn a little heat onto the healthy
rivalry that was already driving university students and sta¬ to get
more systems running DESCHALL clients.
Adam Haberlach at Oregon State caught the spirit of threatening
the use of supercomputers and joked to the DESCHALL mailing list,
“Don™t make me try and get time on our Oceanography Department™s
CM5. Or the CS department™s Maiko.” (For all of the posturing that
students from schools with powerful supercomputers were doing, the
simple fact was that supercomputers really wouldn™t help much, even
if we did have DESCHALL clients that they could run, as described on
page 58.)
MIT undergraduate Will Ko¬el observed that the MIT wasn™t really
doing anything to support DESCHALL or the users trying to ¬nd places
to run the clients. He wrote, “I™d like to see UIUC test 16 trillion keys
a day with dorm room computers!” Ko¬el noted that MIT had some
die-hard DESCHALL fans on campus, who were sneaking into their
labs and ¬ring up clients on all the SPARC 20s and Pentium machines
they could ¬nd. Ko¬el proclaimed, “We™ll take the peak yet!”
Je¬ Gilchrist was coordinating DESCHALL activity at University
of New Brunswick (UNB) in Canada. He had spoken with the faculty
of Computer Science and Computing Services about DESCHALL, and
was given permission to run some of the clients in a few di¬erent de-
Threats 183

partment labs. He had even managed to get some of the professors to
run it on their machines. While not “sponsoring” Gilchrist, the univer-
sity administration were certainly aware of his work and approved of
his running the clients.
Adam Haberlach was in a similar situation at Oregon State. Though
not formally backed by the University, individual departments were
giving him some support. Many students and sta¬ members at Oregon
State were participating, a few labs were running the clients, and some
Web pages were describing the e¬orts on campus and explaining how
others could join in. Among the departments participating, the Busi-
ness Department was actually the biggest contributor. Oregon State™s
rankings went from ¬rst to second in early May, and then lower, when
the DESCHALL supporter there took a trip to a big trade show in
early May. Haberlach added with a smile, “We™ll be back.”
Like Haberlach and Gilchrist, Benjamin Peterson at Notre Dame
wasn™t getting direct support either, but had managed to coordinate
things so that there would be no interference with people using the ma-
chines. He had 170 Sun UltraSPARC 1 machines and ten SGI machines
working on the project. Between 8:00 A.M. and midnight, if someone
logged into the console, the DESCHALL client would be killed. When
no one was logged into the machine™s console, or outside of those “day-
time” hours, Peterson™s program would be sure that no one was logged
into the machine and working remotely. If the machine was being used
that way, his program would stop the DESCHALL program”putting it
in a kind of suspended animation. If the users on the machine all went
idle for more than ten minutes, his program would tell DESCHALL to
continue, picking up right where it left o¬. With some additional checks
to suspend and to continue the process depending on the load of the
machine, Peterson™s contribution to our e¬orts was signi¬cant. His pro-
gram was also so well designed that no one would have any reason to
complain about the program using too much system resources.
Peterson wasn™t the only participant who built additional software
to manage the clients on a large number of machines. At the Bowman
Gray School of Medicine, system administrator Dave Ahn wanted to
run the DESCHALL clients on his SGI systems with their fast 64-
bit R10000 processors. On May 9, he released WFU, the Watch Fork
Utility for DESCHALL.
As summer grew near and students began working on year-end
projects, daytime activity on the machines Peterson was using would
184 CHAPTER 26

tend to peak at about twenty of the Sun machines active at any point.
After the year-end projects were ¬nished, most points of the day had
between ¬fty and eighty machines active.
Beyond that, a few more students and sta¬ were running the clients
in their labs. Unfortunately, support at Notre Dame didn™t grow like it
did in some other environments, and as the summer rapidly approached,
many of the students that were participating from all over the country,
including Benjamin Peterson, were leaving campus for home.
While some DESCHALL participants were preparing to head home
for the summer, others continued to join the project. As the ¬rst full
week of May wound down, the DESCHALL keyserver accepted a re-
port of some keys tested from an unlikely contributor, whose report of
some 30 billion keys tested earned a subtle entry toward the end of the
DESCHALL status report for May 8.

<<

. 26
( 41 .)



>>