Alright Joe, here’s the part you’ve been waiting for. We’re going to touch on how to overcome that shortage of secure comms. First up I’m going to state my honest opinion on having non-regulars and untrained folks encrypting and decrypting messages. Unless it’s simple and idiot proof I’m not a huge fan of it. I would rather folks use sneakernet to pass messages but if time/space isn’t in your favor then it may very well be worth sitting some folks down and conducting a “train the trainer” session to get whatever techniques or technology you use spread amongst the tribe. For our purposes we’ll refer to our code as a “Cipher”.
Message encryption is ancient – literally. Ceaser used a basic encryption to encode his personal messages (Google Ceaser Cipher). There’s literally hundreds if not thousands of ways to encrypt. Book Encryption, drop code, etc. etc. Understand this right now: A cipher is only as good as the folks using it and how secure they keep it.
Joe Commented “Regarding crypto. Prepare a code manual. Five-letter meaningless groups. These are assigned arbitrary meanings. You need the code book to encode and decode messages. The code groups can be spelled out phonetically. Numbers will also work, and may be easier to transmit. Just read 5-digit groups with a pause between groups. The code book is arranged like a bilingual dictionary. Code groups in some order (alphabetic or numeric) with their assigned meanings on one part of the code book; assigned meanings arranged in some manner (alphabetic) with their code groups in the other part.” This is a viable technique as well.
When I was a young troop (and I’m going to give away my age here) we still used PRC-77s. Now light units in those days were “equipment challenged” so not every radio had a Vinson (Google it). In fact only our Company Commander had one. So we lacked secure comms between the Company and the Platoons. And the way we overcame that was through the use of the Company Tactical Standard Operating Procedures (TSOP or TACSOP – an SOP that dictates how a company operates in a tactical environment) and the Communications Electronics Operating Instructions (CEOI later called an SOI – a classified controlled small book normally carried in the chest pocket dummy corded to the carrier). the CEOI gave us the ability to encode messages and other information along with authenticating traffic. The Company TACSOP gave us a neat tool – The Brevity Matrix. I’m going to throw some example tools out inspired by these “low tech” solutions to get your gears grinding.
Remember: A cipher code is only as good as the people using it and how well it’s protected. So if you plan on using it prepare to conduct some really intensive training along with thorough practice sessions along with setting rules on handling your ciphers. And spotcheck both the operation and handling frequently.
Now before we get into the meat and potatoes we need to add a few Prowords (remember those?) to our vocabulary. So jot these down:
ALL AFTER – Used in conjunction with SEND it tells the message sender to resend everything after a certain part of the message. i.e. “SEND ALL AFTER VICTOR VICTOR OVER”
ALL BEFORE – Similar to ALL AFTER except it’s used to send the portion of the message that precedes the stated portion. i.e. “SEND ALL BEFORE VICTOR VICTOR OVER”
AUTHENTICATE – This Proword is used to make a sending station conduct authentication from the authentication matrix.
I AUTHENTICATE – These prowords are used to let the receiving station know the transmitting station is sending an authentication cipher in response to the proword AUTHENTICATE. DO NOT conduct automatic authentication (i.e. before being prompted the transmitting station sends the phrase “I authenticate Victor Victor Zulu”). It is a sloppy practice that can compromise a cipher.
PREPARE TO COPY – This tells the receiving station to prepare to copy a message.
SEND – This lets the sending station know the receiving station is ready to copy the message.
Good to go? Now here’s an interesting tidbit. There are over a thousand words in the English Language that consist of ten letters without a single repeated letter. So for this example I’m going to use my big ass list of ten letter non repeating words as a cipher.
The first thing we’ll go into is Authentication. Authentication is normally used in response to a request, demand, or command. Authentication allows the receiving or directed station to confirm that the sender is the real deal and not some dirtbag trying to pull some B/S. Remember: this is an example. Semper Gumby it.
For my purpose I want to have a 10×10 authentication matrix to make it easy on me (remember I’m working with ten letter words). So I grid out a 10×10 grid and use the words from my list to fill it in. The way I did this one is I started at the top and worked inward from the top and bottom – one from the top, one from the bottom, one from the top, etc.. scratching them off as I went. Once I had the grid filled I added another unused word above and to the right side of the matrix. So this is what I ended up with:
So how do ya use this thing? It’s simple. The station requesting the authentication selects a letter from the top (shaded) row first and then from the shaded side row. For example the station callsign Howell prompts the station callsign Briggs to authenticate:
“BRIGGS THIS IS HOWELL, AUTHENTICATE TANGO SIERRA OVER”
Briggs in turn would look those letters up in the same order Howell did and cross index them – resulting in the letter “R”. Briggs would then authenticate in this manner:
“HOWELL THIS IS BRIGGS, I AUTHENTICATE ROMEO OVER”.
If the authentication is successful then that Cipher shouldn’t be used again for that period (more on that below). If it’s not then Briggs may send another. After two failed authentications Howell would ignore all traffic from Briggs and report a failed authentication to the NCS – which may prompt the QRF to move out and check to see why Briggs had its head up its ass and returned an incorrect authentication – possibly from an expired table (we’ve got a fix for that below).
Another neat technique is the incorporation of duress codes into authentication. If a station is under duress and being forced to send demands, requests, etc. they could slip a predetermined code or technique into the mix. i.e. instead of just authenticating with Romeo they may authenticate with Romeo Tango (the letter below R). The receiving and monitoring stations realize that a dual letter authentication isn’t right and take action. One thing really important here : If a duress is used in conjunction with a cipher then that cipher has to be immediately considered compromised.
Easy, eh? Alrighty, next up is one of my favorites – the Brevity Matrix. We used the brevity matrix to encode messages and even locations to send across unsecured nets. It’s similar to the authentication table however instead of just letters it contains words or even phrases. Using my list of ten letter words (over a thousand of them – that is some fascinating shit) we’re going to create another 10×10 grid. This time we’ll fill it in with common words, orders, information, whatever you feel needs encryption. Once we have it filled in (and you don’t have to fill the entire thing in mind you as blank spots could be a great method of deception – and don’t forget to jumble ’em up) once again we place one of our UNUSED ten letter words on top and the side like the Authentication table. So we end up with something similar to this:
Simple right – so let’s setup a message with it. Once again Briggs and Howell are on the net and Briggs is going to send Howell the message using what we’ve covered so far in comms techniques (including those breaks). Note how both stations use their callsigns – each message is started by the intended receiver followed by the transmitter. Now here’s a technique I recommend: Send brevity matrix codes in the same group size as any location types or other type encrypted info you send – it adds a layer of difficulty for the threat to determine what kind of information is being sent.
“BRIGGS, HOWELL, PREPARE TO COPY OVER”
“HOWELL, BRIGGS, SEND IT OVER”
“BRIGGS, HOWELL, I SEND ALPHA WHISKEY BRAVO, WHISKEY, ROMEO WHISKEY – BREAK” ..”UNIFORM WHISKEY PAPA, WHISKEY TANGO WHISKEY – BREAK”.. “INDIA WHISKEY OSCAR, WHISKEY, NOVEMBER WHISKEY – BREAK”.. “SIERRA WHISKEY ALPHA, OSCAR, OVER”
Now for SnG let’s say Briggs missed the last two sets. Here’s what should happen:
“HOWELL, BRIGGS, SEND ALL AFTER NOVEMBER WHISKEY OVER”
Howell would send:
“BRIGGS, HOWELL I SEND SIERRA WHISKEY ALPHA, OSCAR, OVER”
“HOWELL, BRIGGS, ROGER OUT”.
An “ALL BEFORE” request would be structured in the a very similar manner.
Now it’s not a good idea to throw messages in a straight line like I did – I got a bit lazy making that example and all those Whiskey lines would make breaking the cipher easier. If you scramble those words all over the matrix it’ll take the threat some serious time or a compromised cipher to figure it out. Also I didn’t invent the ten letter non-repeating Cipher technique – I’ve seen a lot of different forms of it over the years. I’m sure there are some other examples on the net as well
So how do we protect our cipher. My suggestion is to have one location (maybe the NCS) develop it daily and distribute it via sneakernet every day prior to the noon switchover with it going into effect at noon right along with the new freqs. To get the new one the old one has to be surrendered. It’s also a damn good idea to track how many go out, how many come in, and who lost their copy (it will happen).
Be creative and come up with your own systems. Remember it has to be simple enough for folks to use it or else they’ll get sloppy and evolve it creating one helluva comms mess. Take into consideration who you are working with in your AO, who needs the cipher, and who’s going to administer it. A cipher is not something you can just float along – if you let it get sloppy IT WILL be compromised.