Treasure maps—encrypted or not—are usually the province of fiction, but every year countless children receive gifts that encourage them to create secret information: diaries. Many parents see diaries as an ideal gift for young school children; the children get to write about what they know and to improve their writing skills. The diary often becomes a privacy problem. The child writes down personal thoughts and feelings she or he does not want to share with others, and then a sibling finds the diary and reads its contents.

Children rarely protect their diaries effectively, though they certainly try. Most child diaries include a lock and key, and modern electronic versions may include keypad-controlled or even voice-controlled locks. Regardless of design, diary locks often are easy to break.

Children also try to hide their diaries: an example of Security Through Obscurity. Hiding may succeed if siblings never have enough time to search for a diary in the owner’s personal space. However, it’s impractical to hide a diary effectively. The child must write in a diary every day, or most days, for it to serve its purpose. Thus, the diary must be easily at hand. This limits the number of practical hiding places. Regular access increases the likelihood that a sibling might see the diary while being moved to or from its hiding place.

In 1881, a 15-year-old English girl named Beatrix Potter started keeping a diary. Unlike typical diarists, Potter developed a secret code and used it to write up her thoughts. In 1901, Potter secured literary fame by publishing The Tale of Peter Rabbit, a classic children’s book.

Fifteen years after Potter’s death, a researcher found her hidden diary and decoded its contents. The actual code is relatively simple by modern standards and could be broken quickly using a computer. At the time, however, literary efforts at code breaking were performed by hand.

Potter is not the only diarist to use a code. Other diarists only used code occasionally and left most of the diary readable. Samuel Pepys, a public figure during the English Restoration in the 17th century, encrypted salacious experiences and impolitic comments about the king. Pepys didn’t design a personal cipher like Potter’s. Instead, he wrote in an obscure and personalized form of shorthand taught at his college.

Charles Wesley, a celebrated 18th-century clergyman, used a similar shorthand in parts of his diary. Most of his diary was published soon after his death, but the coded portions weren’t decrypted until the early 21st century. The coded portions included his observations on scandal accusations made against him and on disputes with his brother, the co-founder of Methodism.

Modern mobile devices rely on encryption to protect their contents if stolen. An Apple iPhone, for example, keeps its contents encrypted unless the phone is unlocked. Thieves can disassemble the phone and extract the contents of the built-in flash storage, but they can’t read the encrypted data.

Encryption transforms readable data (called the plaintext) into unreadable data (called the ciphertext) using secret information (called the key). FIGURE 7.1 illustrates the procedure. Our objective is to keep the readable plaintext hidden from outsiders. We only expose the plaintext when we are “inside” the safe boundary.

The encryption procedure (the algorithm) takes two inputs: the plaintext data and the encryption key. The procedure scrambles the data to produce the ciphertext. If we use high-quality encryption, no one will be able to interpret the ciphertext unless they have the correct key. The recipient on the right side of Figure 7.1 can retrieve the ciphertext by using the appropriate decryption algorithm and key.

The term algorithm should be familiar to computer science students; it is the mathematical term for a step-by-step procedure. We may use it as a synonym for “procedure” when we talk about cryptography.

For encryption to work, there must always be a matching decryption algorithm. These algorithms may be identical in some cases, but not always. The encryption algorithm always accepts two inputs: the plaintext and the key. The output is the ciphertext. The decryption algorithm likewise accepts two inputs: the ciphertext and the key. Likewise, the decryption algorithm yields the plaintext as output.

Following Kerckhoffs’s principle, we must assume that potential threats are familiar with our encryption and decryption algorithms. The secrecy of our plaintext relies entirely on the secrecy of the key.

Categories of Encryption

Encryption algorithms fall into several categories (FIGURE 7.2). To begin with, we have symmetric encryption algorithms in which we use the same key for both encryption and decryption. We focus on symmetric algorithms for now. We study asymmetric (public key) algorithms in Chapter 8.

There are two categories of symmetric algorithms: codes and ciphers. In a code, we apply the transformation to words or phrases in the original text. For example, a military code might have a single symbol for commands like “attack” or “send reinforcements,” plus individual symbols for locations, like St. Paul or Boston. For most codes, the key is a long list of phrases and code values that indicates which stands for which.

In a cipher, we apply the transformation to symbols in the raw text itself. For example, we could encrypt this paragraph by substituting the individual characters with different characters. The key adjusts the transformation so that it varies according to the key’s value.

We classify ciphers further into transposition and substitution ciphers. In a transposition cipher, we rearrange the text of the message. For example, the text “hello world” might be encrypted as “drwolhel ol” through a systematic rearrangement. The original letters still appear in the ciphertext, and the cipher’s key indicates the order of rearrangement. In a substitution cipher, the text letters remain in the same order, but individual letters are substituted with others, again according to the key. Sophisticated ciphers may combine both transposition and substitution.

Beatrix Potter’s diary code was primarily a substitution cipher. She memorized a table of symbols that she systematically substituted for normal text letters. Her encryption also had “code-like” features because she occasionally substituted certain words with symbols, like the words “to” and “too” with the digit “2.”

A Process View of Encryption

Sharing Secret Files: Bob is going to help Alice with her bookkeeping. Alice wants to keep her finances as private as possible. She and Bob agree to encrypt her bookkeeping spreadsheet. They can then share her file on USB drives or email without worrying about others reading it.

FIGURE 7.3 shows the process diagram of Bob constructing encrypted data to share with Alice. The figure shows how information is shared, or not, while passing the data between the two of them. The dark vertical bar separates Bob’s resources from Alice’s.

For Alice to read Bob’s file, the two of them somehow must share the encryption key. The diagram doesn’t show how they share the key. To keep the encrypted data secret, they must not disclose that key to others.

With encryption, we exchange the problem of protecting the file’s plaintext with the problem of protecting the key.

In Potter’s case, the key was a table showing which symbols were substituted for which letters or words. Potter memorized the table, and no physical copy was ever found among her possessions. While we can speculate that Potter may have had a physical copy of her key when she started encrypting her diary, she wisely destroyed it after she no longer needed it.

Shared Secret Keys

The sender and recipient must share a secret key when using symmetric cryptography. This is often the most challenging part of using encryption: to protect the key from disclosure yet share it with the appropriate recipients. In some examples, we simply assume that the participants have shared the key safely. We discuss secret key handling techniques further in Chapter 8.

When we add encryption, we place the information in new and different situations. This yields additional states.In Section 3.5.3, we introduced states and state diagrams. Figure 3.17 illustrated the information states of Bob’s homework file: Storage, Processing, and Transmission.

First, we break the Storage state into two separate states: one encrypted and the other plaintext. We do the same with the Transmission state. The Processing state, however, only operates on plaintext, unless the process actually performs encryption or decryption. We’re not interested in such states right now. This produces five states:

1. Plaintext Storage

2. Encrypted Storage

3. Processing

4. Plaintext Transmission

5. Encrypted Transmission

 

Illustrating Policy with a State Diagram

While working on their survey project together, Bob and Alice need to protect their survey file from disclosure. They also need to transmit it between their computers. They can do so with a USB drive, but they must avoid disclosing the file.

In other words, they never want the file to enter the Transmission state while in plaintext.

The state diagram provides us with a graphical way of illustrating this policy objective. We draw a state diagram that shows the methods by which they handle the survey data. Our policy forbids transmission of plaintext, so we omit states and arrows that might allow it. No arrows connect the Plaintext Storage state to the Transmission state.

The arrows between states need to show two types of information. First, they must show the “cause” of the state transition: the event that triggers the need to change from one state to another. Second, they should explain how the change takes place.

In FIGURE 7.4, the arrows between states indicate both an external event to cause the transition and how the transition occurs. For example, “Open the file” reflects an action by the user that initiates processing, and it also indicates the operation that retrieves the file for processing.

Figure 7.4 illustrates a set of states and transitions intended to keep the survey file safe. Because we never want to transmit the plaintext file, we omit the Plaintext Transmission state entirely.

Note how we mark the arrows between the Plaintext Storage state and the Encrypted Storage state. Each contains an underlined phrase followed by an action. The underlined phrase describes the condition that causes the change between the two states. The second phrase indicates the action that implements the change (“encrypt” or “decrypt”).

Proof of Security

When the U.S. government needs to take extreme measures to protect information, this type of analysis is a fundamental part of the process. When establishing the security policy, the designers specify every state and state change that the system should perform. Then the designers construct a similar analysis of the actual computer system. Finally, they analyze the two together using formal mathematical proof techniques. The analysts try to verify that the actual system never enters the wrong state. When older security experts spoke of systems being either “secure” or “insecure,” a secure system was one that never entered a wrong (“insecure”) state.