Sometimes you start up a project that you truly have a passion for. A project that's constantly on your mind and that you'd give anything to have done. Timeshift is that project for me. It's eaten 5 years of my time and is definitely my flagship project. It's my Mona Lisa and my Sistine Chapel in one project. It's elegant code is as powerful as it is fast and efficient. I've never learned so much from a single project.
In about 2005, I created a chat room dedicated to developers and free for anybody to enter. Give or take about 20 minutes after I started this room, Karl came into the room and we began talking about things we'd do to practice programming and stay sharp. We both admitted to some very amateur dealings in cryptology. Ah, I remember my first encryption program... It was horrible. My first breakthrough in cryptology was simply that we could convert chars to bytes and just do basic math on the bytes. If you couldn't already tell, I entered into the world of cryptography very early in my programming career (My first 2 or 3 crypto-apps were in VB6). Anyway, Karl and I begin throwing ideas back and forth. He'd create a little app and he'd send me the project. I'd look it over and see what goodies he was incorporating. If I found something that seemed a little fishy or made it really easy to guess the password, I'd point it out to him and usually build an app that expressed a way to fix it. We'd go back and forth of presenting ideas to each other and pointing out flaws the other had perhaps not considered, constructive criticism of course.
About two years of randomly chatting about development and exchanging crypto ideas, it finally hit us to work together on one. We pondered and tested things over the next year or so before we began down the trail we're on now. Several times, we started from scratch or made changes so big we might as well have started over, but it worked out in the end. Our very first "stable" build was a two part system seamlessly integrated as one. The algorithm had a truly simple implementation for anybody needing to use it, simply pass in a variable length byte array for the data to encrypt, and pass in a variable length byte array to represent the key. There's no prerequisites about either one of those variables. There is no "must be at least X bytes long" or "must be divisible by X" or any other kind of rule on the data. It just works. The key was passed to Pandora 4, written almost primarily by Karl, and internally it created a 512 bit (64 byte) section of memory that is used in the internal state for the rest of the encryption. We had some small tweaks go on after that, but I'm not here to explain every detail to this project (sorry, no source code either). We knew we were a 512 bit encryption (because of the size of the internal state) but we wanted to make sure it was a fast process as well. So we ran some speed tests encrypting 100 MB of data and testing how long it'd take. Some of our first runs timed out at over one minute; we knew something had to be done about this. Each week for about two months, we tweaked and modified something to really bring down the time it took. When we broke the 10 second barrier, I could barely believe it. I ran the test several more times and had Karl reproduce the results on his computer. It was a glorious day, and yet only the first of many.
We worked hard to get to this point. I learned so many things about compilers and optimization over those two months, and any normal partnership would have taken some time to relish in the new state of their project. Not us. We began looking at the size of the internal state. 512 bits seemed a bit small, so we looked into the biggest we could make it. First we agreed on 1024 bits, and we joked about possibly jumping to 2048, and even the wild concept of a 4096 bit internal state. We laughed and scoffed, but the gears were turning and not two minutes after we stopped laughing were we upgrading it to have an internal state of 4096 bits. In awe we ran our first speed test to find that a eight-fold increase in the internal state only increased our time by a few tenths of a second. Along with the increase in bits for the internal state, a new, larger version of Pandora needed to be developed:
Ten seconds was leaps and bounds better than our first speed tests, but it was hardly enough. We set goals to be faster, how much faster we never really specified, just faster. We chipped time off here and there, tenths of seconds, milliseconds, no decrease in time was too small but all of our changes had to be sure not to degrade the strength in the encryption (the voodoo and black magic that I won't get into here). We experimented with loop structures, compared modulus to logical ANDs, tested the speed of unsafe code you name it and we probably looked into it. We did everything except move it to lower level languages (which we plan to do when we hammer out 100% of the details). About the time we reached 5 or 6 seconds, I was beginning to realize that we might actually have something on our hands. We were developing a 4096 bit encryption at speeds that 256 or 512 bit encryptions could only dream of. Months go by, as we nickel and dime our way to a faster cipher, then I receive a very excited email from Karl... 100 MB in 674 milliseconds. That's 148.3 MB\s (and these are legit Mega Bytes, not Mega Bits)! I was literally speechless. In an instant, I remembered how slow our first run was, over a minute, and how now the same thing was moving 60+ times faster. It's still a surreal feeling when I think about it, and this very moment chills are shooting down my spine. Since that day we've added minor changes for security that have increased the time, but we've successfully kept it at over 100 MB\s, currently it's around 112 MB\s, but the security changes we're adding are more than worth it.
More recently, we've been looking into a top secret feature that I'm not at liberty to discuss in detail here, the main reason being that we discovered it. That's right, brand spanking new and nobody's ever heard of it or used it. The problem is that we can't explain WHY it happens, we only know a handful of parameters for WHEN it'll happen, none of those parameters work on the size of our internal state. We're working on the details and when we are done explaining this, it'll be time to go to market. All I will say is that it's a fundamental change to what we know about a particular basic logical construct.