TEORÍAS QUE ORIENTAN EL QUE HACER PEDAGÓGICO

Thursday, April 10, 12:41 A.M.

Megasoft Online, Columbus, Ohio

Mike Heroux at the University of Washington asked a good question. He wanted to know why we didn’t write a client in Java so that it could run on any type of computer, instead of spending so much time and energy in platform-specific versions. Answering on the DESCHALL mailing list, I discussed the tremendous performance advantage that some implementation strategies had over others. In particular, I pointed to the speed of the 32-bit Pentium clients versus to the clients for more powerful 64-bit processors. I observed that one of the best ways to increase speed was to optimize the client heavily for the specific processor in use, as Verser had done with the Intel clients. Another option I mentioned was the use of the “bitslicing” method described in a recent paper by Israeli cryptographer Eli Biham.

In typical key-search algorithms, the computer’s processor will oper- ate as it normally does—taking blocks of data and performing a series of functions on them. Various techniques were available for reducing the amount of work needed to test a key to see whether it was the right key to unlock the block of data. Biham’s bitslicing key-search method took a rather different view of the problem.

Rather than treating a processor as a single component that works on numbers of a particular size (say, 64 bits), the processor is treated as 64 independent 1-bit processors. Thus, rather than the 64-bit proces- sor changing from instruction to instruction through the course of the processing, each “independent 1-bit processor” performs the same in-

152 CHAPTER 21

struction at each step, but with a different bit each time. This method can be used to reduce the total number of steps needed to test each key, resulting in a dramatic increase in speed. The end result is that roughly 300 instructions are needed to compute DES, where previously over 600 were used in other fast implementations.

This was the theory, at least. It would be up to implementors to prove just how much faster the technique would be.

Monday, April 18, 11:52 p.m.

Carnegie Mellon University, Pittsburgh, Pennsylvania

Darrell Kindred, a Ph.D. candidate at Carnegie Mellon University, had spent the weekend implementing Eli Biham’s bitslicing method, be- cause he was sure that if our clients could use the method, we could increase our key search. DESCHALL’s code for the Intel processors was already the fastest of all known DES key search software thanks to Rocke Verser’s tremendous optimizations for that platform. If Kin- dred could make bitslicing work for DESCHALL’s clients on the more 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 different machines. The first 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

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 significant: 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 different 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 significant, 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 impact.

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” effort 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, theRoanoke 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 Bischoff, 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 off 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.

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 offer 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 fifty 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 configured 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 official 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 “official” 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 effect. 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 find 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

figured 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 effort as a whole. Many of us hope to influence 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.

22