<<

. 11
( 41 .)



>>

much less write. To make his programs run even faster, he would man-
ually optimize his programs to run in ways that were counterintuitive
but ultimately faster. When a program would need to perform a series
of calculations, he would look for opportunities to reduce the number
of steps needed by changing the order of the calculations in a way that
would still produce the correct result. An example might be a program
needed to calculate how many matches a league of soccer teams would
need to hold to determine a winner. Many programmers would write
software to list the teams and put them in pairs, creating a “tree” to
represent the winner™s bracket in memory and then having the soft-
ware count the number of branches in the tree. Verser would give the
problem some thought and determine that the answer was always the
number of teams minus one and write software to ¬nd that solution.
Finding shortcuts like this would result in a program that provides the
correct result, but in a dramatically faster way than those written by
others.
It had been some time since Verser had worked on his fast DES
implementation when he saw RSA™s announcement of the challenges.
He pulled up his fast DES software, having found a way to put them
to good use again.
After some additional development, Verser looked at Germano
Caronni™s 48-bit RC5 software. Caronni™s system of messages that the
clients and server would send back to each other”“protocol” in net-
work parlance”was easy to implement, and it got the job done to solve
the 48-bit RC5 Challenge.
Verser then wrote a keyserver”a software system to coordinate
clients, telling them which section of the DES key space to search.
He built the keyserver to use the protocol adopted from Caronni, made
up of simple messages like, “Ready for keys,” “Test block number. . . ,”
“Finished block number. . . ,” and “Stop working.”
Verser™s previously-existing software and his decision to use a simple
architecture allowed him to get a basic distributed DES key-cracking
Organizing DESCHALL 67

system up and running in relatively little time. Focused on building
the system for testing DES keys, he didn™t get distracted in trying to
¬nd an army of willing participants, setting up Web sites and mailing
lists, or even ¬nding a clever name for his project. It was all simply
about RSA Data Security™s DES Challenge. His clients were given such
exotic names as DESCHAL4.EXE for Intel 486 processors, DESCHAL5.EXE
and Intel Pentium (“586”) processors. Verser™s DES Challenge project
would come to be known as DESCHALL.
By using the keyserver in conjunction with the DESCHALL key-
cracking clients, Verser envisioned many of these clients interacting
with the keyserver much like parts of a very large computer, spread
out all over the United States. The keyserver would be the central
coordinating unit, breaking all possible keys into blocks that could
be handed o¬ to the clients for testing. A person with Verser™s client
software on their computer would simply start the DESCHALL client,
which would then ask the keyserver for a block of keys to test. When the
client was ¬nished testing all of the keys in that block, it would tell the
keyserver it ¬nished and request a new block to test. By communicating
with the participants in this way, the keyserver would keep track of
which keys had been tested and which remained to be tested. If the
right key was found, the client would immediately and automatically
contact the server to report the ¬nd.
Because of the e¬ciency of the protocol Verser implemented, the
keyserver could be a modest machine. Verser had such a machine, with
a 66 MHz Intel 80486 processor and IBM™s OS/2 operating system. He
implemented his keyserver in a high-level language known as REXX,
originally written for mainframe computers and later adapted for ma-
chines like the Amiga and PCs running OS/2.
Thus, Verser had the opposite problem that the European DES-
Challenge group had. Verser had a superb software system for cracking
DES, but he didn™t have anyone to help him ¬nd the right key.


Tuesday, January 21, 4:39 P.M.
Longmont, Colorado

Michael Paul Johnson, a programmer working independently on a va-
riety of projects, had an interest in cryptography and had developed
several cryptographic utilities that he wanted to distribute online.
68 CHAPTER 9

Not wanting to break the law on cryptographic software export,
Johnson developed a system that would allow his software to be dis-
tributed after providing notice that the software is subject to export
restrictions and getting some veri¬cation that the user is allowed to
download the software. Johnson™s system came to be known as the
“North American Cryptography Archive.”
To comply with the Export Administration Regulation (EAR) that
was in e¬ect for cryptographic software, Johnson required users to enter
a name and a password. If those checked out, users would be allowed
to proceed to the archive itself, which was in a hidden location that
changed every hour.
Users could get their own names and passwords for the archive by
¬lling out an online form. Users would supply their e-mail addresses,
and then answer three questions:

1. Are you and the computer(s) you are operating both in the
United States of America or Canada?
2. Are you a citizen of the United States of America, a per-
manent resident (with “green card”) of the United States of
America, or a citizen of Canada?
3. Are you aware of the U.S. Export Administration Regula-
tions and similar Canadian regulations?

Users who provided a¬rmative answers to all three questions and
an e-mail address that appeared to be based in the U.S. or Canada
received a name and password for the site in e-mail. Non-answers and
e-mail addresses that did not appear to be from the U.S. or Canada
would result in a denial of access to the archive.
Johnson described this system on a mailing list called Cryptogra-
phy and included a generous o¬er to host cryptographic software for
distribution to North America.
Rocke Verser took advantage of Johnson™s o¬er and decided to use
the North American Cryptography Archive as the distribution point
for DESCHALL key-cracking client software.


Saturday, February 22
Megasoft Online, Columbus, Ohio

After talking with Justin Dolske about Rocke Verser™s fast key-cracking
software, I decided to contact Verser myself. After exchanging some
Organizing DESCHALL 69

pleasantries, Verser let me know where he had put the DESCHALL
clients for download. I started running his key-cracking client software
on about a half-dozen machines at my home o¬ce and a few more back
up at our company headquarters in Freehold, New Jersey.
Word was quietly spreading among people interested in RSA™s DES
Challenge that Rocke Verser™s software was really fast. By March, more
people were running Verser™s DESCHALL key-cracking clients. Verser,
Dolske, and I traded e-mail daily, discussing how to get more people
involved.
As was true with the other DES Challenge projects, the earliest
DESCHALL participants were savvy about cryptography and comput-
ers and so they needed very little help to start participating. They
handled minor di¬erences in the way that their computers were con-
nected to the Internet, sometimes after asking Verser for a little help.
Nevertheless, most people who didn™t know about cryptography had no
idea that software like DESCHALL existed, and they had no idea why
running a DESCHALL client to help someone win the RSA contest was
a good idea.
Coordinating the e¬orts of a slowly growing number of people be-
came increasingly di¬cult. Verser, Dolske, and I all agreed that we
should have a public mailing list, where everything that we would
write about the project would be sent, allowing participants to fol-
low the conversation and to participate in it. (Of course, if we needed
to communicate privately, direct e-mail was still an option.) By having
a public mailing list, we could have people write to the mailing list
when they needed help with the DESCHALL client software, allowing
people other than Verser to answer such queries. This, in turn, allowed
Verser more time to make improvements in the DESCHALL software
itself.
Once a core group of participants had been established, we looked
at the resources that each had available. The main Megasoft o¬ces
in Freehold had good Internet connectivity, and I ran an important
machine there, named gatekeeper. Because gatekeeper was always con-
nected to the Internet, it was the best place to host a public mailing
list to help us coordinate our attack on DES.
70 CHAPTER 9

Saturday, March 29
Megasoft Online, Freehold, New Jersey

As the sun set, I logged into gatekeeper in Freehold from my home
o¬ce in Columbus. I installed a software package known as Majordomo,
which would automatically run mailing lists and keep archives.17
Messages started to ¬‚ow into the mailing list immediately. In the
¬rst hour and a half that the list was online, participants from all over
the country started to enumerate the obstacles before us so we could
set about ¬nding solutions.
Ironically the biggest hurdles to what would turn out to be the
world™s largest computation were not technical, but political. The U.S.
Government had engaged in a three-year criminal investigation of Phil
Zimmermann after a cryptography program he wrote called Pretty
Good Privacy (PGP) found its way onto the Internet and out of the
country in 1991.
The government claimed that its export rules for cryptographic
products had been violated and threatened to prosecute Zimmermann
as a dealer of illegal munitions. Although the investigation had been
o¬cially dropped in early 1996, there was still no precedent”no one
had been known to export cryptography from the U.S., so anyone try-
ing would likely be the test case to see whether the government would
actually attempt to prosecute violations of cryptographic export policy.
Rocke Verser did not like the prospect of becoming the subject of a
government investigation, so he decided to limit his project to citizens
of the U.S. and Canada working in the U.S. and Canada.
Given Zimmermann™s hassles, restricting access to the clients was a
prudent move for Verser, but it did have some pretty signi¬cant con-
sequences for the DESCHALL project. Although the U.S. had played
an important role in the development of computing and the Internet,
the technology wasn™t con¬ned to North America. It had been many
years since the U.S. and Canada contained more processing power than
could be found in the rest of the world combined. People outside the
U.S. who wanted to participate in RSA™s contest would need to ¬nd
another way.
In an article posted to the DESCHALL mailing list, Verser called
for an attorney well-versed in the law surrounding the issue of cryp-
tography, speci¬cally its export from the U.S. to advise us. Although
there was interest, we could not ¬nd a lawyer who could help us.
Organizing DESCHALL 71

Another option that was considered was the publication of the
source code for Verser™s clients. Under the law of International Tar-
i¬s in Arms Regulations (ITAR), descriptions of mechanisms were not
forbidden, but implementations were not allowed outside of the U.S.,
except to Canada. Thus, source code, printed on a piece of paper as
a description of the system could be exported, but the same software
on a ¬‚oppy disk, as an implementation, could not. The problem with
this approach was that it would simply take too long to prepare soft-
ware for publishing, to have the printing and shipping done, and for
the recipients to run the paper through the necessary optical charac-
ter recognition software needed to turn the printed source code into
working software.
What we did not know at the time was that the Clinton adminis-
tration moved cryptographic software from coverage under ITAR three
months earlier. We had no idea that William A. Reinsch from the De-
partment of Commerce described regulatory policy on cryptography
just nine days earlier for the House Judiciary Subcommittee on Courts
and Intellectual Property. Even if we had known that cryptography was
now regulated under the Bureau of Export Administration (BXA), part
of the Department of Commerce, as a “dual-use” technology”that with
military and non-military uses, the rules were so new, we wouldn™t have
known how to follow them anyway.
The ¬nal and most feasible suggestion was to have clients developed
outside of the U.S. work with our project. However, this software did
not exist and as was becoming clear by demonstration in the European
DES-Challenge e¬ort, unless an idea had software to back it up, nothing
more would come of it.
The core DESCHALL group had other problems to address, namely
barriers that prevented machines in the U.S. from participating. There
were two general classes of such machines: systems that were connected
by modems (and were thus often o¬„ine) and systems whose Internet
connections passed through restrictive network ¬rewall systems.
The occasionally-connected were basically all of the individual ma-
chines: home computers that were used for e-mail, the Web, and games.
Without constant connectivity to the Internet, the DES key search soft-
ware would not be able to communicate with the keyserver in a timely
fashion. The keyserver gave out keys in packages that took the slower
computers about forty-¬ve minutes to test. Once the computer ¬n-
ished a batch of keys, it needed to reconnect to the keyserver in order
72 CHAPTER 9

to report its results and get a new batch of keys to test. For most
people whose computers shared the household telephone line, this was
an inconvenience. The problems facing these users would be di¬cult
to address, so we began with an easier problem: getting the systems
behind ¬rewalls able to participate.
Computers whose Internet connections were regulated by network
¬rewalls”millions of them throughout North America”had tremen-
dous computing power and could easily form the basis for the world™s
largest virtual computer, if only we could harness their power by getting
their managers to put the DESCHALL client software on them. The
simple fact that most of these machines ran behind ¬rewalls prevented
them from being able to talk to our keyserver.
The most straightforward way to connect to corporate clients to
our keyserver would be to take advantage of the ever-growing ubiquity
of the Web. Simply stated, we needed clients to be able to talk to
the keyserver via the Web™s protocol: HTTP, the HyperText Transfer
Protocol. HTTP was basically a message format that would specify
how to format a communication between a Web server and a Web
client (like a browser). Many corporate networks already had made the
necessary changes to allow HTTP tra¬c through their ¬rewalls safely.
The challenge facing us there was how to make that happen without
introducing more code into the clients”which needed to be as small
and unobtrusive as possible”and without imposing new requirements
on the keyserver.


Tuesday, April 1, 9:35 P.M.
Worcester Polytechnic Institute, Worcester, Massachusetts

From his dorm room at WPI, student Carleton Jillson was looking at
Rocke Verser™s Web site and was studying some of the basic statistics
that had been made available. Those statistics showed that eight of
the top ten contributors, in terms of keys tested, were educational in-

<<

. 11
( 41 .)



>>