. 27
( 41 .)


Keys Clients Domain
30 Billion 1 sollentuna.se
Table 11. Surprise Entry in May 8 Report

Friday, May 9, 4:20 P.M.
Sollentuna, Sweden

SolNET DES project coordinator Fredrik Lindgren grinned as he read
the DESCHALL mailing list and saw the question, “Hey, don™t they
have their own project?” The day before, Lindren went to Andrew
Glazebrook™s Web site in Australia and downloaded a copy of the DES-
CHALL client. Lindgren posted a friendly note to the DESCHALL
mailing list explaining that he simply wanted to see how the DES-
CHALL client ran and wished us well.
Some DESCHALL participants suggested that it made sense for
someone from SolNET to check our progress so that they wouldn™t test
the keys that we™ve already tested. Someone else then suggested that we
should “respond” to the “o¬ense” by blocking requests to the keyserver
from their domain and changing the way that we assign blocks of keys
to test.
Threats 185

Justin Dolske sardonically responded to the suggestion of block-
ing SolNET™s communication with our keyserver with a mock-paranoid
message posted to the DESCHALL list. He wrote:

That wouldn™t help. Sollentuna is run by the NSA [National
Security Agency], and they™re already using alien technology
to read Rocke™s brainwaves. In fact, part of the [non-disclosure
agreement] the rest of the developers have signed requires us to
wear a hat wrapped in tinfoil, to try and protect our thoughts.
Additionally, we are starting to suspect that most of the do-
mains “helping” DESCHALL are, in fact, fronts for the NSA,
FBI, BATF [Bureau of Alcohol, Tobacco, and Firearms], PBS
[Public Broadcasting System], and UN [United Nations]. In the
next few days, we will be locking out all of the currently partic-
ipating domains, in order to keep out these secret government

Many others responded more seriously, pointing out that we™re really
all working for the same goal. Rocke Verser summarized the issues
nicely in his response. He wrote:

SolNET has placed us twelve seconds closer to the solution.
It™s not my concern how they got the software. I suppose it™s
the concern of the FBI. All I know is they didn™t get it from me.
The U.S. border leaks like a sieve with respect to cryptography
products. (Another example of how U.S. law hurts U.S. indus-
try: the products get to foreign soil anyway but royalties don™t
come back to the U.S.)
SolNET has announced that they preassigned their “master”
keyblocks in a random order, and that they are distributing their
keyspace in the order preassigned.
DESCHALL does not issue its keys sequentially, but it™s not
entirely random, either. How DESCHALL assigns and processes
keyspace is subject to the Non-Disclosure Agreement our devel-
opers have signed, so further comment is inappropriate.
As far as blocking their requests”I have no intention of
blocking anybody™s request unless they somehow abuse the key-
As far as disallowing their access to the mailing list”I trust
that Matt will continue to allow everybody to read our mailing
list! (I read SolNET™S mailing list.)
186 CHAPTER 26

SolNET and DESCHALL are working competitively, toward
a common goal. I certainly hope that a DESCHALL client ¬nds
the key. But if the Probability Gods gave me the choice of letting
SolNet ¬nd the key tomorrow or DESCHALL ¬nding the key in
forty-four weeks, I™d let SolNET ¬nd it tomorrow.
And ¬nally, the SolNET organizers are a class act. They have
never said or done anything distasteful or disparaging towards
They were forthcoming when they discovered their server
had been [attacked]. (They could have pretended it wasn™t hap-
pening; they could have continued to claim a highly in¬‚ated
keyspace rate, but they didn™t.)
As I said in my posting to their mailing list a few days ago:
“If U.S. export laws weren™t what they are, I suspect we would
be collaborating.”

The campus rivalry that had been stirred up continued over the course
of the next several days”this time with UIUC and Georgia Tech.
Statistics showing progress on May 10 put UIUC at the top of the

Keys Clients Domain
22.28 Trillion 543 uiuc.edu
22.21 Trillion 683 gatech.edu
Table 12. UIUC Ahead of Georgia Tech, May 10

Georgia Tech™s Perry Minyard found another important entry in the
logs. A group of four machines working in the network address space
of did not have names in the reverse DNS”the mapping
of IP addresses to names. Hence, they showed up as IP addresses in
the statistics, and not part of the record for gatech.edu. Looking at
those statistics together produced a di¬erent result. Minyard proudly
proclaimed Georgia Tech the site leader in keys tested.
Dave Terrell and Jay G. Lickfett, both at UIUC, then noticed an-
other important line in the same DESCHALL progress report. A client
Threats 187

Keys Clients Domain
22.30 Trillion 687 gatech.edu and 130.207
22.28 Trillion 543 uiuc.edu
Table 13. Georgia Tech Ahead of UIUC, May 10

was participating from the network without reverse DNS.
The network belonged to none other than UIUC. Terrell
and Lickfett recalculated the results with glee.

Keys Clients Domain
22.31 Trillion 544 uiuc.edu and 128.174
22.30 Trillion 687 gatech.edu and 130.207
Table 14. UIUC Ahead of Georgia Tech Again, May 10

Kees Cook at UIUC took a look at the graphs to see total keys
tested and found that UIUC had tested roughly 350 trillion keys in
total, while Georgia Tech had so far tested about 80 trillion keys. Giving
credit where it was due, though, Cook noted how quickly Georgia Tech
brought so much computing power online.
Getting that many clients cranked up in such a hurry was indeed an
accomplishment. Those Georgia Tech guys knew just what to do. Geor-
gia Tech student Jason Bennett relayed the story on the DESCHALL
mailing list.

Actually, there™s a great story here. A few weeks ago, [Sports
Illustrated] released a poll saying the University [sic] of Georgia
has the best mascot. Well, the local paper decided to run its
own little poll on its Web site. Unfortunately, they forgot to
check for multiple votes. So, some Tech people go on the [local
Georgia Tech] newsgroups and persuaded some others to run
scripts and hit the server with tons of votes. We won the poll.
Flash forward a week or so, and Vincent (I think) posts a
message about needing more people on DES, since MIT and
[another] school [were] beating us. Like moths to a ¬‚ame!

Just before the UIUC and Georgia Tech battle for ¬rst started,
Rocke Verser made an important announcement.

Tuesday, May 6, 3:05 P.M.
The Ohio State University, Columbus, Ohio

Part of building the world™s fastest DES-cracking system was getting as
many “nodes” as possible”computers running DESCHALL client soft-
ware. Ohio State graduate students Guy Albertelli and Justin Dolske
were making sure that people who wanted to participate would be able
to do so, even if they didn™t have equipment that was exactly main-
Among the machines that Ohio State had were the sleek black com-
puters produced by NeXT Computer, Inc. Apple founder Steve Jobs
started NeXT after losing a boardroom showdown with then-CEO John
Sculley in 1985. Despite never enjoying the huge commercial success of
Jobs™ other projects, including the Macintosh and the Apple II, NeXT
machines could be found in universities and other institutions popu-
lated by early adopters of new technology around the country.
Albertelli produced a DESCHALL client for the black NeXT com-
puters by porting Rocke Verser™s key-testing software written in the
C programming language. (See page 93 for a description.) Though the
number of NeXT computers running in the U.S. and Canada was small
by comparison to other platforms, they still numbered in the tens of
thousands. Enlisting the aid of these machines would not prove di¬-
cult because even in the companies and universities that had the black
NeXT computers, the machines had largely fallen into disuse, meaning
that there would be little competition for their resources.

190 CHAPTER 27

After building the NeXT DESCHALL client, Albertelli put the soft-
ware through the testing and quality control process that Verser im-
posed on all developers. Once the tests were ¬nished and Verser gave
approval to release the client, Dolske put the client into the DESCHALL
client distribution archive at Ohio State and I did the same at Megasoft
Online. Albertelli drafted a quick message to the mailing list that the
NeXT client would be available soon. Over the course of several hours,
several dozen distinctive NeXT computers joined the hunt for the key.
From his own NeXT computer (which was now running the DES-
CHALL client), project participant Michael D. Stan¬ll thanked every-
one who worked on the production of the NeXT client. He noted that
while the aging NeXT machine was testing a modest 2.4 billion keys
in its ¬rst day of operation, it was happily contributing what power it
had. Stan¬ll™s fast 64-bit computers from SGI were testing keys at a
much faster rate, but he started to wonder about the promised bitslic-
ing clients for his 64-bit machines. It had about a week since Kindred
shared the results of his tests with the DESCHALL mailing list readers,
so Stan¬ll asked for an update on when those clients would be released.
While the mailing list had been quiet on the topic of bitslicing for a
week, the developers were thinking of little else as Friday approached.
Throughout the week, Kindred™s bitslicing work was being integrated
with Verser™s fast DES key testing method, and the other developers
built, tested, rebuilt, and retested the client software under their care.
On Friday morning, the new version of the client software made it
through the last tests and Verser sent the whole set to Dolske and me
for inclusion into the DESCHALL client distribution sites.

Friday, May 9, 3:21 P.M.
Loveland, Colorado

Users of high-end engineering workstations with 64-bit microprocessors
such as DEC™s Alpha and SGI™s MIPS had long been using the slower,
portable client implemented in the C programming language. Fast, ex-
pensive machines with that slower key-testing software simply could
not test anywhere near the number of keys per second that the rela-
tively slow and cheap machines running Verser™s fast software could.
High-end system users™ frustration would soon end.
A grueling week of client software integration, building, and testing
was about to come to an end, but to make the most of it, Verser had
Overdrive 191

to get his message posted before the majority of participants in the
Eastern time zone went home for the weekend”and it was already
approaching 5:30 P.M. there.
After receiving word from Justin Dolske and me that the DES-
CHALL distribution sites were ready, Rocke Verser posted a message
to DESCHALL™s announcement mailing list.
In a message entitled, “Ultrafast 64-bit clients!” Verser wrote,

If you™ve got a 64-bit Alpha or SGI”stop running the DES-
CHALL client that you™ve got right now. Run (don™t walk!) over
to the DESCHALL archive and download the NEW client for
your platform. These new clients implement a derivative of the
Biham™s bitslice method for doing DES encryption, and they™re
blazing fast.

These new clients, using the bitslicing method (described on page
151), more than tripled the speed of some of the clients. Considering
that many of the largest contributors of processing power were univer-
sities with the kind of high-end systems that used these 64-bit proces-
sors, we expected the overall DESCHALL key testing rate to increase
dramatically as soon as the new clients got put into place.

Keys per second
(in thousands) Relative
Machine Old New Speed
SGI Onyx2 (194 MHz R10000) 829 1943 230%
SGI Indy (180 MHz R5000) 370 820 220%
AlphaStation 255/233 451 1297 290%
AlphaStation 600 5/333 916 2944 320%
DEC Alpha 3000/400 200 600 300%
SGI PowerChallenge2 (R8000, 90 MHz) 233 820 350%

Table 15. Performance of First DESCHALL Bitslice Clients

DESCHALL long had the fastest DES key testing software”and
some of the clients had just gotten much, much faster.
The day after the release of 64-bit clients for SGI and DEC sys-


. 27
( 41 .)