<<

. 20
( 41 .)



>>

project that would rank participation by platform provided the kind of
132 CHAPTER 17

data that the enthusiasts needed to show that their platforms were a
force to be reckoned with.
To ¬nd how much interest there was in a DESCHALL client for
the Macintosh, pre-cognitive science undergraduate student TC Lai at
the University of California at Los Angeles posted to the DESCHALL
mailing list. After getting some favorable responses and signing the
necessary con¬dentiality agreements protecting the DESCHALL source
code with Rocke Verser, Lai started work for a DESCHALL client for
the Macintosh that was ¬rst released on April 29.
Mac users weren™t the only ones clamoring for new clients. Users
with relatively uncommon architectures (such as Solaris/x86, Sun™s
Unix implementation designed to run on Intel-based systems instead of
its own systems with the SPARC processor) also had lots of processing
power available and wanted to join in, as did users of various scienti¬c
and engineering workstations. Almost all of those requests would be
answered in time.
People who were watching our progress closely were interested in
an important number that we simply did not have”the total number
of computer systems that were contributing processing power. We did
not have this ¬gure because the key-testing clients did not have a se-
rial number. What we could do, however, was approximate, based on
several ¬gures that were available to us. The keyserver was keeping
track of the unique Internet Protocol (IP) addresses and counting how
many addresses were checking in; we kept track of this information and
reported it in the daily statistics. However, these reports did not indi-
cate how many processors were testing keys on multiprocessor systems.
Also, all clients behind proxy-style ¬rewalls were reported as a single
client, since all of their data would arrive at the keyserver from the
¬rewall, rather than from the client running the software.
In addition, participants who were using dial-up Internet access with
dynamic IP address assignment found that if they connected to the
Internet, say, ten times per day, they might well have ten di¬erent IP
addresses. Dynamic addressing was typical for home users; since their
systems were not advertising the availability of any information to the
Internet population, there was no need for its address to remain the
same for any signi¬cant period of time. Static addressing was used for
dedicated lines, whether they ran over high-speed lines leased from the
phone company or whether they ran over low-bandwidth modem lines
Milestones 133

that were permanently connected, like Rocke Verser™s home o¬ce that
housed the DESCHALL key server.
Some participants wanted to count the number of clients instead
of using these estimates. One method to get such a count was to put
a serial number into each client, so the total could be counted accu-
rately. Having clients report their serial number when checking into the
keyserver would require a change in the communication between key-
testing clients and the keyserver. Since our overriding concerns were
focused on cracking the DES challenge message, protocol changes were
a last resort and would only be employed when addressing a problem
important to the project™s core function or stability.
In the end, we just reported the numbers that we had, unique IP
addresses, and pointed out that some forces (like ¬rewalls) tended to
de¬‚ate the number of clients, whereas others (like dynamic IP address-
ing schemes) tended to in¬‚ate the number.
The matter of reporting individual contributions to the project came
up again, although Graph-O-Matic had solved the biggest concern of
this type some three weeks earlier. Since Graph-O-Matic generated
its reports from the DESCHALL statistics, it reported contributions
of keys tested by domain name. Some participants wanted to be able
to organize themselves into teams or to have their contributions from
several di¬erent networks (such as home and work) be counted together.
SolNET provided this service by having its client software report the e-
mail address of the client operator along with the results of its testing.
Users could then con¬gure all of the clients they wanted to be counted
together to use the same e-mail address, and enter their e-mail address
into SolNET™s graphing server. Instead of getting just one network or
another this way, all of a user™s clients statistics would be aggregated
together in the report. Since DESCHALL didn™t send e-mail addresses
between clients and servers, Graph-O-Matic could not provide that
functionality. Although DESCHALL coordinators agreed the feature
would be nice, it would require a change in the protocol between the
client and server”something that would pose too great a risk for us to
try unless it directly solved a serious obstacle to the core problem, the
testing of keys.
Another request that came in from DESCHALL participants was
the ability to request larger blocks from the keyserver than the ones
it was handing out. Dial-up users were accustomed to working o¬„ine
and going through the hassle of connecting only when interactive use
134 CHAPTER 17

of the Internet was necessary. With the DESCHALL client running
dial-up users had to reconnect to the Internet ever few hours (around
the clock) or to let the machine sit idle after ¬nishing a block while it
waited for the next connection. Users who did not want to have their
systems connect every other hour started to ask us to give their systems
enough keys to keep them busy for longer periods of time”six, eight,
or twelve hours. Again, this would require a change in the DESCHALL
protocol so we did not implement the feature.
In reality, only individual machines were using dial-up modems and
by this point, the only systems that could not automatically connect
when the DESCHALL client needed to communicate with the keyserver
were Windows machines. Windows users would simply need to wait for
a while before their dial-up woes would be solved.
Finally, another type of request that DESCHALL participants re-
peatedly made had to do with optimizations. Highly sophisticated pro-
cessors (even 64-bit processors) performed poorly by comparison to the
hand-optimized 32-bit 486, Pentium, and Pentium Pro clients that we
had. More correctly stated, the machines with the sophisticated pro-
cessors were fast, but Verser™s optimized Intel code was awesome”with
half of the power of some sophisticated workstations, personal comput-
ers were able to get better than twice the performance. The requests
that began in early April for optimized clients for the other architec-
tures continued unabated through April. There was no doubt that we
needed optimized clients for the 64-bit processors like Alpha, Ultra-
SPARC, and MIPS, but we needed more help before we could deliver
fast code for those users.
The second optimization-oriented requests came from users of the
Intel “clone” processors from AMD and Cyrix. Ultimately, such opti-
mization would require someone who understood the internal workings
of those processors. No one with the expertise would ever step forward
to do the work”there just aren™t very many people who have that
depth of expertise, especially who also had an understanding of how to
implement a cryptographic algorithm like DES. It might even be true
that at the time, a large portion of the people who had experience with
both cryptography and such low-level code optimization were already
at work on DESCHALL or projects like it. Consequently, the users of
the so-called Intel-compatible processors would continue to use the In-
tel 486 client, because it ran the fastest on those systems”though still
nowhere near the speed on the genuine Intel hardware.
18
Gateways




Sunday, April 20
Columbus, Ohio

Justin Dolske and I put the “T2U” (TCP to UDP) gateways into pro-
duction and released the corresponding “U2T” (UDP to TCP) proxy
software that would allow people to participate in DESCHALL by run-
ning clients from behind ¬rewalls. Then we ran into trouble.
Dolske developed the U2T gateway software in the Perl program-
ming language, which made it able to run on pretty much any kind
of computer. This was an important requirement for gateway software,
since participants on corporate networks could have any kind of sys-
tems in use and we could not put the same kind of e¬ort into build-
ing and maintaining gateway software that we put into the key-testing
clients. Perl software could be written once and work without modi¬ca-
tion on dozens of types of computers. One particular problem arose on
Windows-based servers, however. Although Windows systems could run
most Perl code, a critical feature that the U2T gateway needed was not
present in Windows. In corporate environments where a Unix system
could be used, they could just run U2T there. Users in Windows-only
environments were stuck so we started to look for alternatives.
I was initially very supportive of the idea of having Windows-based
gateways. After all, the job that we were trying to accomplish was huge
and we needed as many clients as possible. If Justin Dolske™s gateways
wouldn™t work for every possible participant™s computing infrastruc-
ture, it seemed to make perfect sense that other types of gateways
could be useful.

135
136 CHAPTER 18




After seeing that Dolske™s U2T software wouldn™t work on his Windows
servers, Bret Stastny started to work on U2T software speci¬cally for
Windows systems. On April 22, Stastny posted a message to the DES-
CHALL mailing list that he wrote a U2T gateway for Windows.
Since the Dolske gateway code was already released in the form of
source code (the human-readable version of a program), thus showing
very clearly how the internal gateway needed to communicate with
the external gateways that Dolske and I were running, I assumed that
other contributions of gateways would simply be replacements for the
internal (U2T) proxy, making use of the T2U servers that Dolske and
I had in production for the whole project.
Sadly, Stastny did not just write a U2T gateway. Instead, he wrote
a completely new U2T/T2U gateway pair, using a protocol completely
incompatible with Dolske™s. Essentially, we would need to duplicate all
of Dolske™s proxy architecture on Windows to use Stastny™s software.
None of the DESCHALL coordinators had Windows servers in produc-
tion, and given the instability and management di¬culty of Windows,
we didn™t want to trust a critical piece of the entire DESCHALL project
architecture to a Windows system. The production T2U proxies would
have to be stable, largely self-managing systems. We could not take on
the additional administrative load of an incompatible T2U proxy set.
We asked Stastny to get his internal gateway to work against our T2U
gateway, but that work ultimately did not lead to any success.
Other attempts were made at creating internal gateways for people
who could not run Dolske™s Perl-based U2T. On May 8, Aaron Williams
at Adaptec posted a Java version of the U2T gateway. Java, like Perl,
would run unmodi¬ed on dozens of computer types. Java did a much
better job of hiding the underlying computers™ di¬erences better than
Perl, and a Java gateway would work unmodi¬ed on both Windows and
Unix systems. While the approach”a plug-in replacement for the inter-
nal gateway that used the production external gateways”was correct,
there were some problems. Williams hadn™t worked with us to coor-
dinate the e¬ort and to test the software, so as released, the software
would send malformed updates to the T2U gateways. The gateways, in
turn, forwarded the request along to the keyserver, which would ignore
the message. Any work done by clients using the Java gateways would
be lost.
Gateways 137

The gateway problems didn™t end there. Williams™ subsequent at-
tempts to get his gateway tested and debugged for re-release were also
done without our cooperation. He was testing his software by having
his nascent gateway send messages to the production T2U gateways,
which dutifully passed messages that seemed to look correct on to the
keyserver. Had he coordinated with us, we could have given him the
information on the servers used for testing. Williams™ testing against
the production servers killed the keyserver on May 21. Ninety minutes
later, Verser succeeded in bringing the keyserver back online.
The following day, Verser posted a “Request for Patience and Coop-
eration” to the DESCHALL mailing list. He wrote that the outage had
occurred because a user had been testing some buggy software against
our production keyserver. He added:

I have never claimed the keyserver was bulletproof. Maybe it
should be more robust, considering it™s only handling about a
quarter-million requests per day, and only doling out around
300 trillion keys per day.
You wouldn™t believe the onslaught of strange and bogus
data that comes to the keyserver. The keyserver manages to
deal with most of it successfully. But neither the keyserver nor
my ISP are bulletproof.
If you support the DESCHALL e¬ort, *please* do not test
your code against the production (3.5 billion key/second) key-
server!
Prior to the outage, I urged the person who took down DES-
CHALL to ask for advice on the mailing list. Here is an excerpt
of his response. This e-mail was received about an hour and a
half before the outage, while I was sleeping.
Even if you don™t have experience with ¬rewalls, I do,
and it is a specialty of mine. The easiest way for me
would have been to integrate the tunneling code directly
into your code. Since you won™t let me do that, I will
have to write my own tunnel.

Verser added that the number of keys lost because of the outage was
the equivalent of one Pentium system testing keys non-stop for a whole
year. Verser stressed that he had no reason to suspect that Williams
intended the project any harm, but his refusal to ask for advice and to
wait a few hours for answers from the project coordinators had cost the
138 CHAPTER 18

project a bunch of keys. Though reports from many clients that never
made it to the keyserver would simply be resent until the message got
through, there was a loss of key reports in the system failure; some keys
that had been tested would simply need to be tested again. It was a
disappointing setback”and completely avoidable.
About the same time that work was being started on the gateways,
discussion on the mailing list was focused on getting key-cracking clients
that would run on as many machines as possible. University of Wash-
ington student Mike Heroux asked about creating a client in the Java
Programming Language, so that anyone, on any computing platform
would be able to run it.




Word of mouth and persuasion had worked well for us in getting new
users to run DESCHALL clients on their systems so far. Usually, re-
cruiting new system administrators to the project”or at least allowing
someone to run the clients on their machines”was a simple matter of
explaining the nature and importance of the project.
Sometimes, enlisting support got more complex. When Corey Betka
at the University of Illinois at Urbana-Champaign approached a sys-
tem administrator who had charge of over 150 machines, the system
administrator explained that she™d be happy to run the clients on all
of the machines in her care, if he was willing to help on a “project” of
hers.
The system administrator”who was never identi¬ed by name”

<<

. 20
( 41 .)



>>