. 30
( 41 .)


with a “?” and the other was reported as “Unknown.” Whatever “?”
was, it tested more keys than “Unknown” on May 12, though it was still
behind for the week. Probably a number of the “?” clients were brought
online and would need a few days before their total contribution would
surpass that of “Unknown.”

Keys Tested Platform
115.0642 trillion Windows-Intel
37.340 trillion Sun-Sparc
27.084 trillion Linux-Intel
19.229 trillion MacOS/PPC
12.787 trillion ?
11.809 trillion Unknown
6.585 trillion NetBSD-Intel
5.437 trillion AIX-rs6000
4.728 trillion DigitalUNIX
4.374 trillion OS/2-Intel
3.842 trillion IRIX-Mips
3.658 trillion HP/UX-hppa
3.440 trillion Irix-Mips
2.606 trillion SolarisX86-Intel
2.086 trillion BSDI-Intel
1.618 trillion DEC-Alpha
0.186 trillion MacOS/68k
0.093 trillion Linux-Alpha
0.064 trillion Linux-Sparc
Table 19. Platform Rankings for May 12
An Obstacle

Saturday, May 16
Loveland, Colorado

Failures to route packets properly to and from the keyserver would not
be the only obstacle for DESCHALL to overcome. While DESCHALL
was setting DES key testing rate records during the weekend of May 9“
11, participants were watching their machines™ performance carefully.
Demand for per-domain contribution reports from Justin Dolske™s Web-
based Graph-O-Matic soared far beyond the capacity of the machine
to keep up: it simply didn™t have enough processing power to issue the
reports at the rate they were being requested.
Normally, such a hammering wouldn™t have been a big problem.
In this case, though, the Graph-O-Matic server turned out to be
commissioned for several jobs”as was often the case in university
environments”and all of them required memory and processing time.
Besides trying to keep up with all of that Graph-O-Matic tra¬c, the
machine was also serving network ¬lesystems and routing tra¬c from
one network to another. A machine like that crashing or otherwise being
unable to keep up with the load was sure to get someone™s attention.
Dolske turned o¬ Graph-O-Matic and sent me a note to hasten the
migration of the software to my site, which had a faster processor that
would be better able to handle the onslaught of requests.
As I was working on the Graph-O-Matic migration, I received an
e-mail message from Rocke Verser. Integrity of the DESCHALL project
was critical, so coordinators typically encrypted and signed e-mail to
other project coordinators with PGP, keeping the contents safe from

208 CHAPTER 29

prying eyes and assuring us that we received a true copy. After decrypt-
ing the message, I read its ominous contents: all developers should verify
the security of our computer systems and the safety of the DESCHALL
source code.
Verser™s warning was prompted by the news that someone had bro-
ken into a DESCHALL developer™s computer. The target of the attack
was apparently DESCHALL project secrets, possibly including source
code for the clients or detailed design speci¬cation. Another possible
target could have been the DESCHALL project integrity, perhaps mak-
ing malicious modi¬cations to the DESCHALL client software that
would undermine our project or harm the users who ran the client
software. SolNET withstood an attack already, so we weren™t really
surprised to ¬nd ourselves in the crosshairs of some nitwit.
Analysis of the compromised machine showed that no con¬dential
DESCHALL material was exposed. Apparently frustrated by the inabil-
ity to get DESCHALL information, the perpetrator maliciously harmed
the system, doing some damage to data unrelated to DESCHALL.
Verser asked each of us to ensure that DESCHALL con¬dential in-
formation was protected against unauthorized disclosure and damage.
Although we had been taking precautions, such as encrypting source
code and con¬dential e-mail among coordinators and developers, we
needed to be vigilant and keep our guard up. DESCHALL project in-
tegrity was no longer an abstraction: someone, somewhere wanted to
do our project, and possibly our users, harm.
Even though no one outside of the group of DESCHALL devel-
opers learned of the attack, there was widespread discussion of the
risks involved with distributed computing projects like DESCHALL
and SolNET that week. Much of the fuss was started by an article
that appeared in issue 19.14 of the highly-regarded electronic newslet-
ter RISKS Digest, published by distinguished security researcher Peter
G. Neumann at SRI in Menlo Park, California. An article on client
software integrity was submitted by Thomas K¨nig, a SolNET partici-
pant and graduate student at the University of Karlsruhe in Germany.
Prompted to write about the issue of client integrity assurance by the
recent attacks against SolNET from Finland, K¨nig stated that,

You may remember RISKS-19.09, in which I discussed the
risks in a network-wide attack on the RSA DES challenge: the
Swedish group at http://www.des.sollentuna.se/ didn™t give out
An Obstacle 209

its source, so the client could, in fact, do anything, such as crack
a master EC-card key. The reason given was client integrity.
Well, a month after this, the promised source code release has
not happened. Instead, it appears that somebody disassembled
part of the client, made a version that reported fake “done”
blocks, and then sent these to the servers.
Moral? Don™t ever think that nobody can read compiled
code. Don™t try to run a cooperative e¬ort like this in a closed
development model.

Although DESCHALL developers agreed with one of K¨nig™s con-
clusions (even compiled code can be read by someone with enough
expertise), the criticism of the “closed development model” was signif-
icantly more controversial. Presumably K¨nig meant that distributed
computing projects should give out the source code to their client soft-
ware to prevent problems like SolNET™s. K¨nig did not explain how
giving out the source code would have prevented SolNET from being
vulnerable to the attack from Finland.
Some DESCHALL participants would sometimes complain that we
were putting DESCHALL at risk by keeping the source code and client
development so heavily under wraps. We generally did not address
these requests or criticisms. There was too much work to be done to
get drawn into every possible philosophical debate. Fortunately, some
DESCHALL participants were willing to address other, less sensitive
projects and to take the initiative to get them done.

Dial-up users continued to contribute what they could to the e¬ort, in
spite of the tremeondous di¬culty of keeping them in communication
with the keyserver for long periods of time. These were some of our
most dedicated volunteers, willing to put up with far more hassle to
participate than more typical users who usually had access to faster
and more reliable Internet connections.
We worried about more “typical” users, though, because we wanted
them to join our e¬ort. DESCHALL still needed more clients; on May
11, we had ¬nished testing just ¬ve percent of the total keyspace. We
needed more clients running and we needed things to be easy for would-
be participants if we were going to get time on their machines.
210 CHAPTER 29

Windows programmer Randy Weems joined the DESCHALL project
in the ¬rst week of May. Just a little more than a week later, Weems
posted an announcement of his own to the DESCHALL mailing list: the
availability of a piece of software he wrote to help Windows users with
dial-up Internet access manage their DESCHALL clients. His software
was a graphical user interface for the standard DESCHALL client for
Windows. He called his software DESGUI.
DESGUI ran as a small icon in the task bar, creating a hidden
console window. It started the DESCHALL client and watched the
output, but instead of just showing the DESCHALL client™s text output
to the user, DESGUI drew a graphical display of the client™s progress
and statistics. It also provided the ability to have the log ¬les redirected
to a ¬le, so users who had software that read the DESCHALL client
output could use DESGUI and whatever software they wrote at the
same time.
Doing more than just providing cool features, the real motivation to
use the software was to address the problems with dial-up networking
in Windows. The most critical feature of DESGUI was its ability to
connect to the Internet over a dial-up modem about one minute before
the DESCHALL client would need to connect to the keyserver. By the
time the client was ready to report its status and to ask for another
block of keys to test, the system would be online. After the transaction
with the keyserver, DESGUI would drop the connection. Operating this
way, Windows users participating over a modem would be able to stay
just as productive as the users of systems that were always connected
to the Internet.
Because DESGUI was strictly a front-end for the DESCHALL client
software, it was not actually testing any keys and was not actually a
part of the DESCHALL client. This also meant that there was no need
to coordinate the work needed to get the software tested and integrated
into the core DESCHALL code.
Reaction was swift and clear. It was a big hit, a must-have for Win-
dows users with dial-up connectivity to the Internet. There were a few
bugs in the initial release, which were pretty quickly ¬xed, and DES-
GUI version 1.2 was released. Users reporting problems in the earlier
releases reported that all was well with the new version.
Now that participants running Windows had DESCHALL client
management software, Toronto-based system administrator Ken Chase
asked how long a client had to report their ¬ndings before the keyserver
An Obstacle 211

would ignore the report. Chase naturally assumed that a report from
a client about a block of keys that had not been assigned would be
ignored because it was a false report. He also assumed that a report
from a client about a block of keys that had been assigned a month
earlier would also be ignored as a false report because anything with
even the computing power of a wristwatch should be able to get through
a block of keys in that period of time. But just how long did a client
have to issue a report to the keyserver that would not be treated as a
false report?
Chase asked the question because with DESGUI and the client man-
agement programs like the one that Benjamin Peterson at Notre Dame
built and the one that he wrote himself, it seemed possible that one of
those programs could stop a client from working for some reason, and
keep the program stopped so long that the report would be ignored by
the keyserver once it did ¬nally ¬nish. Based on some earlier commen-
tary on the mailing list, Chase worked with the assumption that the
timeout period was two hours and thought that the way his software
worked might be problematic. Chase™s software ran on Unix systems
running DESCHALL clients. When a user logged into the machine,
Chase™s software would suspend the DESCHALL program™s execution
and wait for the user to ¬nish with the computer. Once the user logged
out, Chase™s software would restart the DESCHALL client, letting it
pick up right where it left o¬”although that could be hours later.
The concern was a valid one, but it turned out that the keyserver
would not ignore such reports. Rocke Verser posted a reply to Chase™s
question and answered de¬nitively: the keyserver was not presently tim-
ing out blocks at all. Of course, it knew which it had issued and when,
and which had not been returned, so reissuing blocks could be done
easily enough if they did turn out to be abandoned. With only six per-
cent of the keyspace tested, though, there was no need to worry about
retesting abandoned keys. Verser went on to say that in the begin-
ning, the keyserver was automatically expiring such blocks it thought
were abandoned, and it could do so again”but that the timeout period
would be set for a day or two, not just a few hours.
The automated methods for key management were safe.

Wednesday, May 14
Capitol Hill, Washington, D.C.

The House Judiciary Committee continued its work on liberating cryp-
tography with the SAFE Act, which survived its ¬rst hurdle just two
weeks earlier. At issue now was a provision that even many of the bill™s
supporters did not like: speci¬cation of new criminal penalties for the
use of cryptography in committing a crime.
This provision prompted a letter to the bill™s sponsor, Rep. Bob
Goodlatte. Signed by representatives from twenty-six organizations (in-
cluding American Civil Liberties Union, Americans for Tax Reform,
Center for Democracy and Technology, and Internet Society), the let-
ter argued that the provision tended to draw attention away from the
criminal act itself and to cast “a shadow over a valuable technology
that should not be criminalized.”
The letter then discussed how such a provision would a¬ect other
more familiar and readily understood technology. “It may, for instance,
be the case that a typewritten ransom note poses a more di¬cult chal-
lenge for forensic investigators than a handwritten note,” wrote the
authors. “But it would be a mistake to criminalize the use of a type-
writer simply because it could make it more di¬cult to investigate
crime in some circumstances.”
During the two weeks since the letter was received, committee
members had plenty of time to consider the argument. Representa-
tive William Dellahunt, a Democrat from Massachusetts, addressed the

214 CHAPTER 30

committee. Dellahunt proposed an amendment to the bill designed to
limit the provision that caused concern among many of its supporters.
Following acceptance of Dellahunt™s amendment, the committee
passed the bill by voice vote, sending it along to the House Interna-
tional Relations Committee for consideration.


. 30
( 41 .)