The mathematics behind cryptosystems is only part of the picture. Implementation is also very important. The best systems, when used incorrectly, can lead to serious problems. And certain design considerations that might look good at the time can later turn out to be bad.

We start with a whimsical example that (we hope) has never been used in practice. Alice wants to send a message to Bob over public channels. They decide to use the three-pass protocol (see Section 3.6).

Here is a physical description. Alice puts her message in a box, puts on her lock, and send the box to Bob. Bob puts on his lock and sends the box back to Alice, who takes her lock off the box and sends the box to Bob. He takes off his lock and opens the box to retrieve the message. Notice that the box always is locked when it is in transit between Alice and Bob.

In Section 3.6, we gave an implementation using modular exponentiation. But Alice and Bob know that the one-time pad is the most secure cryptosystem, and they want to use only the best. Therefore, Alice and Bob each choose their own one-time pads, call them $K_A$ and $K_B$. Alice’s message is $M$. She encrypts it as $C_1=M\oplus K_A$ and sends $C_1$ to Bob, who computes $C_2=C_1\oplus K_B$ and sends $C_2$ back to Alice. Then Alice removes her “lock” $K_A$ by computing $C_3=C_2\oplus K_A$ and sends $C_3$ to Bob. He removes his lock by computing $M=C_3\oplus K_B$.

Meanwhile, Eve intercepts $C_1\text{,}{C}_2\text{,}{C}_3$ and computes

The moral of the story: even the best cryptosystem can be insecure if not used appropriately.

In this chapter, we describe some situations where mistakes were made, leading to security flaws.