Off Topic Post: Xcrypt
This post is going to be a little off-topic, as it's about the encryption software, Xcrypt, I wrote a few months ago. I've been spending a lot of time on it, so I felt it deserved some time here since, while this blog is dedicated to my time at AdAdapted, it's also, in a way, dedicated to my technological ventures. So, story time!
This story starts with a cruel twist of irony. Once I finished Xcrypt, I was excited. I wanted to use it all the time. "I can secure all the source code on my flash drive!" Naïve-Me said. So, Naïve-Me went ahead with encrypting the source code of the projects he had on his flash drive and, of course, overwriting the originals.
It was beautiful at first. I felt secure. "Surely," Naïve-Me said, "if I lose my flash drive, my source will be secure." But there was a problem with Xcrypt. Not with the code, certainly. I spent countless hours ironing out any bugs. No, the problem was with the design. It was needlessly complex. In an attempt to give the user ample control over their encryptions, I gave them several options when encrypting a file. First, the encryption key. Encryption keys could be randomly generated by Xcrypt, you could make your own, or you could tweak an existing one. When starting an encryption, you specified which key to use. Then, you chose a case-sensitive password. After that, you chose an encryption strength. If you got a single one of these things wrong in the decryption process, the "decrypted" result was a garbled mess of misplaced bytes, just as the encrypted version was.
So, you see, the problem was that, when trying to go back to Xcrypt to improve a few things, I attempted to open the source code from my flash drive because I no longer had a copy on my desktop. What I discovered, though, was that I had encrypted it and, worst of all, I had not only forgotten the password, but I couldn't remember what key I used nor the strength. You could say I was royally screwed.
But I love Xcrypt. It's one of my babies. I couldn't let it just die like that, especially when I had so many ideas on how to make it better. So, I recently started recoding Xcrypt from the ground up.
The new version will feature such beautiful things as a changed appearance (the messages you receive throughout Xcrypt are more managed, and organized AND you can change the color of the text. WHO DOESN'T WANT TO PUT XCRYPT IN BRIGHT GREEN TO LOOK LIKE A MEGA-HACKER?!), new options for changing Xcrypt's settings (directly edit an XML file! (the old interface for changing settings will remain for users who don't trust themselves with XML)), and, most important of all, MAJOR improvements to the encryption/decryption process. First of all, the user experience is vastly simplified. After typing in the command to encrypt a file, the user will now be greeted with a file explorer window instead of a prompt asking for a perfectly-typed path to the file. From the file explorer, you can choose as many files as you'd like to encrypt at once, all by just pointing and clicking. Glorious! After you choose a file, you'll type in the password you want to use and then Xcrypt will get right to encrypting. Screw encryption keys and strengths! Well, not entirely. Encryption keys still exist, but they're all done behind the scenes in such a way that make things much more secure, reliable, and user-friendly. You no longer need to remember which key you used, and you no longer have to make sure you hang on to the text file containing the key you use all the time. You no longer have to fear for the posterity of your files if you (gasp!) lose the encryption key altogether (a problem that, in the old Xcrypt, meant that the file was totally un-decrypt-able). All you need to remember now is the password! As for strengths, there's one strength used across the board.
"But Josh," you say in a huff. "I can't choose my strength anymore? But Xcrypt was so slow on large files regardless of my processor's 473289478932 cores and super-aerospace-dynamic-hyperthreading technology!" To that, I say: parallel processing, baby. With the power of the .NET framework, I have implemented parallel processing into Xcrypt. Don't know what that means? That means that Xcrypt will now be able to use the full power of your CPU (if you want. If not, you can specify a CPU usage percent that Xcrypt will limit itself to). What else is magical is that this phenomenal technique isn't limited to the encryption process of one file, but to groups as well. Selected 100 files for Xcrypt to encrypt? Watch as your processor tackles several files and their respective encryptions simultaneously, boosting the speed of Xcrypt immensely.
Streamlined, incredibly more efficient, and totally way cooler. Meet: Xcrypt 2.0.
This story starts with a cruel twist of irony. Once I finished Xcrypt, I was excited. I wanted to use it all the time. "I can secure all the source code on my flash drive!" Naïve-Me said. So, Naïve-Me went ahead with encrypting the source code of the projects he had on his flash drive and, of course, overwriting the originals.
It was beautiful at first. I felt secure. "Surely," Naïve-Me said, "if I lose my flash drive, my source will be secure." But there was a problem with Xcrypt. Not with the code, certainly. I spent countless hours ironing out any bugs. No, the problem was with the design. It was needlessly complex. In an attempt to give the user ample control over their encryptions, I gave them several options when encrypting a file. First, the encryption key. Encryption keys could be randomly generated by Xcrypt, you could make your own, or you could tweak an existing one. When starting an encryption, you specified which key to use. Then, you chose a case-sensitive password. After that, you chose an encryption strength. If you got a single one of these things wrong in the decryption process, the "decrypted" result was a garbled mess of misplaced bytes, just as the encrypted version was.
So, you see, the problem was that, when trying to go back to Xcrypt to improve a few things, I attempted to open the source code from my flash drive because I no longer had a copy on my desktop. What I discovered, though, was that I had encrypted it and, worst of all, I had not only forgotten the password, but I couldn't remember what key I used nor the strength. You could say I was royally screwed.
But I love Xcrypt. It's one of my babies. I couldn't let it just die like that, especially when I had so many ideas on how to make it better. So, I recently started recoding Xcrypt from the ground up.
The new version will feature such beautiful things as a changed appearance (the messages you receive throughout Xcrypt are more managed, and organized AND you can change the color of the text. WHO DOESN'T WANT TO PUT XCRYPT IN BRIGHT GREEN TO LOOK LIKE A MEGA-HACKER?!), new options for changing Xcrypt's settings (directly edit an XML file! (the old interface for changing settings will remain for users who don't trust themselves with XML)), and, most important of all, MAJOR improvements to the encryption/decryption process. First of all, the user experience is vastly simplified. After typing in the command to encrypt a file, the user will now be greeted with a file explorer window instead of a prompt asking for a perfectly-typed path to the file. From the file explorer, you can choose as many files as you'd like to encrypt at once, all by just pointing and clicking. Glorious! After you choose a file, you'll type in the password you want to use and then Xcrypt will get right to encrypting. Screw encryption keys and strengths! Well, not entirely. Encryption keys still exist, but they're all done behind the scenes in such a way that make things much more secure, reliable, and user-friendly. You no longer need to remember which key you used, and you no longer have to make sure you hang on to the text file containing the key you use all the time. You no longer have to fear for the posterity of your files if you (gasp!) lose the encryption key altogether (a problem that, in the old Xcrypt, meant that the file was totally un-decrypt-able). All you need to remember now is the password! As for strengths, there's one strength used across the board.
"But Josh," you say in a huff. "I can't choose my strength anymore? But Xcrypt was so slow on large files regardless of my processor's 473289478932 cores and super-aerospace-dynamic-hyperthreading technology!" To that, I say: parallel processing, baby. With the power of the .NET framework, I have implemented parallel processing into Xcrypt. Don't know what that means? That means that Xcrypt will now be able to use the full power of your CPU (if you want. If not, you can specify a CPU usage percent that Xcrypt will limit itself to). What else is magical is that this phenomenal technique isn't limited to the encryption process of one file, but to groups as well. Selected 100 files for Xcrypt to encrypt? Watch as your processor tackles several files and their respective encryptions simultaneously, boosting the speed of Xcrypt immensely.
Streamlined, incredibly more efficient, and totally way cooler. Meet: Xcrypt 2.0.
Comments
Post a Comment