. 23
( 41 .)


powerful 64-bit processors, we could get another boost in overall search
speed. We would need this help if we were to stay ahead of SolNET,
which was hard upon our heels. After performing some preliminary
tests, Kindred sent his results to some DESCHALL coordinators. The
results were very impressive.
Kindred™s tests were run on three di¬erent machines. The ¬rst test
was on a Digital Equipment Corporation (DEC) AlphaStation 255/300,
with the 21064A microprocessor running at 300 MHz. As shown in Ta-
ble 7, Kindred™s bitslice client ran 106 percent faster than the available
DESCHALL client for that system, 145 percent faster than the DES
Violation Group client, and 177 percent faster than the SolNET client.
Kindred also compared the speed of his software with bitslicing software
from Australian programmer Matthew Kwan, who also wrote some fast
DES functions.

Kindred bitslice software 1182k keys/sec
DESCHALL client 574k keys/sec
DES Violation Group client 483k keys/sec
SolNET client 427k keys/sec
Matthew Kwan™s bitslice software 361k keys/sec
Table 7. Bitslice Performance on the 300 MHz DEC Alpha Processors
Short Circuit 153

The next test was performed on a DEC AlphaStation 600 5/333
with an Alpha 21164 processor running at 333 MHz. Table 8 shows
that increases there were also signi¬cant: 135 percent faster than the
existing DESCHALL client, 175 percent faster than the DES Violation
Group client, and 216 percent faster than the SolNET client.

Kindred bitslice software 2140k keys/sec
DESCHALL client 907k keys/sec
DES Violation Group client 775k keys/sec
SolNET client 677k keys/sec
Matthew Kwan™s bitslice software 1720k keys/sec
Table 8. Bitslice Performance on the 333 MHz DEC Alpha Processor

Finally, Kindred tried his code on a di¬erent vendor™s system, one
from SGI, long known for their hot graphics computers. On an SGI
Onyx with a 194 MHz R10000 processor, Kindred™s bitslicing code ran
74 percent faster than the existing DESCHALL client, 157 percent
faster than the DES Violation Group client, and 142 percent faster
than SolNET™s client. See Table 9.

Kindred bitslice software 1430k keys/sec
DESCHALL client 823k keys/sec
DES Violation Group client 555k keys/sec
SolNET client 589k keys/sec
Matthew Kwan™s bitslice software 753k keys/sec
Table 9. Bitslice Performance on the 194 MHz MIPS R10000 Processor

DESCHALL already had the fastest clients, but Darrell Kindred
found a way to get them to run even faster. These improvements
were signi¬cant, because they showed that we could literally double
our speed on these sophisticated 64-bit processors like the Alpha and
R10000. Every 64-bit client being upgraded to a client using Kindred™s
software would be like recruiting another new machine. Pentium sys-
tems were still by far the largest contributor of processing power, but
the improvements in the 64-bit system clients would have an immediate
154 CHAPTER 21

Meanwhile, DESCHALL started getting more publicity. Communica-
tions Week ran a blurb about DESCHALL in its “Security Monitor”
column in the April 28, 1997, issue. Columnist Tim Wilson wrote:

So far, about 2500 computers already are working on [cracking]
the [DES-encrypted] message in a cooperative, “brute force”
e¬ort to try every possible key. More than 72 quadrillion possi-
bilities exist, but the group is already trying 50 trillion keys a
day, and more participants are joining in all the time, accord-
ing to Rocke Verser, an independent consultant who developed
the cooperative software in his spare time. At its current rate
of growth, the group could decode the message in as little as
two months, Verser said. Opponents of these export restrictions
hope that if DES is cracked, the federal government will rethink
its regulatory policies.

Wednesday, April 30
Virginia Polytechnic Institute, Blacksburg, Virginia

Blacksburg Virginia, which had been written up in “USA Today” in
the summer of 1996 for being “the most wired town in the world,” (as
determined by the highest number of personal computers per capita)
had a local paper, the Roanoke Times. That newspaper ran a full-length
feature article on DESCHALL in its April 30, 1997 issue, covering the
points we made in our press release and focusing on the contributions
of local participants, including Alex Bischo¬, whose picture was also
printed with the article.
Also on April 30, DESCHALL got attention on the popular Macin-
touch Web site, a daily collection of Macintosh newsbits that thousands
of people hit each day. In response to the recent release of new Mac-
intosh clients, Jim Doolittle, a student at the University of Illinois at
Urbana-Champaign tipped o¬ the Macintouch site operators. The Mac-
intouch site then included news about DESCHALL and provided a link
to the client archive, starting a steady stream of new participants over
the next few days, with the Macintosh clients being download several
hundred times.
Thanks to the publicity”including media, advertising in online sig-
nature blocks, and word of mouth”not only were we searching more
keys every day, but the mailing list also was becoming more active.
Short Circuit 155

After the list bean receiving and distributing about thirty messages
daily, some participants who really only wanted to see announcements
started to ask for a way to keep up with the project without seeing
everything that every project participant posted.
To o¬er some kind of reprieve, I opened a separate mailing list
strictly for announcements relating to the project, including the re-
lease of new clients and important notes about any critical part of the
DESCHALL architecture. The new list went live on April 30.

Beginning in late April, participants would occasionally write to the
DESCHALL mailing list that they noticed delays when their clients
would check in with the keyserver. Others were carefully watching the
size of the blocks that the keyserver was handing to the clients for
processing and reporting their observations to the mailing list. From
these reports, some participants attempted to deduce the status of
the keyserver. A few participants even started talking about “when
DESCHALL adds a second keyserver,” apparently assuming that DES-
CHALL would follow SolNET™s footsteps in the addition of keyservers
to its overall architecture.
Rocke Verser posted a message to the mailing list on April 30, ad-
dressing the question of the keyserver™s status. “The keyserver is alive
and well,” wrote Verser. He continued:

Up until today, it has generally been running at about twenty
percent CPU. Today, it™s probably between thirty and ¬fty per-
cent. I won™t know until the end of the day if that translates
to more keys being checked or whether there were more pack-
ets being dropped on the Internet, requiring the server respond
multiple times to the same request.)
As I sit here, I can watch the “activity” light on the hub
blink in step with the server™s console log. There is no percep-
tible delay between the server receiving packets and the server
responding to those packets.
The server is easily handling over 4000 clients, and could
comfortably handle 4000 more. Since I expect more than 8000
clients, plans are in the works for an additional server. But I
emphasize, we don™t need another server, yet!
156 CHAPTER 21

In an emergency, some minor changes to the keyserver could
be made to increase the size of the average keyspace. Also, a
“backup” keyserver is con¬gured and can be brought online on
very short notice if it becomes necessary.
Some have asked why SolNet is already using multiple
servers. I can™t answer the question with any certainty. How-
ever I™ll note that DESCHALL uses UDP [Unreliable Datagram
Protocol] packets. SolNet by contrast uses TCP [Transport Con-
trol Protocol] packets. TCP has advantages for most protocols.
But for this application, TCP is much more resource intensive
and requires several low-level packet exchanges to accomplish
what a single packet exchange in UDP can accomplish.

Questions about the keyserver subsided”at least for the time being.

Several hours before Verser™s comment on the keyserver, our Australian
participant, Andrew Glazebrook mentioned that he had a server avail-
able to use as a distribution point for DESCHALL software outside of
the United States and asked if any of the o¬cial U.S.-based Web sites
would provide links to his site for users outside of the U.S. and Canada.
I quickly responded that while we could do nothing to stop him from
doing anything that he wanted, we would not likely be able to provide
links from any “o¬cial” Web sites to his. Even though we recognized
the ultimate futility of trying to keep the software in the country, we
had no intention of skirting the regulation while it was still in e¬ect.
Linking to a site where the software was distributed without regard to
the regulation wouldn™t be exporting the software, but a zealous pros-
ecutor might ¬nd a way to argue that we violated “the spirit of the
law,” and none of us could begin to guess where that would wind up.
Glazebrook never did say how exactly he got the software, but we
simply assumed that someone who could download the client, did, and
then exported the software.
On May 1, Glazebrook posted to the DESCHALL mailing list that
his site was distributing the DESCHALL client software for Intel pro-
cessors. In that note, he explained his rationale a bit further: he was
running OS/2 and SolNET simply didn™t have an OS/2 client, so he
Short Circuit 157

¬gured that he could help other potential participants in the same
predicament by having his own distribution site.
While some thought the idea was a good one, Darrell Kindred posted
a note of caution:

It seems quite possible to me that it will cause trouble for Rocke
personally and/or the DESCHALL e¬ort as a whole. Many of us
hope to in¬‚uence U.S. export policy through this contest, and I
don™t think it™s going to help our case if the contest participants
get portrayed as smugglers.
If you™re outside the U.S. and Canada, join the SolNET ef-
fort. We™re all working toward the same goal.

As it turned out, the SolNet OS/2 client was released the day after
Glazebrook posted the announcement of his Australian download site
on the DESCHALL mailing list, but it was much slower than the OS/2
client we had developed. Ronald Van Iwaarden at Hope College in Hol-
land, Michigan tried the SolNet OS/2 client once it was released, and
reported that it tested 270,000 keys per second, while the DESCHALL
client™s 480,000 keys per second.
DESCHALL Community

Though DESCHALL had success in getting very fast client software
developed, we still hand plenty of challenges to overcome. A real sense
of community started to develop among DESCHALL participants as
we worked through these obstacles and many users helped each other
rather than waiting for one of the project coordinators to comment.
One situation where participants were able to help one another in-
vovled tackling the issues faced by users who were connecting to the
Internet via a dial-up modem. Reports ¬ltered in from participants on
dial-up machines. These participants found that their ability to con-
tribute to the e¬ort was hindered, sometimes signi¬cantly. If computers
running the DESCHALL clients had to sit idle for hours, waiting for an
active connection to the keyserver so it could report their activity and
to get more work from the keyserver, any bene¬t realized by having
extremely fast clients on those machines would be lost.
To combat this problem, many of the people running clients on these
machines decided that they would simply remain connected for long
periods of time. Unfortunately, this wasn™t always an option. Many ISPs
at this time oversold their capacity, since not all users who subscribed
to the service would be online at once. As a result, an ISP could have
30,000 subscribers, with the capacity to serve only 15,000 at any one
To prevent users from tying up service capacity unnecessarily by
staying online continuously, ISPs would detect and disconnect users
when the line they were using remaind idle for some period of time”
anywhere from ten minutes to as little as one minute. Generally the rule
of thumb was that the more oversold the ISP, the less time it would
allow its users to remain idle online.

160 CHAPTER 22

Colin L. Hildinger, Games Editor at OS/2 e-Zine, posted his solu-
tion to the problem. Hildinger con¬gured his e-mail program to check
for new mail every ¬ve minutes, thus staying under his ISP™s timeout
period while being permanently connected. By doing this, Hildinger™s
DESCHALL client was free to exchange information with the keyserver
whenever necessary.
Milton Forte II, another OS/2 user, suggested the INJOY dialer,
a program which would allow the system to use a “dial on demand”
feature. Clients using this feature would be able to run DESCHALL
normally even after their ISP dropped the connection because INJOY
would automatically reconnect with the ISP when the client needed to
communicate with the keyserver, just like the freeDUM program for
Windows mentioned on the mailing list three weeks earlier.
Discussion on the DESCHALL mailing list on May 1 showed that
freeDUM worked for only a few participants, leaving most to ¬nd more
creative ways to keep their Windows systems in communication with
the keyserver. Jason Gmoser, a participant from Florence, Kentucky,
decided that he would just stay connected by having his system initiate
a little bit of network tra¬c every ¬ve minutes. It worked well, but after
having been connected for about seventeen hours, his ISP disconnected
him. When Gmoser™s system reconnected, he got a message that despite
being been online all that time, he had only downloaded about ¬ve


. 23
( 41 .)