Testimony before the House Judiciary Subcommittee on Courts and In- tellectual Property was compelling across the board. Everyone seemed to agree that the stakes were high and that breaking encrypted mes- sages by brute force was a hard, time-consuming problem, even for well-funded government agencies.
The Justice Department’s Robert S. Litt provided some of the day’s most interesting testimony, not only providing estimates on the diffi- culty of cracking a cryptosystem by brute force, but specifically pro- viding an estimate for cracking DES keys. Litt even cited the source of his estimate—NSA, the very same intelligence agency responsible for the brilliant cryptanalysis that uncovered Soviet spies operating in the United States after World War II. If anyone understood cryptography, it would be NSA.
NSA’s estimate, he said, was that even with a $30 million su- percomputer it would take a year and several months to decrypt a DES-encrypted message by brute force. Litt’s argument was especially strong, drawing on the common knowledge that supercomputers were the fastest and most powerful computers available. Indeed, supercom- puters were very good at dealing with very complex problems, tracking huge amounts of data, and working with gargantuan numbers.
But finding cryptographic keys in a brute-force attack isn’t a large, complex problem. A search wouldn’t need many data and the numbers involved weren’t very big, at least as far as computers were concerned. Finding a key by trying every single one until the right key is discovered was really a large number of very small problems. The security of the system relies in the sheer number of keys that must be tested to find the one that unlocks the message.
You might think about a test that would require you to solve arith- metic problems like 1 + 3 and 9 + 4. Those problems aren’t difficult at all, but if you must finish the test in an hour and there are one million problems, you might not be up to the challenge.
There are several ways that you can increase your chances of success. You could have all of your friends work on the test with you, giving each person a separate sheet of paper with some of the arithmetic prob- lems on it. Perhaps your friends might recruit their friends, and you could increase the number of people helping you on your test further still. Having a mathematician join the project isn’t going to help you much, though. While a mathematician can perform much more compli- cated operations and can work with much larger numbers, a fifth grade student could solve simple arithmetic just as quickly as the greatest mathematician in the world.
Using supercomputers to find DES keys would be just as expen- sive and inefficient as using mathematicians to solve a large number of trivial arithmetic problems. Just as an army of fifth graders would be cheaper and more effective in finishing a million-problem test of arithmetic, a large number of regular computers would be much more effective than a single supercomputer in finding a cryptographic key.
The fundamental issue here is how easily the problem can be “parallelized”—broken into steps that can be performed simultaneously by different computers, instead of all in order, one at a time. Engineers often illustrate this problem by pointing out that bringing a new person into the world is not something that can be parallelized. One woman is pregnant for nine months before we have a new person. We cannot expect a baby at the end of a month by impregnating nine women.
Testing cryptographic keys can be easily parallelized, just like a large number of trivial arithmetic problems. To show how supercomputers and desktop computers compare in this contest, let’s assume that a supercomputer can test a cryptographic key in one second and that a regular desktop computer can test a cryptographic key in ten seconds. One supercomputer (at, say, $30 million) will be ten times the speed of a single desktop computer (at, say, $3000). That same supercomputer would be the same speed as ten desktop computers ($30,000). The same supercomputer would be one tenth the speed of 100 desktop computers ($300,000).
Almost since the beginning of digital computing, our machines have become smaller, less expensive, and faster. Where a single, monolithic
Supercomputer 59 machine used to serve a user community, subsequent generations of computers have become more efficient and more numerous. By 1997, personally-owned computers were commonplace in homes and dorms, and those machines were many times faster than the kinds of minicom- puters and even mainframes that were used a decade or more earlier.
At the same time, progress in telecommunications allowed comput- ers to communicate with each other as they had not been able years earlier. The rise of the Internet enabled this trend to the point where every computer in the world had the ability to communicate with nearly every other computer in the world.
Part of what made the Internet special was that it was not a network of computers, but of networks. Having Alice put her machine on a network would allow it to communicate with others on that network. Bob putting his machine on a network allowed his computer to talk to others on that network. The Internet made it possible for Alice’s and Bob’s networks to connect to each other.
Though many academic and business environments had dedicated connections to the Internet, individual users would typically use modems to call an Internet Service Provider (ISP). The connection was only temporary, though, and would only stay active as long as the user needed to be able to exchange email, to surf the web, or to read arti- cles.
Very large numbers of computers were out there, able to commu- nicate with other machines on the Internet. The question was how to get them to cooperate with one another and apply their energies to a singular problem like finding the particular DES key needed to read the encrypted message, thereby solving the RSA challenge.
RSA didn’t put limitations on how anyone could solve its challenges. With 40-bit and 48-bit RC5 challenges already solved, the world’s cryp- tographers were thinking seriously about how to increase the efficiency of a large-scale key search computation.
Increasing the number of computers looking for the key is one way to increase the efficiency of the search, but two other important options are available to the cryptanalyst who wants to use a brute-force attack. The first is to increase the efficiency of the software itself, and the other is to wire the instructions needed to find DES keys directly into a computer’s hardware.
Consider the first option—efficiency in software itself. This alone can have a dramatic improvement in performance. When people write
programs for computers, they typically use languages that were created for the specific purpose of communicating an algorithm or program specification to a computer. Computers don’t run the programs that are created by the human programmers. Instead, programmers will write software in a computer language like Java, Lisp, or C++. The version of it that programmers work with is called source code. When the software is finished, the programmer will invoke a program called a compiler to read the source code and turn it into a form that the machine can read and run directly, known as the binary executable or
object code.
In essence, the compiler will translate what the programmer says into something that the computer can do. Building software this way is economical and frankly much more practical than having people write object code directly. By making the process of creating the software easier, we reduce the amount of “people time” needed to create a fully operational system and to get it running. Since general-purpose com- puters like your typical PC, Macintosh, or Unix system are so fast and cheap and people are so expensive, we ultimately save huge amounts of money having computers do things for us.
If a program was generated by a compiler, its speed is nowhere near what it would be if the programmer with the skill took the extra time to write the program in a language that the computer can understand. A computer language known as Assembler makes it possible for a programmer that knows the machine very well to be able to create ex- tremely efficient code which is tailored to a given machine and contains very specific instructions.
An intimate understanding of the computer will allow the program- mer to write code that performs the job in very few instructions, taking advantage of any little feature that a particular computer has available. Languages (like Lisp and Java, mentioned earlier) are typically called “high level” when they allow the programmer to work on a solution without thinking much about how the computer is actually going to get the job done. “Low level” languages (like Assembler) re- quire the programmer to specify exactly how the machine will store and manipulate the data in order to solve a problem. The difference between high-level and low-level languages is roughly the same as say- ing “walk down the street with a little spring in your step” and saying precisely how much to move each muscle in the body in order to move down the street. Writing programs in Assembler is comparatively hard
Supercomputer 61 work. Relatively few programmers can write in Assembler, because it requires much more intimate knowledge of computer hardware—a level of knowledge that many programmers simply lack.
A program written so “close to the metal” can be extremely fast on the system it was designed for. Any variation in that system, though, can slow it down dramatically. Even an upgrade in processor type (from one Pentium model to another, for example) will alter the processor’s internal structure, making a program that ran very quickly in the old system perform very badly in a newer and faster system.
Peter Trei was able to implement his DESKR program in relatively little time because he didn’t take the time to make the software search for keys as fast as the machine could possibly do it. Instead, he chose the language that most cryptography software is written in, known as C, a sort of mid-level language that doesn’t let the programmer completely forget about the hardware, but doesn’t require him to specify exactly what to do with every single bit in the entire system. That flexibility also allowed Steve Gibbons to make relatively minor changes to the software so that it would work on his computers and for me to make other minor changes so it would work on my computers. If Trei had built his software in Assembler, we would have had to write some parts of the DESKR software almost from scratch to work on other computer systems.
The only question remaining was whether key-searching software written in C was fast enough to get the job done. If not, the new key- cracking system would have to be written in Assembler, or possibly something even faster.
Building a physical system to perform a brute-force attack in hard- ware would increase its efficiency further, making it even faster than Assembler. However, the issues that need to be addressed when imple- menting a program in Assembler are still present when implementing that same program directly in hardware. Even worse, hardware imple- mentations require building or physically wiring special-purpose equip- ment, which is much more expensive than reprogramming software.
Whether to crack keys with regular software written in a high-level language, specialized software written in a low-level language, or with custom-built hardware comes down to how fast the system needs to find keys and how much time and money can be thrown at building the system.
Litt said a supercomputer would take over a year to crack a DES key. If it took too long to solve RSA’s DES Challenge, the government would have proved its point about the difficulty of breaking encrypted messages by brute force and we would have no choice but to shut up. The public policy debate over the freedom to use strong cryptography in the United States could be heavily influenced by how cryptographers would respond to the DES Challenge. We had a lot of decisions to make, and we had to choose well.