Pivoting Caesar Cipher: a toy encryption algorithm

English: Caesar cipher with a shift of 3.

English: Caesar cipher with a shift of 3. (Photo credit: Wikipedia)

As a fun little exercise, I decided I wanted to come up with an encryption algorithm. It’s nothing new, but it was enjoyable as a bit of a time-waster.

In this exercise, I’ve come up with a variation on the classic Caesar cipher (also known as ROT-13), where we shift characters a certain amount in order to mask our cleartext. However, unlike in ROT-13, we’re not going to use a fixed shift value. Instead, we’re going to establish particular characters—pivots—that cause the shift value to change for later characters in the message. The idea for this is that it will make it more difficult for an attacker to read the message, as they’d need to know which characters change the shift value, and how the value changes at each of those characters. There are two different ways we can approach the shift change: either by setting a new shift value outright, or by adjusting the existing shift value by adding or subtracting a value. We’ll go with the latter for this algorithm.

Besides adding pivot points and a changing shift value, let’s also define a range of valid characters that can be used for encryption. Caesar’s cipher was designed with only the basic Latin characters in use at the time, but these days there are more characters in the Latin alphabet, not to mention our use of Indo-Arabic numerals. For our example, we’ll use an “alphabet” of A-Z, 0-9, and the period / full stop for a total of 37 characters: ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789. We could add more characters (additional punctuation, space, accented characters, etc.) but this should be good enough for most uses of such a simple cipher. Not to mention that 37 is a prime number, which may offer us some useful characteristics.

Since we’ve got into the example zone, let’s also set up our pivot points and their adjustment values. We’ll choose the vowels, the digit 0, and the full stop as our pivots, and the first seven primes as the shift adjustment values:

Character Adjustment Character Adjustment















Finally, we’ll choose an initial shift value. Remembering this system’s roots with the Caesar cipher, where we rotate by half the alphabet, we’ll choose 19, rounding to the odd number, coincidentally another prime number and the one that follows our final pivot point!

We want to encrypt the message “The password is swordfish.” First, of course, we’ll make it uppercase since our alphabet doesn’t have any lower case characters. Then we’ll replace the spaces with periods, and the period at the end with two periods so we know it’s the end of the sentence. Our resulting message for encryption is: “THE.PASSWORD.IS.SWORDFISH..

The first character of the message is T with position 20 in the alphabet (remember, it’s indexed from 1, not 0), and our initial shift value is 19. The sum is 39, and as that’s greater than the length of our alphabet, we have to take the modulus, or 2. Therefore, our ciphertext starts with B. The next character, H, becomes: (8 + 19) = 27 = 0. E: (5 + 19) = 24 = X, and since E is one of our pivot points, it’s time to adjust our shift value. We take our current shift, 19, and add the adjustment value 3 – the following characters will be shifted by 22 characters. With the next character being the period, we therefore calculate (37 + 22) mod 37 = 22 = V. And since the period is also a pivot, time to adjust the shift again: (22 + 17) mod 37 = 2.

But what if the shift adjustment for the period was 15? We would have ended up with a shift value of 0, but that would cause us to output cleartext until we encountered another pivot character. Therefore, let’s add the rule that if the shift value ever becomes 0, we reset it back to the initial shift value.

Likewise, we need a rule for when the modulus of the character position and shift against the alphabet length is 0. Whenever we encounter this situation, we’ll wrap back and use the final character of the alphabet, in this case the period.

When we run through the entire algorithm, we get the ciphertext “B0XVRCWW0S2OK.O6591AXZ2G6YE

Now, what about decoding the message? To convert our ciphertext back into something readable, we need to subtract the shift from each character. Given the character B and the initial shift of 19, we calculate (2 – 19) = –17. Wait. A negative number? We know about taking the modulus for positive numbers, but what do we do in this case? Simple: when we have a negative value, add the size of the alphabet. Therefore, we go (-17 + 37) = 20 = T. The next character, 0, has the value 27, so (27 – 19) = 8 = H. Then for X: (24 – 19) = 5 = E. And that’s a pivot point, so we adjust our shift by the adjustment value, giving us (19 + 3) = 22. After that, for V, (22 – 22) = 0? Uh oh, looks like we hit a snag. Let’s do the same thing as we did when creating the ciphertext, and wrap around backwards to the period. And again the shift gets adjusted, (22 + 17) mod 37 = 2.

Continuing through the decryption process, we return to our original cleartext: THE.PASSWORD.IS.SWORDFISH..


Turning ideas into great blog posts

Some old Greek writingDo you ever find yourself starting a blog post and have no idea of what to write? You have a topic you want to write about, but you just can’t get the words out.

I’m going to share with you a useful workflow for going from concept to a great blog post in six steps. By following this flow, you’ll spend less time wondering how to craft your posts, and more time creating content people want to read. Read more »


Recent projects

Some stuff I’ve been working on lately (apart from work projects or games):

I created a new plugin for Media Browser Server, meant to force the creation or updating of local metadata files for items in the media library. This plugin is pretty raw and currently only available as source code on Bitbucket, but it provides the functionality I needed to keep an update of Media Browser from early in the year from blowing up parts of my library. I don’t know if I want to try and get this functionality added to Media Browser itself or just kept as a plugin, but it’s good to have the ability to schedule a recurring task to ensure that metadata files are kept up to date in case the MB devs decide to make more changes to how folders are structured.

I also set up a repository on Bitbucket for one-off tools that I write to help me out here and there. Currently there’s only a single project in the repository, a console-based file system monitor, but I expect that I’ll also be pushing up LINQPad scripts, helpful batch files, MSBuild projects, and other hacks and utilities I put together and don’t want to lose. The tool currently in the repo, DirectoryMonitor, supports watching multiple different paths, and can filter based on filename wildcards (for example, just files matching *.xml in each path). This one might be worthy of expanding more fully, as well.

Finally, I needed to bring back NUnit output support for xUnit.net 2.0 so we could use the latter at work with Bamboo. This was mostly just pulling up an older, 1.9 era file, and updating it, but now we’re able to run xUnit.net tests automatically as part of our CI build process at work. I actually blogged about that on the Northcloud website, detailing the steps needed to get this working by using a trick of how MSBuild prepares and runs Visual Studio solutions. For xUnit.net 2.0 RC4, the NuGet packages for test runners are changing, so I’ll need to update my article some time this week.

There’s a couple things coming down the pipe, as well:

I’ve been on-again off-again writing a blog post for months now, detailing a toy encryption algorithm I put together for fun. Or more correctly, one that I’m still putting together alongside the article. It’s something that I expect that a half-decent cryptologist could crack in a couple of hours with nothing but pencil and paper, but it’s been an interesting learning experience so far.

I’m also writing another blog post for the Northcloud website, about my experiences with software technical design and the SOLID principles. I’m not sure when it’ll be finished, but it should be published by the end of the Month.

Last but not least, I’m starting the tech design for a new version of MoodTracker, built as a Windows universal app. My big problem with this, though, is that universal apps don’t have access to SQLCE, meaning that existing users will not be able to simply upgrade if they want to keep their existing data. This problem is a bit of a pain in the ass, but can probably be solved by releasing an intermediate update for the existing app on Windows Phone 8.x to migrate the database to SQLite, and then release the actual MoodTracker 2.0 some time later so that most or all users don’t suffer any data loss.

One last thing: I just found out about a great little package from Microsoft that pools MemoryStreams. This’ll certainly help me out with one of my current work projects, since it uses a lot of memory streams with different lifetimes. Microsoft.IO.RecyclableMemoryStream is definitely going to be put to use here.


An alternate US-International keyboard layout

The default US-International keyboard layout for Windows isn’t exactly my cup of tea. Primarily there are issues, in my mind, with regard to composing keys, but in addition to that there are other characters I’d like to have available in a US-International layout. I put together this particular layout a few years ago, but it’s mostly just languished, occasionally shared with friends or other developers through email or sometimes Dropbox.

Anyway, I’ve done a rebuild, and provided the layout as an installer package or 7-Zip archive for anyone interested. The keyboard layout source file is now also available on BitBucket, in case anyone wants to make their own further changes.

Read more »


Using TinyIoC with Common Service Locator

For a recent project at work, I had the opportunity to use TinyIoC, a single-file IoC container implementation, for a command line program used for quality assurance testing of images. The QA testing itself was in a separate assembly, written for an earlier, WPF application that used MvvmLight and SimpleIoC. The thing is, the assembly which actually did the work was written with service location and dependency injection in mind. I didn’t want to have to add MvvmLight to the command line app just to get SimpleIoC, so I added TinyIoC via NuGet instead, in hopes that I could just use that.

The thing is, that work assembly was relying on Common Service Locator (i.e. Microsoft.Practices.ServiceLocation) to get services both from itself and provided by the assemblies that used it. And TinyIoC doesn’t come with an adapter for Common Service Locator. Fortunately, writing up an adapter isn’t that difficult; you merely need to supply a class implementing IServiceLocator and have that class map the interface’s calls to methods on your container. The following Gist provides an adapter implementation for TinyIoC:

There’s not much else to it but this. Of course, to actually put it to use, you’ll need some code to let CSL know to use TinyIoCServiceLocator – and, of course, register your services with the container:

Voila, TinyIoC and Common Service Locator, hand in hand for your next application.