Cal Tipton

ENCREBOOT

Introduction

ENCREBOOT is technically one of my longest-running projects ever. Its initial conception happened when I was in tenth grade, and I've been incrementally improving it since. Now, the more astute among you may be wondering what the hell an ENCREBOOT is, so let's start there. "ENCREBOOT" is a combination of the words "The ENCRYPTOR" and "reboot," and it's just a program that encrypts text files. In the beginning, it was meant to be a more original and secure version of The ENCRYPTOR, which is one of my first ever Python programs. I say "more original" because The ENCRYPTOR was essentially just ripped from a book named The Big Book of Small Python Projects written by Al Sweigart. This book was one of my favorite resources when it came to first learning Python. Anyway, I knew even then that The ENCRYPTOR was not something I came up with, and therefore not something I could be proud of, so I set out to create something even better.

Algorithm

The ENCRYPTOR used a simple ROT-13 cipher, which I found less than impressive. Before I wrote any code, I spent countless hours in study hall, in boring classes, and even at home agonizing over a more secure way to encrypt text. Finally, I was able to throw together a method that satisfied my sixteen-year-old desires for security. Later in life, I was devastated to learn that I just "re-invented" a modified version of the Vigenère cipher. But, we have no reason to despair about that right now, so let's continue!

The basic concept of ENCREBOOT's encryption algorithm is (thankfully) pretty simple. To encrypt or decrypt a message with ENCREBOOT, the user needs three things: the text that will be encrypted/decrypted, the relevant key/passcode, and a "charts file" (we're going to ignore young me's questionable naming conventions for the duration of this article). I'm already sick of typing "encrypt or decrypt," so for the purposes of this explanation, just assume that the encryption and decryption processes are nearly identical, so if I say something about one, it applies to the other.

The first step of the encryption process is converting both the message and the key from characters (something you'd type on a keyboard) to numbers. For this, a programmer would typically use an ASCII table, which is a standardized way to do exactly what we need. It maps numbers to most standardized characters on an English keyboard. So, the table would look at a character ("A" for example) and convert it to whatever number the table says (for "A", the number is 65). However, at the time of devising this algorithm, I didn't actually know what the ASCII table was, so I accidentally turned this into a feature. The aptly- named "charts file" is what takes the place of the ASCII table. Each charts file contains every acceptable character, and the character's position in the file is used as the number. So, if the character was "A", and "A" was the third thing in the charts file, the character would be converted to 3. I call this a feature because it technically adds more layers of security. To decrypt a message, a user (or hacker) needs both the key and charts file, instead of just a key. Obviously, the charts files can be easily swapped out when using the program.

At this point, both the message and key are strings (ordered collections) of numbers. This next step is the only one where encryption and decryption differ. The numbers of the key are added to (encryption) or subtracted from (decryption) the numbers of the message. So, if the first number of the message is 15, and the first number of the key is 24, the resulting number in the message is 39 (if decrypting, the number would be -9). If the message is longer than the key (it usually is), then the key will just repeat from the first position. For the next (and final) step to correctly work, the resulting number needs to be between 1 and the max number of characters in the charts file. So, as long as the charts file has 39 or more characters, 39 is fine. Obviously, regardless of the length of the charts file, -9 is not a valid number, because it is less than 1. This leads to the quesion, how do we turn invalid numbers into valid numbers?

If a number is too big, the number of characters in the charts file is subtracted from it. So, if the length of the charts file is 26, 39 would be converted to 13. If the number is too small, the length of the charts file is added. So, assuming the charts file still has 26 characters, -9 would be converted to 17.

Now, the numbers representing the message have been changed according to the key. For the final step, the modified numbers of the message are converted back into characters using the charts file. Since we already assured that all of the numbers are valid in the last step, this is trivial. The number is converted into whatever character is in the position of the number in the charts file. So, 13 is converted to whatever character is in the 13th position of the charts file.

To sum all of it up, the message is converted into numbers using the charts file, the numbers are changed according to the key, and then the numbers are converted back into characters using the charts file again. For those of you who know the Vigenère cipher, you'll likely be able to see the similarities.

Backstory

The initial draft of this program was written in Python and cripplingly unoptimized. It was more than fast enough for basic text files that were a few hundred lines long, but once I started to test it using entire classic books (huge shoutout to Project Gutenberg), the lackluster speed became apparent.

Fast forward a few years, and it's time for me to learn the C programming language. As practice, I rewrote ENCREBOOT entirely in C. Obviously, rewriting the code in C itself was transformative in terms of performance, but I was still using the same basic, crippling, unoptimized methods. In light of this, for the final, most recent version, I implemented numerous improvements to the code to fix memory leaks, improve general accuracy/stability, and, most importantly, increase speed dramatically. You can check my GitHub for more details on the specific optimizations if you're really curious (currently, it's named "Creboot").

References

Here are links to a few of the things I referenced above! https://inventwithpython.com/bigbookpython/project61.html https://www.gutenberg.org/ https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher https://github.com/SteppinKurry?tab=repositories