Book Excerpt: Hiding in Plain Sight

Eric Cole

August 4, 2003 (Computerworld)

Chapter 8: Cracking Stego and Crypto

As you've read elsewhere in this book, the only way to test the strength of an algorithm is to have smart people try to crack it. Understanding how you go about cracking a given algorithm will help you grasp the strengths and weaknesses of different approaches to building one.

Building crypto or stego that is strong and will stand the test of time takes a special skill set. It is not the ingredients of an algorithm but the unique way that somebody combines them that differentiates an expert from a mere amateur.

A chef can tell you the ingredients that go into a gourmet pastry, but you can use the same ingredients and the results just won't be the same. Secret communication requires a similar specialized expertise. Just as building strong algorithms is a skill, knowing how to test them or break them also requires a special talent. In this chapter, I'll examine some of the unique techniques that make this a profession where only a few succeed.

Cracking can come in many forms. Now, I'm sure everyone has received a fax where the top of the printout appears to have a set of lines that are elongated and distorted running off the edge, like a product bar code from a box of cereal. Most of us assume it's some automatic fax information with the sender's fax number and name. But did you ever think those wavy lines could contain hidden data?

Eric Cole

Eric Cole is chief scientist at The Sytex Group Inc.'s information warfare center, where he heads cutting-edge research in technology and various areas of network security. An information security expert for more than 10 years, he holds several professional certifications. Eric is the author of Hackers Beware and Hiding in Plain Sight and co-author of SANS GIAC Certification: Security Essentials Toolkit and Security Essentials.

Ahmed was a Middle Eastern businessman in France on a supposedly routine trip. In reality, he was gathering information on foreign power plants for his government. When Ellen Mendez, an information specialist with the U.S. Army, was asked to look at copies of faxes Ahmed had been sending back to his office in Saudi Arabia, she figured out that he had encrypted data with a binary code using 0s and 1s and put lines representing the code at the top of the faxed page.

To the unsuspicious, the lines looked like a fax glitch -- just garbage. But on closer examination she realized they were really a code he was using to transmit data.

Ellen also noticed the way Ahmed would adjust the spacing between letters and words. The code was in the variations of the spacing. She ran a software program used to shift letters in a document to hide data this way, and she discovered hidden data.

Who's Cracking What?

Cracking by the criminal, hacker, or spy elements is done for a variety of purposes, but whatever their motivation, they are out to get information that simply doesn't belong to them.

Cracking by the cryptanalyst community is critical in order to understand whether a given algorithm is strong. By knowing how a technique can be broken, a developer can fix the weakness and, in doing so, make the technique more robust.

Making strong crypto is an iterative approach. When somebody finds a chink in the armor of a particular algorithm, the developer fixes the weakness and makes the crypto more robust. This may happen several times, helping the developer to strengthen the algorithm over time.

NOTE: The general rule of thumb is that you can never rely solely on testing code that you built. That's because you know too much. Because you wrote the code, you might overlook something obvious simply because you are too familiar with the code.

So, the fact that someone is able to crack a technique is not a sign that the technique is no good; it is just a sign that something was missed in the original development. The real question is this: Can the weakness be fixed in a timely manner, in a way that introduces no other weaknesses and that makes the resulting technique more robust?

NOTE: When DES (data encryption standard) was released there were some weaknesses in how the data was broken up before it was encrypted. The developers were able to fix this problem, and the resulting technique was very robust. On the other hand, Double-DES had a weakness that could not be fixed without significantly impairing the algorithm. That's why you don't hear of anyone using Double-DES. Everyone today uses Triple-DES because Triple-DES was able to overcome the weaknesses of Double-DES. This was an example of the meet-in-the-middle attack, described later in this chapter.

Cracking Analysis

Even though most developers of crypto and stego techniques test their algorithms and try to break them, the skill set required to break algorithms is a different skill set than the one used to develop the algorithms or techniques.

Cracking algorithms is actually a separate discipline that could take years, if not a lifetime, to master. In this section, I'll briefly introduce the roles people play in this highly specialized industry.

Cryptanalysts

Cryptanalysts are people who analyze encryption techniques, looking for weaknesses and ways to break the technique. By deciphering a plaintext message encoded with a cryptography technique, the cryptanalyst has essentially broken the code.

A good cryptanalyst knows so much about the inner working of crypto that he or she can usually tell which part of the code needs to be fixed and whether the weakness is a major or minor one.

The cryptanalyst's job is only to find the weakness, not to fix it. Once the cryptanalyst has discovered the flaw, it is the job of the developer of the technique to figure out how to strengthen it.

There are various approaches to breaking a crypto technique. A cryptanalyst might look for a general weakness in the algorithm that impacts all implementations or for a weakness in a specific implementation, though the general algorithm is still robust.

The most common way to break a technique is to find a unique situation in which the technique does not work as intended. For example, let's say an algorithm breaks text into blocks of data and then encrypts each block with the same key. If the block is too short or if the cryptanalyst feeds it large amounts of repeated text, two blocks of data might encrypt to the same value. This could be considered a weakness because any patterns that can be inferred from the encrypted text can help a cryptanalyst break the technique.

Other specific attacks that a cryptanalyst performs are detailed later in this chapter in the section titled Cracking Cryptography.

Steganalysts

Steganalyst is a relatively new term that was developed to refer to someone who tries to break stego techniques. Even though the terms cryptanalyst and steganalyst are similar, their roles are quite different. The difference becomes obvious when you look at the goals of the two techniques.

A cryptanalyst tries to break an encrypted message to read it. The goal of a steganalyst is to detect whether a message has data hidden in it.

Once a steganalyst has determined that a file has a message hidden in it and the message has been extracted, if it is encrypted it then becomes the job of a cryptanalyst to try to break the ciphertext and figure out what the plaintext message is.

The role of detection

With steganography, detecting that a message is hidden is the goal. With cryptography, even though the mere fact that something is encrypted could call attention to it, the main focus is usually not on whether people can detect that data is encrypted; what's important is that no one can crack the encryption and read the plaintext masked by it.

Of course, sometimes the lines do blur and detection of crypto becomes important. In certain countries where the mere use of encryption is illegal or deemed highly suspicious, just the fact that a message or file is encrypted could raise enough suspicion to get those involved in sending and receiving it into trouble.

Detecting encryption

Encryption takes a plaintext message and converts it to ciphertext, which is unreadable. In general, weak encryption has patterns, and strong encryption does not because any patterns that can be found in the ciphertext make it easier to crack.

Another characteristic of strong encryption is that there should be no relationship between the plaintext and the ciphertext. Any relationship between the two makes it easy to crack because that establishes a pattern that can be used to map out the plaintext.

For example, the word "the" appears frequently in the English language. With weak encryption, the word "the" would appear the same way in the ciphertext each time it occurs. Now if I study the ciphertext and notice that three letters are repeated through the message, I can guess that those three letters refer to a commonly used word such as the. If strong encryption does not have any patterns in the cipher text, it may be hard to crack, but the very randomness of the text can help you to detect that encryption is being used.

One final method used to detect encryption involves headers. Encryption applications need some way to identify the files that they encrypted. If you look at a traditional Windows program such as Microsoft Word, it includes some sort of header on a file that tells the application what to do with it. Most encryption programs do the same thing.

PGP or PEM (two popular encryption applications) will actually put their own unique headers at the top of a file to make it easier to find and process the data that they encrypt. Therefore, you could write a program that looks for these unique headers and not only discerns that the data is encrypted, but also determines what application created the encrypted file.

Looking for headers will work in some cases, but this approach turns out to be less reliable than looking for randomness, which you'll look at next.

Out of place encryption

I often work with companies that wish to protect their intellectual property. In one particular case, it turned out that a competitor was releasing similar products and beating them to market. After this happened several times, the management finally realized that something was seriously wrong.

In looking at this company's situation, I noted that it was part of its corporate culture that encryption was not used on any of the servers or for any communication. I was able to use that information to find the person who was committing corporate espionage.

I knew that there were no supported companywide encryption programs and no policies stating that encryption be used. That suggested to me that there should not be any encrypted traffic on the network. Therefore, I set up a system that would pull data off the network and run it through a program that could detect whether data had been encrypted.

I began to see a pattern: Two accounts were being used to send large amounts of encrypted data to anonymous e-mail addresses. This became even more suspicious when I realized that both accounts belonged to the same person. I was able to use the fact that encryption had been detected to focus in on this individual and help the company take legal action, even though I had no idea what the encrypted material said.