Cryptographers are often asked a key question: “Can’t I just encrypt my data and simply not tell the attackers what algorithm I used and how big the key is? How can they break my message then?” There are three answers.
Answer 1: They Always Figure It Out Anyway
Attackers can deduce your algorithm without any help from you. Eventually, they always figure it out. Always. Without exception. Never in the history of cryptography has someone been able to keep an algorithm secret.
In war, spies have always found ways of discovering the algo- rithm, whether it originates in a mathematical operation or a machine. They steal it or get someone to reveal it, maybe through blackmail, extortion, or the time-tested cryptanalytic technique known as “the rubber-hose attack.” Agents have always uncovered the algorithm or gotten a copy of the machine. For example, in World War II, Polish soldiers captured the German Enigma machine early in the war. Enigma was the crypto machine the German military used. The allies (namely the British) were able to crack the code more easily because they had the machine in their possession.
Alternatively, the cryptanalysts simply figure out the algorithm. In World War II, U.S. codebreakers were able to determine the inner workings of the Japanese code machines without having one of the machines in their possession.
In modern times, a company called Gemstar Development created a code that converted date, time, and channel indicators into a sin- gle code number. These code numbers were published in TV listings as “VCR⫹.” People who bought a GemStar control box could program their VCRs simply by punching in the numbers, simplifying the process and thus benefiting people who owned the product. Only the Gemstar box knew how to decrypt the code numbers. But Ken Shirriff, Curt Welch, and Andrew Kinsman broke the Gemstar algo- rithm, and they published it in the July 1992 issue of Cryptologia,a trade journal. Now, anyone who wants to decode those numbers
Chapter 2
24
(such as VCR manufacturers) can do it without buying a Gemstar control box.
Another example is RC4, an algorithm invented in 1987 but never published. Cryptanalysts and other experts studied it and deter- mined that RC4 was a good way to keep data secret. But the com- pany that created it, RSA Data Security, never made the inner workings of the RC4 algorithm public. This secrecy was for monetary and not security reasons; the company hoped that by keeping it secret no one else would implement and sell it. In 1994, anonymous hackers posted the algorithm on the Internet. How did they figure it out? It was probably by stepping through a copy of the object code with an assembly language debugger. Incidentally, RC4 is now used as part of Secure Socket Layer(SSL), the World Wide Web’s secure communication protocol (see Chapter 7). RC4 is arguably the most commonly used symmetric cipher, even more so than DES, discussed later in this chapter in the section “Digital Encryption Standard.”
If a cryptographic system is hardware-based, engineers open it and look at the internals. In 1998, David Wagner and Ian Goldberg, at the time graduate students at the University of California at Berkeley, opened a supposedly secure digital cell phone and cracked its code.
Sometimes it is possible to keep an algorithm secret long enough to be effective, but eventually the enemy figures it out. For example, in World War II, the U.S. Army used Navajo soldiers to communicate. They simply spoke in Navajo. The Japanese military did not have anyone in its employ who spoke Navajo, nor did it have dictionaries or other reference material. The encryption worked because the algorithm (the Navajo language itself) was kept secret.
Now, of course, any large military has linguists on staff who either know or can easily learn any language used to encrypt secrets.
Answer 2: You Can’t Make Money Developing
Secret Algorithms
Gemstar did make money for a while using a secret algorithm, but only until someone cracked it. The ultimate problem, though, goes deeper. Think about it this way: How can you sell something without letting buyers see what they’re buying?
tem to an e-mail vendor, enabling it to encrypt messages. How could you prevent this client, or anyone else, from looking at your code? There are plenty of ways to reverse-engineer software, as shown in the RC4 story.
“Fine,” you may counter, “I won’t sell my algorithm to just anyone. I’ll make sure that only people I trust can use it.” Is it possible to trust enough people to make money that way? And how are your trusted clients going to use your algorithm? About the only thing they could do so is store their data and talk to each other. But people want to communicate with others who do not purchase their algo- rithm from the same vendor. As a result, the algorithms must be standardized, and that means they must be public.
The other problem with trying to sell algorithms arises on the buyer’s side of the arrangement. If you want to use cryptography, you must employ a hardware device or a software program. The problem is this: Just as you have access to the product, so do attack- ers. Where did you get your hardware or software—a retail software store, a business-to-business vendor? Attackers can go to the same source and get their own copies.
In short, if you use your own algorithm and want to keep it secret, you can’t sell it. As a result, you can’t make any money.
Answer 3: Publicly Known Algorithms
Are More Secure
Let’s say you’re the purchasing agent for your company and it’s up to you to decide which cryptographic algorithm to buy. Your company will use this algorithm to store data and communicate securely. Two sales reps offer their products. One warns, “This algorithm is secure as long as the attacker does not know its inner workings.” The other proclaims, “You can tell attackers what the algorithm is and how long the key is, but they can never retrieve your sensitive data without the key.”
Which one would you buy?
If it is possible to build a cryptographic system in which the algo- rithm is completely known, and if attackers still can’t break it with- out the key, isn’t that system more secure than one that can be broken if the algorithm is uncovered? Well, it is possible to build such cryptographic systems.
To answer that question, let’s consider what the word “random” means. You probably have an intuitive idea of randomness, and most likely it’s correct. To be more formal than intuition, we could put it this way: “If someone knows what the currentnumbers are, is it possible to predict the
nextnumbers?” To put it the way cryptographers prefer, random values are simply sets of numbers that pass statistical tests of randomness and are unrepeatable.
Suppose that you choose a few thousand numbers and ask a mathe- matician, “Are these numbers random?” To simplify things and to conform to computer conventions, you make the numbers binary, meaning that they are sequences of 1’s and 0’s. The mathlete will draw on a set of tests
Chapter 2
26
When algorithms are made public, cryptanalysts and computer engineers get a chance to examine them for weaknesses. If an algo- rithm is vulnerable, you can choose not to use it. Otherwise, you can be confident that your data is safe. If an algorithm is kept secret, on the other hand, analysts will not be able to find any weaknesses it may have. Does that mean it has no weaknesses? Not necessarily; it simply means that you don’t know whether or not it is vulnerable. Maybe a cracker, lurking somewhere in a basement, has obtained a copy of the algorithm (remember, they always do) and has already found a successful attack. But this cracker has decided not to share the information. If you use the secret algorithm, all your data is com- promised but you don’t know it.
When an algorithm is made public, however, that’s no guarantee that it is secure. Maybe analysts have not yet found the weakness, and the basement-dwelling cracker has found it. But great minds thrive on finding flaws in public cryptographic systems. There’s prestige (and sometimes a little money) in finding chinks in the armor. If the cryptographic community cannot find something wrong with an algorithm, there’s a good chance that no one else will.
Sources: See David Kahn’s The CodeBreakersfor the histories of the Enigma, Purple, and Navajo codetalkers. See Cecil Adams’ Return of the Straight Dopefor the Gem- Star story.
that examine the numbers. Among these tests (see Figure 2-5) are ques- tions such as these: Are there roughly the same count of 1’s and 0’s? Do some patterns of 1’s and 0’s appear “too often”? Do some patterns of 1’s and 0’s appear “not often enough”? If the numbers pass the tests, we say that the numbers are probably random. “Probably” random? Can’t we say “definitely” random? No, we can’t, and in a few paragraphs you’ll see why.