The reason the Ceasar substitution cipher is easy to break is that the keyspace is tiny.
You can easily try all 26 possible offset values and see which produces recognizable text.
But what if every character had its own offset? For example, the first letter might have
offset 2, the second 12, the third 7, etc.
To make it easier to write, the offset values are usually represented by letters.
The offset 0 coresponds to the letter A, 1 corresponds to B, etc. So the offsets 1, 11, 6
would correspond to the key value B, L, G. The combination
of all the offset letters forms the key or onetime pad.
You can combine a plaintext character P and a key character K to give a ciphertext character C
like this:
C = (P + K) Mod 26
In Visual Basic this looks like:
C = Chr$((Asc(P)  Asc("A") + Asc(K)  Asc("A")) Mod 26 + Asc("A"))
To recover the plaintext, you subtract the key from the ciphertext like this:
P = (C  K) Mod 26
In Visual Basic this looks like:
P = Chr$((Asc(C)  Asc("A")  (Asc(K)  Asc("A")) + 26) Mod 26 + Asc("A"))
The Mod operator does not ensure that its result is nonnegative.
For example, 3 Mod 10 is 3 not 7 as you would like.
To avoid getting negative character numbers, this code adds 26 to the result of the subtraction
before using Mod.
You combine the plaintext with the keys one
character at a time to produce the ciphertext.
Plaintext: APE
Keys: BLG
Ciphertext: BAK
There are 26 possible offsets for
the first character, 26 for the second, and so forth. If there are N letters in the message,
the number of possible combinations of offset values would be 26 ^ N (26 to the Nth power).
This is a huge number. If N is only 10, there are 141,167,095,653,376 possible key combinations.
For larger messages, you couldn't possibly try all the possible key combinations.
Even worse, you could not know when you have found the right key. The 26 possible offset values
for a letter map that letter into every possible ciphertext character. Or if you think about it
backwards, the 26 offsets can map a ciphertext letter back to any plaintext character.
When you take the message as a whole, there is some combination of offset values that will
map the ciphertext back to any possible plaintext value.
For example, suppose the ciphertext is HAC. Now suppose you guess the key is HLY.
Then the plaintext is APE which seems like a valid message.
Plaintext: APE
Keys: HLY
Ciphertext: HAC
Now suppose instead you guess the key is FAL.
Then the plaintext is CAR which also seems like a valid message.
Plaintext: CAR
Keys: FAL
Ciphertext: HAC
For any ciphertext and any plaintext, you can find a key value that maps the plaintext to the ciphertext.
This is very important. It means a onetime pad is perfectly secure. Noone can recover the plaintext
from just the ciphertext.
This also means you could have two sets of keys that map back to different plaintext messages.
You would use one to decode the message correctly. You could give the other to the bad guys
if they grab you and torture you for your secrets. The bogus key would decode the message to something
seemingly meaningful. The attacker would not know the real message and would have no way of telling.
There is one catch to onetime pads: you can use onetime pad to encode only one message.
If you use a pad more than once, then the series of messages you encode using it become a
very large message encoded with a repeating key word. You'll see in a later that this system
is not secure.
Back to top
 Write a program that has three TextBoxes for plaintext, a onetime pad, and ciphertext.
After entering plaintext and a onetime pad, the user should be able to click a button
to generate the ciphertext. Similarly after entering a onetime pad and ciphertext, the
user should be able to click another button to recover the plaintext. The program should
reformat the text so it contains all capital letters in groups of five characters each.
Solution.
 If you were going to use this system in real life, you would need to send the onetime pad
to the person you will later want to send the message. In practice, you would probably want
to copy the pad onto a floppy disk and give that person a copy (keeping one for yourself).
Actually this can be hard.
Imagine trying to sneak a code book behind enemy lines. Or imagine your bank sending
all of its customers a different onetime pad by bonded courier so noone could tamper with the mail.
This is actually why onetime pads are not used all the time. While they are perfectly secure,
getting the onetime pad to the person who will receive the message is hard.
Modify the previous program so the user can load and save the plaintext, onetime pad, and ciphertext
in text files with extensions .txt, .pad, and .cip.
 Modify the program again so it has an option to use Visual Basic's Rnd statement to generate
a pseudorandom onetime pad. Be sure to use Randomize to initialize the random number
generator. (You'll see in a later tutorial why this method is not secure.)
Back to top
Back to main cryptography tutorial
