<<

. 15
( 41 .)



>>

access to the source code and
would soon begin work on porting
the DESCHALL client software
to work on other systems. Verser
had been looking for ways to get
his DESCHALL clients running on
other platforms”such as the hot Fig. 4. Justin Dolske, Matt Curtin, and
graphics-oriented machines from Guy Albertelli at the Ohio State Univer-
Silicon Graphics, Inc. (SGI), the sity, 1997
sophisticated network-centric sys-
tems from Sun Microsystems, the datacenter-friendly RS/6000 systems
from IBM, and the lightning-fast DEC Alpha systems. Verser hoped
that with more platforms able to run the client, we could get greater
numbers of participants, in turn helping us to ¬nd the key more quickly.
In a period of a few weeks, the expanded development team pro-
duced a series of new clients. SGI machines running IRIX 6.2 on MIPS
processors got their own client. IBM™s RS/6000, running AIX 3.2, got
its own client, as did AIX 4.1-based RS/6000s. Sun™s SuperSPARC
processors under Solaris got a client of their own. Additional clients to
follow were for Digital Unix on the fast 64-bit DEC Alpha processor.
Finally, Sun™s Solaris on the Intel processors got a client.
96 CHAPTER 13

While Dolske and Albertelli worked on the clients, I continued think-
ing about the issue of connectivity. Getting those systems behind ¬re-
walls to be able to run DESCHALL clients would require a good look
at our overall architecture.
14
Architecture




DESCHALL™s architecture”the electronic infrastructure to support
the testing of DES keys”was a simple one. As Rocke Verser originally
designed the DESCHALL system, there were only two components: the
key-testing client software that project participants would run on their
computers and the keyserver that would keep the clients coordinated,
making sure that each DES key was being tested”and tested only once.
The DESCHALL keyserver was located in Verser™s home o¬ce in
Loveland, Colorado, about ¬fty miles north of Denver. As clients re-
quested blocks of keys to test, the keyserver would assign those blocks
of keys, keeping track of which blocks were assigned and when. This
keyserver would keep clients from wasting their e¬orts by testing keys
that other clients already tested.
This is how coordinated e¬orts like SolNET, DES Violation Group,
and DESCHALL di¬ered from an uncoordinated key search system like
the DESKR software Peter Trei wrote. DESKR was called an uncoor-
dinated key search because each client would randomly pick DES keys
and test them; no two DESKR clients would coordinate their e¬orts
with each other. So, Trei created his DESKR software and made it
available for people to run if they chose, but he had no “project” to
manage and no way to know how much work was being done by DESKR
clients that people were running. SolNET, DES Violation Group and
DESCHALL all operated as projects independent of one another, but
each with its own architecture of key testing clients coordinated by a
keyserver.
Like the other coordinated projects, DESCHALL™s architecture re-
lied on the Internet to have clients communicate with the server. When
Verser was building the DESCHALL software in January of 1997, he


97
98 CHAPTER 14

had to decide how to get the client and server to send their messages
to each other. Adopting Germano Caronni™s protocol in a February re-
vision of the software, Verser knew what messages to send, but he still
had to decide how to send them. This was a lot like being on vacation
and sending a letter to a friend back home: you know what you™re going
to write (“Having a great time! Wish you were here!”) but you have to
decide whether you prefer the economy and convenience of a postcard
over the cost and reliability of certi¬ed mail.
Verser wanted his DESCHALL clients to run on as many systems
as possible, from all over the country. There wasn™t a need for a great
deal of information to be exchanged between clients and the keyserver”
messages could be terse, and there weren™t many possible messages that
could go between the client and server. Clients needed to ask for keys,
the keyserver needed to provide keys, the clients needed to report on
their status, and the keyserver needed to be able to tell clients when
to shut down. There simply was not much more for clients and the
keyserver to say to each other.
Since many clients needed to be supported by the keyserver, Verser
needed a communications protocol that was lightweight, keeping the
keyserver from becoming so bogged down with unpacking messages
from clients and packaging responses for the clients that it did not
have time to deal with the messages themselves. To address those re-
quirements, Verser chose to have the messages between the clients and
keyserver be sent using the Unreliable Datagram Protocol (UDP).
UDP messages (“datagrams”) are very simple, roughly the equiv-
alent of scribbling a message on to a postcard. Sending the message
is easy to do and they almost always reach the destination without
any problem. Even so, there is no guarantee that the recipient got the
message. If you want to be sure that your message has been received,
you™ll need to have your own method to verify the fact because the
postal service won™t provide proof of delivery on a postcard.
Receiving UDP messages is also very easy and like a postcard. The
computer just receives the datagram and then passes it to a program for
processing. The operating system does not need to count the number of
datagrams to be sure that it got all of the message parts”the datagram
is all there is.
An alternative to UDP is the Transport Control Protocol (TCP),
which involves a lot more work to establish and to maintain the channel
of communication between the client and the server. TCP is generally
Architecture 99

used to establish connections where there will be more than one tiny
message sent in each direction. Designed for sending larger amounts of
data, TCP can break large chunks of data into smaller “packets” that
are numbered and sent separately. The computer operating system on
the receiving end will then take the packets, put them into the right
order, and then hand the reassembled message completely intact to the
program that is listening for that message, as if it were never broken
into pieces at all.
So that messages sent via TCP are always complete, TCP provides
another important feature: guaranteed packet delivery. In this way,
TCP is like certi¬ed mail. With certi¬ed mail, you™ll need to put your
message into an envelope and at the post o¬ce, they™ll put an extra tag
on the outside for the recipient to sign, and the carrier will not release
the letter without a signature. That signature will then be sent back
to the sender as proof of delivery. With TCP, the systems establish a
connection, and then acknowledge receipt of each packet by number.
If one computer sends a TCP packet and the receiving computer does
not acknowledge the packet, the sender will resend the packet until it is
acknowledged by the recipient. The computer has to do more work to
send and receive TCP messages; computer systems can process far fewer
TCP packets at any one time than UDP datagrams for this reason. If
you need to be sure that the message is received, TCP is your best
bet”unless the extra work it requires the system to do is more than
your system can handle.
With either TCP or UDP, Verser would be relying on another proto-
col for messages to be sent from one system to another. That protocol,
Internet Protocol (IP), serves essentially the same purpose for the In-
ternet as the postal system does for global mail delivery. The postal
system de¬nes standards so that anyone can address a message to any-
one else in the world unambiguously. Those standards make it possible
for a message to be carried toward its destination by one mail carrier
after another, until it ¬nally arrives. IP serves the same purpose”it is
literally the protocol that de¬nes the Internet and ties the entire world
together. IP de¬nes the addressing scheme for computers™ global net-
work addresses (Internet addresses, such as 192.168.1.2) and the basic
framework for how to format data for transmission on the Internet,
without regard to which type of computer the recipient is using. Just
as the postal addressing scheme provides foundation so that postcards,
letters, and parcels can be properly delivered, IP provides the founda-
100 CHAPTER 14

tion that allows TCP packets, UDP datagrams, and other chunks of
data to be sent from one computer system on the Internet to another.
Messages that DESCHALL clients needed to send to and receive
from the server were small and could easily be contained in a single
datagram: things like “Ready for keys,” “Test block number. . . ,” “Fin-
ished block number. . . ,” and “Stop working.” Though the messages
were important, Verser decided that it was best to use UDP and then
to have the DESCHALL client software simply wait for a few minutes
after sending a message; if no response came back, the software would
just repeat the send-and-wait procedure until it did get a response.
This choice allowed clients to communicate reliably with the keyserver,
while also allowing the keyserver to operate e¬ciently enough to sup-
port many thousands of clients at a time.
Although the original architecture envisioned by Verser had only
clients and the keyserver, other needs for software arose over the course
of the project. Many of these additions were provided by the partic-
ipants running the clients themselves, developed for their own needs
and shared with other participants through the DESCHALL mailing
list.


Monday, April 7, 8:34 P.M.
Bowne Global Solutions, Piscataway, New Jersey

Unix system administrator Lee Sonko could not run DESCHALL dur-
ing the day at work, but he did not intend to let that stop him from
participating. Using his skills in the Bourne Shell programming lan-
guage, Sonko created two programs: one to start and the other to stop
the DESCHALL client. When combined with the Unix system func-
tionality for automatic process scheduling, these programs would allow
it to be run on Unix machines in Sonko™s care during o¬-hours, while
leaving the machines completely free for use during normal business
hours.
The week before, Sonko posted the source code for his programs so
that other Unix users would be able to have their systems automati-
cally start and stop DESCHALL clients as needed. In his case, he ran
the clients outside of the hours 5:00 A.M. to 6:00 P.M. during the week
and outside of 8:00 A.M. to 5:00 P.M. on the weekends. Although the
DESCHALL client was speci¬cally designed to run with very low pri-
ority, ensuring that any other needs that the systems™ owners might
Architecture 101

have would be satis¬ed before DESCHALL took any processing time,
Sonko, like others, took the additional step of not even having the
clients running when anyone might need to use the systems.
Over the course of several days, Sonko made small improvements
over the original version of his “desstart” and “desstop” scripts. He felt
comfortable that the improvements were worthwhile and he happily
posted his new and improved programs to the DESCHALL mailing list
for others to use at their own facilities.


Thursday, April 10, 6:24 A.M.
Shrewsbury, Massachusetts

Adam D. Woodbury wanted to know what the DESCHALL clients were
reporting as they ran, but he couldn™t watch all of the machines he was
running to see what they were doing. Even if he could watch all the
screens, he had better things to do than watch DESCHALL client out-
put all day, every day. Woodbury decided to write some software that
would watch his clients™ operation for him and let him know whenever
something interesting happened.
The ¬rst issue to address would be the need to have the clients
report what they were doing in some way that could be monitored. The
DESCHALL client software didn™t have any function in it to create a
“log ¬le””a ¬le containing its periodic reports on activity (the number
of keys tested, how quickly keys were tested, whether the key had been
found, etc.) That kind of status was just normal program output”so if
the client got started from the command-line, the output would appear
on-screen. Woodbury decided to create his own DESCHALL client log
¬le by having that program output go to a ¬le instead of to the screen”
an extremely simple procedure with his computers, which ran the Unix
operating system.
Once his DESCHALL clients were writing their output to a ¬le,
those log ¬les could be easily combined to show the activity for all of
the systems. With all of the program output in one place, he could
write programs that would look through the logs for things that he
would want to have reported to him.
Woodbury noticed that when the client reached the end of a block of
keys being searched, it would report “key not found” before requesting
another block from the keyserver. This gave him an idea. He decided to
have his program that read logs and reported progress alert him if the
102 CHAPTER 14

key had been found. He did not know what exactly the client would
say if the key had been found. Searching the logs for the message that
the key was found required knowing what to search for”what exactly
the client would report in that case.
Looking at what he did see from the usual output of the program”
frequent “key not found” messages as blocks of keys were tested”
Woodbury assumed that the client would probably say something like
“key found,” or at least something about “key” without the word “not”
in it. He wrote a program that would search his logs every day at 1:00
A.M. and send him e-mail showing any messages that included the word
“key” without “not” somewhere else in the message.
Woodbury put his program into place shortly after he had joined the
DESCHALL e¬ort in late March and it had been running since then.
When a discussion on the DESCHALL mailing list turned to what the
client would report once it had found the right key, Woodbury wrote
about what he had done and posted a copy of the source code for his
software to search the logs, thinking that perhaps someone else would
¬nd the software useful.


10:57 A.M.
Loveland, Colorado

Rocke Verser read over the program to report messages about keys
that Woodbury posted to the mailing list. Verser recognized that the
program would successfully report the message that Woodbury knew
he was looking for (“key found”) but that it would miss several other
messages that might also be useful.
In addition to the “key found” and “key not found” messages, the
client could report informational messages from the keyserver that users
should be able to see. Verser could, for example, con¬gure the keyserver
to check the version of the client software that a user had, and if it
was particularly old or needed to be replaced for some reason, send
an informational message back to the client encouraging the user to
upgrade to the latest version of the client software. Verser could use
the “informational message” to get any information he needed to users
through the clients, which would have gotten the message as part of
their response to a request.
Verser typed out a quick message to the mailing list, suggesting

<<

. 15
( 41 .)



>>