The Need for Secure Communication
For more than three millennia, humans have sought ways to protect and secure information so that it is only available to a limited set of select individuals. Whether they were ancient military leaders seeking to keep their battle plans out of enemy hands or modern-day financial investors trading stocks online, there is an unlimited number of scenarios in which access to information needs to be restricted.
One way to ensure that information is not accessible to others is to completely destroy the information. Imagine writing a private message down on a sheet of paper and then shredding the page into a million tiny pieces. The information contained within the original message will be all but lost, ensuring that no bystander might piece it all back together again. Unfortunately, it also means that you will also not be able to reconstruct your data, rendering this an undesirable solution to the problem.
Instead, the real problem is to obscure the data, rather than destroy it. If only there were a way to scramble the information in some way that renders it unreadable to anyone who does not know how to unscramble it. This is the ultimate goal of cryptology, the study of securing (or encrypting) information such that it is inaccessible by third parties.
Alice, Bob, and Eve
The classic example that is often used to demonstrate and explain the problem of encryption is the case of Alice, Bob, and Eve. In this scenario, Alice (A) wishes to send a message to Bob (B), but she and Bob are unable to meet in person to exchange information directly. Instead, all communications between Alice and Bob must go through a third-party messenger, Eve. Unfortunately, Eve (as in eavesdropper) is potentially untrustworthy and might read any messages she is asked to deliver.
This hypothetical scenario is a stylized version of what happens every time you make a private phone call, access a web page, or send an email or text message. You, like Alice, are reliant upon the computers, routers, online services, and other parts of the network infrastructure to deliver the data of your message to your intended recipient. Unfortunately, like with Eve, you have no oversight of these components and cannot guarantee that an interested third party is not accessing the private data that you are transmitting.
One of the earliest and simplest attempts at encryption is the Caesar cipher, employed by Julius Caesar in the 1st century BC. This schema is known as a substitution cipher because it substitutes each letter of the original, unencrypted message (called the plaintext) with a corresponding letter in the final, encrypted message (called the ciphertext).
The Caesar cipher works by aligning two alphabets against one another and offsetting them by a number of positions. Caesar himself used a “left rotation” of three spaces, causing an
a of the plaintext to align with an
x in the ciphertext.
Plaintext: abcdefghijklmnopqrstuvwxyz Ciphertext: xyzabcdefghijklmnopqrstuvw
Try playing around with an interactive demo of the Caesar cipher to see how messages can be encrypted and decrypted.
For example, if you enter a plaintext message of
this is a caesar cipher and set the offset to be 23 (left shift of 3), then clicking on “Encipher Plaintext,” will produce the following ciphertext:
Plaintext: this is a caesar cipher Ciphertext: QEFP FP X ZXBPXO ZFMEBO
Similarly, entering a ciphertext of
GUVF VF QRPELCGRQ and an offset of 13 will produce the following plaintext:
Ciphertext: GUVF VF QRPELCGRQ Plaintext: this is decrypted
See if you can decipher these messages. Note that you might need to try a number of different offsets to find the right key to decrypt the message back into an intelligible plaintext.
PGGTFU CZ POF DRO YPPCOD SC DOX JC IJ TJP CVQZ YDNXJQZMZY HT NZXMZO LUJYFWAPVU PZ MBU MVKZGXBQWV QA ABQTT NCV
Notice how in order to decrypt each of these messages, you must know three things:
- The ciphertext message
- The method of encryption used to create the ciphertext (e.g., a Caesar cipher)
- The number of positions by which the plaintext and ciphertext alphabets have been offset
The last of these items, the offset, serves as the key that effectively locks and unlocks the message. Using the key to encrypt the message into a ciphertext secures the message and protects it from prying eyes, much like locking the message in a box or safe. Likewise, you use the key to properly align the alphabets and unlock the message in order to read the original plaintext.
In the earlier scenario, as long as Bob knows which key Alice used to encrypt her message, he can use the same key to decrypt the message once he receives it. However, without being told which key was used, Eve cannot decrypt the message as easily as either Bob or Alice.
Obviously, as you have previously seen for yourself, a Caesar cipher’s key can be easily deduced through simple trial and error. After all, there are only 25 possible keys and it is easy to try each one through brute force.
Today, modern encryption schemes are far more sophisticated than those used in Julius Caesar’s day and they use far more complex keys that are much harder to guess through brute force techniques. But the model used more than 2000 years ago is still more or less the one we use today.
- A sender (Alice) uses an encryption scheme and a key to encode a message.
- The encoded message is transmitted through one or more intermediate and potentially untrustworthy handlers (Eve).
- The recipient, who knows which encryption scheme was used and is already in possession of the necessary key unencrypts the message back into its original, plaintext form.
The only difference between the ancient Roman times and now is that computational processing power has made Eve’s job much easier and the need for stronger encryption algorithms and keys much greater.
Using the Caesar cipher simulator, create five new ciphertexts of your own and exchange them with a partner. See who can decrypt the other’s five messages first.
Consider designing a more sophisticated algorithm that would be more secure than the Caesar cipher. What sequence of steps could you perform to securely encode your message that would make it harder for an “Eve” to crack your code?