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