Friday, July 25, 2008

On the security of passed notes in a 8th grade classroom...

This entry into my blog is a letter of advice to all of you school children who are out there passing notes, hoping to keep your messages secret from other students, teachers, and administrators. To tell you the truth, I have no idea of you kids these days are still passing notes, but I choose to believe that you do, that it isn't all SMS traffic these days. Much like I choose to assume that all kids today aren't taking MDMA like it was M&M's and/or packing a 9... But, given that I've recently learned that all kids do apparently go through a dinosaur phase, I feel that there is hope for the world.

But this isn't about parenting and the resulting paranoias and self deceptions, it is about maintaining traffic security.

Kids, your channels are wide open to interception. You've all seen the teacher intercept the passed note, read the contents aloud, and shame those involved into humiliation. That's just not cool. No one knows that you saw Joey around behind the library kissing Jenny or whatever is in those notes (that do actually seem to be a predominantly female concern). Least of all Joey or Jenny or the members of your intelligence network. So start to put some kind of protective encipherment across these things.

You might be using a simple monoalphabetic substitution -- and that will prevent the causal reader from understanding the message at a glance. Shifting all the letters one, two, or thirteen to the right might buy you what the intelligence guys call operational security -- that is enough time to complete your mission (let us say sneaking around behind the library to kiss that good-for-nothing but hunky Joey), but it won't save the message from eventual decryption and your actions from exposure (possibly at the worst possible moment -- mid smooch!). So if you're going to use a monoalphabetic, at least use yourself a random alphabet, even if it does increase the workload at encryption and decryption time. Security is not for the lazy or hurried!

Far better would be to pull out a polyalphabetic -- a code that uses several different alphabets to arrange the substitution between the plain text and the cipher text. These can actually be pretty easy to set up based around an easy-to-remember code word, and therefore simpler to implement operationally in that no-evidence world of the deep cover agent or middle school student. Pick a keyword that everyone knows and agrees to. Ideally it is random and meaningless, but let's make it easy and fun and choose the school mascot's name. My high-school was the Blue Devils. That'll do nicely. It provides us with a sequence of ten different (well, actually eight different) alphabets that we use. For the first one, the letter A in the plaintext would be enciphered as a B and any other letters would use the same shift of 1. For the next letter in your plaintext, the letter A would encipher as an L, a B as an M, a C as an N and so on -- based around the original shift. For the third letter, A would encipher as U...and if you are referring back to they codeword, you probably have the method figured out.

This vastly increases complexity, because if the message is sufficiently short and the key period (the time until you wrap around and start reusing the same sequence of alphabets -- ten characters in this case) is unknown, the cryptologist has a much more challenging job of applying the sort of statistical analysis that can blow a straight monoalphabetic wide open. But here we run into one of the unfortunate errors made by amateur and hobbyist cryptographers -- that of assuming that each message will face an enemy's scrutiny in isolation. The reality is that a cipher system is rarely, if ever, practically used on a single message. Instead it is used for days, weeks, or even years to protect a whole series of messages. The longer the system and the key is in force, the greater the volume of traffic likely to be intercepted and the greater the quantity of raw material the analyst can work with. And, remember, that once a key is blown based on bad practice with a single message or amassed traffic, all the traffic protected by that key is compromised. No good.

So change your keys often -- perhaps every week. Or every day. And use keys that are hard for the analyst to guess. No boy bands, teen idols, or school mascots.

Here is another good tip -- use a superenciphered code rather than a straight cipher. Cryptanalysis depends very strongly on probability and good guesswork -- guessing the nature of the message you are trying to break. If you know that the message contains a certain word in a certain location, you can figure out what the alphabetic substitution was at that point and possibly get a break that will spread further or to other messages. So let's suppose you have a science teacher named Mr. Polymer who is sadly encumbered with extremely protuberant eyes. If you send a message in his class, there is a fair chance it would contain the word POLYMER, thereby giving your foe a clue. Instead, make up some codeword that stands in for his true name. Don't make it MR BUGEYES or anything else that is obvious. Make it BLUE SHARK or even better yet something completely random like GRLXX or LYUOG. Do this for all frequently used or distinctive names and locations. For very frequently used ones, have several code names that you switch between at random, so that hunk Joey might be known as LNEMQ, POVON, and WEUBC depending.

Much improved -- but with a warning. If you are in a hurry -- never partially protect a message. If you have to pass a note and don't have time during the geometry quiz to fully encipher it, don't use the codewords at all. This merely risks their compromise if the message is intercepted. TELL WEUBC TO MEET ME BEHIND THE YRPED DURING NRFFO TO QAGOT is really just asking to have the codes for Joey, library, lunch, and presumably "make out" compromised -- not just for this message but for all messages. Thing strategically and don't put the network at risk out of a desire to protect one message.

In general, don't put any easily guessed information into your message. It might seem surprising, but the headers that contain message address information should never be enciphered. They should be sent either in clear text or using another cipher or code of some sort. It might seem like a huge risk to your security, but predictable information like names and addresses should never be put in the body of an encrypted message. Again, don't risk the entire message or channel out of a desire to protect one part of it. Most military ciphers of the golden age used separate codewords or encipherment tables to secure the beginning and end of the message.

While you're at it -- see if there is something you can do to vary the cipher key used slightly. This is another component of most military grade ciphers. There is a weekly or daily key that is common for all folks on a channel. But there is another part of the coding system that is varied from message to message -- a indicator as it is usually known. We might choose to slightly vary the shift in our polyalphabetic or add a transposition (think word scramble) component to our cipher that is controlled by this indicator group. The indicator group is sent in the clear somewhere in the message or its header information. We might apply some transformation to the indicator before using it in our keying process, but we always send it in the clear.

I know -- its starting to get kind of hectic by now. But remember that the risk of compromising your intelligence and actions never allows for shortcuts. For the moment, I leave you with a relatively effective polyalphabetic and some good instructions about how to ensure that it is implemented in an effective system. Be careful, keep the notes short, and don't get caught with Joey! More sophistication, and more protection, are coming...

No comments: