The XOR cipher is a simple cipher that can be employed using binary numbers and the XOR operator. Much like the tabula recta studied in an earlier chapter, you'll see that while the encipher and decipher protocols are simple, the key generation provides the real security of the message.
Below, we'll see some examples of how we can use this binary cipher with English language messages.
A straight forward implementation would be to choose a Base64 plaintext and key, convert both the key and the message to binary and then encipher each letter of the message with the same key, just like the Caesar cipher. However, unlike the Caesar cipher, instead of regular integer addition, the encipher process will use bitwise addition, or the XOR operation, on each individual bit of the message. When using Base64 characters, there are many more options for the key than we've previously been able to use. Since there are 64 characters in the "alphabet" we can use integers between 0 and 63.
decimal key: 37 binary key: 100101 Base64 plaintext: Obi Wan binary plaintext: 001110 011011 100010 010110 011010 100111
To encipher a message, XOR the key with each binary number in the plaintext stream. To organize this process, it's easiest to write the binary key under the binary representation of each letter, similar to what you've done with tabula recta based ciphers.
binary plaintext: 001110 011011 100010 010110 011010 100111 keystream: 100101 100101 100101 100101 100101 100101 binary ciphertext: 101011 111110 000111 110011 111111 000010
To make the text readable again, we can look up the 6-bit binary groups back to a Base64 character.
binary ciphertext: 101011 111110 000111 110011 111111 000010 Base64 ciphertext: r+Hz/C
So the message
Obi Wan becomes
r+Hz/C using a binary Caesar cipher with key of
37. One thing that's different about using bitwise addition is that we don't ever need to MOD 26 (or in this case MOD 64) after the addition. That's because the bitwise sum of any two 6-bit binary numbers is another 6-bit binary number. Since every 6-bit number has an associated character in Base64, it's guaranteed that after enciphering each 6-bit block of binary will be 'valid' in that you can convert it back to a symbol.
Much like with the Caesar, we can reuse an old cipher with this new binary number system. Choosing a Base64 keyword and plaintext message, you can convert both to binary, repeat the binary keyword as much as needed to "cover" the plaintext, perform bitwise addition with the bitstreams, and finally convert the binary result back to Base64.
Base64 keyword: EGG binary keyword: 000100 000110 000110 Base64 plaintext: Breakfast binary plaintext: 000001 101011 011110 011010 100100 011111 011010 101100 101101 keyword bitstream: 000100 000110 000110 000100 000110 000110 000100 000110 000110 plaintext bitstream: 000001 101011 011110 011010 100100 011111 011010 101100 101101 ciphertext bitstream: 000101 101101 011000 011110 100010 011001 011110 101010 101011 base64 ciphertext: FtYeiZeqr
Even though these messages use an extended alphabet of 64 characters and bitwise addition, they have the same exact security flaws of the original versions due to the way the keys are used. Frequency analysis would ultimately reveal enough information about the message and keys to make it decipherable without originally knowing the keys. What's needed is a way to generate a random bitsream to use as the key. However, it was truly random then it would be very difficult to ensure that both the sender and receiver were using the same key. What's really needed is a pseudo-random (or close enough to random) stream of 1's and 0's that both sender and receiver could generate independent of each other and obtain the same result. If such a stream were to be created, the pseudo-randomness would provide a much higher level of security than choose a single keyletter or even a keyword would be able to.