. 24
( 41 .)


megabytes of data, thus indicating that he was holding the line, rather
than actually using it the whole time. After getting that message from
his ISP, he decided that he needed to ¬nd another approach.
Among DESCHALL users, there was no shortage of solutions to
any problem”administrative or otherwise. Another participant work-
ing from home, Matt Clauson, quipped that Gmoser™s problem could
be solved by making a mirror of the entire software archive at Wash-
ington University”the largest collection of free software on the planet.
Over a modem, the process would literally take months. In any case,
it would prevent his ISP from complaining that he wasn™t downloading
enough during the time he was connected.
Still another participant working from home, Andrew James Alan
Welty, suggested that the strategy of checking e-mail would be more
e¬ective if Gmoser mailed himself a twelve megabyte ¬le. At 28.8 kbps,
the upload to the mail server would take about an hour, and the down-
load on the way back from the mail server should take another hour.
DESCHALL Community 161

Still others suggested a simple change to a di¬erent ISP with su¬cient
capacity to handle a dial-up customer who was always online.

Participants frequently used the mailing list as a forum for all sorts of
DESCHALL-related issues, including announcements of their own doc-
umentation and clever solutions to various problems before them. Stu-
art Stock, a systems and security administrator at Gundaker Realtors
in St. Louis posted his “DESCHALL Linux Bootdisk Mini-HOWTO”
on May 1.
Stock™s Mini-HOWTO was a brief, technical document describing
how to create DESCHALL “bootdisks” along the lines that Rocke
Verser described in his April 10 message to the mailing list. The Mini-
HOWTO document included con¬guration strategy hints as well as
technical details, thus allowing system administrators to use, say, a
network of ¬fty Windows 3.1 machines that had been booted from the
DESCHALL Boot Disk to test keys all night long. The Mini-HOWTO
even showed how the system would be able to run until it was time for
work again, at which point the system would again reboot, but since
the bootable ¬‚oppy disk had been removed (immediately after starting
the client), the system would start as usual.
The whole process was designed to be so discreet that system users
never had any idea that the systems they were using during the day
were hard at work on DESCHALL overnight. While this was no dif-
ferent from what system administrators were doing on university cam-
puses and large companies around the country, it was a signi¬cant step
forward because Windows 3.1 machines had not previously been able
to run the DESCHALL clients. Stock™s Mini-HOWTO showed partici-
pants how to bring DESCHALL to a whole new group of computers.

By this time, we had clients for nearly every platform in common use,
including Windows 95 and NT, Macintosh, OS/2, Linux, and nearly
every type of Unix workstation and server. Users of Sun™s new Ultra-
SPARC workstation and servers had just gotten a new client in the
162 CHAPTER 22

past week, bringing their performance from 640,000 keys per second up
to 700,000 keys per second.
Users of the 64-bit systems, such as Sun™s UltraSPARC, had not yet
seen Darrell Kindred™s work on the bitslice clients. Even as Kindred
sent the incredible results of his testing to DESCHALL coordinators,
users clamored for more improvement in the performance of the client
software built for systems with non-Intel processors. While our clients
were faster than those of the other projects, participants with expen-
sive engineering workstations were disappointed to see their key testing
rates compare so poorly to users with Intel-based PCs. The comparison
wasn™t really fair, since the Intel clients were so heavily optimized (see
Chapter 13), but without any other means to compare performance,
the users grew frustrated.
As Darrell Kindred continued his work on the bitslicing clients, he
promised mailing list readers that he would explain in detail how the
method worked, but not until after he ¬nished his work and the new
bitslicing clients were available for download.

Wednesday, April 30
Capitol Hill, Washington, DC

Participants in projects like DESCHALL, SolNET, and DES Violation
Group could easily get lost in technical minutiae regarding searching
algorithms, architectures, and key sizes. While the DESCHALL team
and our friends working on competing projects raced to see who could
build the fastest and largest DES key searching system in the world,
legislators in Washington were battling for the future of public policy
on cryptography in the United States and abroad.
In the U.S. House of Representatives, the Security And Freedom
through Encryption (SAFE) Act, designed to liberate cryptography,
was making progress. It had been debated extensively and, despite
the Clinton administration™s objections that its electronic surveillance
e¬orts would be hindered, the SAFE Act passed its ¬rst hurdle in a
Judiciary subcommittee”unanimously. (See Chapter 7 for discussion
of the bills and their rationale.)
The U.S. Senate version of the legislation was known as Pro-CODE.
It was scheduled for a vote in the Commerce Committee on May 1. After
seeing the SAFE Act™s success, Conrad Burns, a Republican senator
from Montana, led the bill™s sponsors in delaying the vote for a month
while they assessed their newly strengthened negotiating position.
“I think the administration sees the handwriting on the wall,” said
Burns™ press secretary, Matt Raymond, to CNET News. Pro-CODE
sponsors hoped that any changes that might further increase the bill™s
strength could be made by early June, at which point the bill would

164 CHAPTER 23

be ready to go to the full Senate for debate, and possibly even a vote.
Helpfully, the Senate™s majority leader, Republican Trent Lott of Mis-
sissippi, was a cosponsor of Pro-CODE.
Not everyone could read handwriting on walls, however. Less than
two weeks later, an outline of a new bill by Senators John McCain (R-
AZ), Bob Kerrey (D-NE), John Kerry (D-MA), and Earnest Hollings
(D-SC) appeared on the popular Fight-Censorship mailing list. Known
as the “Secure Public Networks Act,” the bill was intended to give
government o¬cials access to information”even if encrypted. The bill
required that all Americans using cryptography submit a copy of their
encryption keys to a government-approved third party. If a government
agency present the third party with a warrant for a given key, the third
party would turn over that key to the government. Thus the McCain-
Kerrey bill allowed the government some access to Americans™ private
information, while the other bills essentially restricted it.
DESCHALL was not only racing other groups participating in
RSA™s DES Challenge contest or ¬ghting for a stronger replacement
for the U.S. government standard for data encryption. For many par-
ticipants and observers, DESCHALL was about asserting the right of
the people to use cryptography freely. With the debate in Washington
heating up, a new sense of urgency would drive our activity through
the month of May.
In the Lead

Friday, May 2, 7:18 P.M.
MIT Campus, Boston, Massachusetts

Undergraduate student Ethan O™Connor started taking a look at Sol-
NET statistics and noticed that their site was reporting 2 billion keys
per second, with roughly 4000 hosts reporting in per half-hour. Using
that as the basis for his calculations, he showed that SolNET was in-
creasing in its overall search speed faster than DESCHALL. If progress
for both projects remained constant, SolNET would pull ahead of DES-
CHALL in overall search speed within the week.
Meanwhile at Ohio State, Justin Dolske performed his daily checkup
on our progress, as well as that of our friends at SolNET and DES
Violation Group. We had not paid much attention to the DES Viola-
tion Group since the mid-April comparisons of our respective statistics
pages that showed them lagging so far behind.
Instead of ¬nding the group™s latest progress statistics, Dolske saw
a note that read:
Due to lack of support, resources, and time to invest, the DES
Violation Group has become inactive. With alternatives such
as SolNET going more than ten times faster, our e¬ort is just
“wasting CPU cycles,” to quote an e-mail we have received. We
would like to thank all those who devoted time, e¬ort, and CPU
cycles to our cause.
Some of the DESCHALL participants speculated that with DES
Violation Group falling so far behind and then seeing that SolNET was

166 CHAPTER 24

gaining on DESCHALL, DES Violation Group coordinators opted to
throw their support behind the SolNET e¬ort. We did think it strange
that a U.S.-based project would not throw its support behind the other
U.S.-based project”and front-runner!”but we were too busy testing
keys to waste much time wondering why we didn™t get the endorsement.
Although we would have liked the DES Violation Group coordinators to
recommend that their members join us, we knew that those members™
CPU cycles were not lost to us: we were just going to have to recruit
them more actively.
While we contemplated the potential impact of reducing competi-
tion in the DES Challenge, Nelson Minar at MIT drew our attention
to an unwelcome development in the competition to recruit project
Instead of waiting for the DES Challenge to be solved, Mike Driscoll,
an engineering student at Colorado School of Mines, was organizing an
e¬ort to respond to a di¬erent contest”RSA™s 1997 Secret Key Chal-
lenge for the 56-bit version of the RC5 cipher. (See page 44 for the
announcement of the contests.) RC5 was not an interesting target be-
cause of what it was used for (most commonly, for securing Web trans-
actions), but because attacks against RC5 were a useful way to show the
relative strength of di¬erent key sizes. As a variable-key-length cipher,
RC5 lets the implementor choose the desired key size between 40 and
128 bits. But there wasn™t any particular importance to RC5; if 56-bit
RC5 wasn™t strong enough for a particular application, the implemen-
tation could easily be made 64 times stronger with a relatively simple
con¬guration change to use 128-bit keys. With DES, no such recon¬g-
uration was possible; it was hardwired to a 56-bit key”any variant to
increase strength would require multiple keys, which introduced still
other problems.
DESCHALL participants and coordinators were anxious to demon-
strate the weakness of 56-bit keys in general, but we were disappointed
that Driscoll was proceeding before waiting for the DES Challenge
to ¬nish. Although the disappearance of DES Violation Group would
make more participants free to participate in either DESCHALL or Sol-
NET, the appearance of Driscoll™s group to break a 56-bit RC5 message
by brute force, known as Bovine, would pull some potential participants
away from the DES Challenge and to the RC5 Challenge.
Although DESCHALL was still going strong, Driscoll™s project
raised a couple of concerns. First, if we were to really prove the fal-
In the Lead 167

libility of DES, we needed to crack it quickly to show that DES was
too weak for practical use. A secondary problem would be the way that
an 56-bit RC5 crack taking place before a DES key crack would play
in the media. Imagine the headline, “56-bit Cryptography Cracked;
Actual Standard Still Safe.” While we could probably argue that the
Bovine project demonstrated the weakness of 56-bit keys, the point
of our project was to demonstrate how the actual standard itself was
vulnerable to brute-force attacks.
DESCHALL participants understood these issues, so we had no con-
cerns about them switching to the other contest. We did worry that
potential participants would hear about the Bovine project and choose
to participate in it instead of joining the ranks of DESCHALL.

Friday, May 2
Megasoft Online, Columbus, Ohio

While it was tempting to worry, it was too early to tell whether the
Bovine groupd would have a negative impact on DESCHALL, and
frankly, I had other, more urgent matters to address. To explain the
purpose and importance of the DESCHALL project and to help peo-
ple get started participating, I began to compile a list of frequently
asked questions and put them into a document along with the answers.
Participants who joined the e¬ort early tended to understand cryp-
tography and computing technology pretty well, but as we got more
attention through the media, we knew that we could not count on par-
ticipants just joining us to have the same technical background. The
“Frequently Asked Questions” document was intended to allow people
who had heard about DESCHALL or the RSA DES Challenge to ¬nd
out more information about the e¬ort, and decide if they wanted to
participate and how they could do so.
Finally, as the work week came to an end, I ¬nished the ¬rst release
of the document and put it into place.
During our discussions about the disappearance of DES Violation
Group, the acceleration of SolNET™s key testing rate, and the possible
implications of a premature e¬ort to recruit people to the 56-bit RC5
e¬ort, something was quietly happening: DESCHALL experienced a
signi¬cant increase in its overall key testing rate.

170 CHAPTER 25

The morning of May 3 turned
out to hold good news for us.
The release of the of the previous
140 day™s statistics showed that we
had started testing the keyspace


. 24
( 41 .)