Digital Security for Dentists and Chocolatiers (Pt. 1)

I pride myself on being a man with his finger on the pulse of the wants and needs of the general public; a sort of psychic thermometer of the zeitgeist. It’s a responsibility I take tremendously seriously, so when I sat down to figure out what to post about I immediately considered the unsettled nature of society and the precarious economic brinksmanship we’re all engaged in and knew – without the merest consideration of the possibility of the fractional perception of any feasible doubt – that it was my duty to write a couple of posts about encryption.

It’s a subject that – in the normal world where we’re not all filled with low-grade dread about curves and spikes and rates – often throws people for a loop. I’ve been lucky to work with (and for) some remarkable people in a breadth of roles and industries, and it’s always a little humbling to come across someone who knows a lot more than you about something eclectic or esoteric. I, for example, may know a lot about mobile device management, but I know nothing about being a chocolatier. If you put me in front of a barrel of raw chocolate and told me to make a ganache then there’d be little that I could bring to the table that couldn’t be slotted into the categories of “Inedible” or “Vile.” Likewise, I can design and build robust and secure wifi networks, but I can’t practice dentistry or surgery (and really shouldn’t ever be in a position where anyone would want me to try.)

You can’t be a specialist and a generalist at the same time, but we pick up broad strokes about fields of knowledge as we go along through life and use those to build models of about how the world works. I know that chocolate is made with dairy and sugar and that dentistry involves scrapy tools, soothing music and an ability to understand your patient’s incomprehensible gurgling and translate it to lies about how often they floss.

Encryption seems like it falls into this category; most clients are aware of the general idea of what it is, and that it’s important and that it’s a good thing, but there’s an inherent reticence to trust it. People are fine with the idea of end-to-end encryption because that’s something that conversationally makes sense; that something can be encrypted all the way through to its destination. It’s a functional linguistic model, but when you start talking about public and private keys and certificates then that model breaks down; not because laymen aren’t capable of understanding it, but because those aren’t concepts that can easily be understood in simple, layman’s terms by people who aren’t IT people and are, say, chocolatiers and dentists.

So, I’m going to try and fix that in a handful of simple, easy lessons that involve minimal bloodshed.

(Attention: Other IT people, please make note: this is supposed to be a high altitude view of the subject. I don’t want a lot of messages along the lines of “what about session keys” or “actually, you can use private keys to encrypt data for public keys when you’re working with digital signatures” and so on. This one’s for the chocolatiers and dentists, not you, okay? Cool.)

The Golden Rule

“Security is mostly a superstition. It does not exist in nature.” – Helen Keller

I like to trot this quote out a lot when I talk about encryption and security, because while Helen Keller was famously not a security expert (and the rest of the quote was talking about how you should embrace risk and change,) this absolutely cuts to the core of the problems we face in keeping people and data safe.

Notably: you can’t. Security is a lie. It doesn’t exist. Zebra are not safe from Lions. You can skip driving and never fly in a plane and obsessively try and control every aspect of your health and still die from being hit by lightning or choke on a brussel sprout. There are no guarantees; in the real world there’s no 100% infallible path to safety. When we talk about security, what we’re really talking about is the mitigation of risk.

And really, that’s fine. Think of information security as a boat with a hole in the bottom. Provided you’re paying attention and bailing water out as fast as it comes in, it won’t sink; and in fact if you keep paying attention and are practical and smart about your bailing strategy then the boat can keep floating indefinitely. The other passengers may not even notice that there’s a hole in the boat at all.

Okay, that’s not the greatest metaphor, but what I’m trying to get across is this: there’s always going to be some unseen, unanticipated vector of attack, but with good practices and responsible vigilance you can greatly cut down or almost eliminate how that could effect you.

The History of Encryption (1900BC to 1970AD)

Well, now that’s out of the way we can dial in on what modern encryption is and how it works, and a good introduction to that is to go into what modern encryption isn’t.

When we think about encryption in the simplest of terms we tend to think about codes and ciphers, which are forms of symmetric encryption. The idea of substituting one thing for another in order to obfuscate a message is the simplest and oldest form of encryption, and given a good enough schema it can be decently effective.

Symmetric encryption really refers to a form of encryption where one key is used to encode and decode a message. While what’s below mostly refers to antiquated forms of symmetric encryption (because they’re historically interesting and conceptually easy to get your head around) it’s still a method that’s used in modern security. Blowfish, DES, and the assorted flavors of AES (AES-128, AES-192 and AES-256) are all examples of symmetric encryption.

The Egyptians were doing it with hieroglyphs, but as seems to be the case with a lot of technologies it was the Romans who kicked things up another conceptual notch by inventing Shift Substitution ciphers – while Julius Caesar is widely credited with the invention there’s no absolute way to be sure who had that bright idea, but the fact remains that by the 1st Century A.D the Romans had it all solidly nailed down. The problem with the old Substitution cipher was that if messages were complex enough then it was possible to look at the frequency of certain words or glyphs and speculate/infer what they might refer to, but Shift Substitution was a degree more complex because it shifted each character in a message up by a fixed interval, thus:

In the above example you can see that each letter of the alphabet is shifted up a pre-ordained number of places, so that A becomes E, B becomes F and so on. Without knowing the number of places that each character is shifted through it’s difficult (although ultimately possible) to work out what the message might be.

Finally, we jump forward about 1700 years to the late 1800s and the invention of the One-Time Pad:

One-Time pads were cyphers initially created for Telegraphic transmission, and they were used extensively during World War II, and sort of built off of the shift-substitution model. Each message sent with a one-time pad used a unique set of numbers as ciphers – one per letter – with the sending and receiving party encoding and de-encoding using the same sets. After each transmission the set of numbers was destroyed (thus only used “One-Time”), so if the transmission was intercepted there was no way that the message could be cryptographically compromised. So, if we wanted to send a message (“Hello World”) then we’d assign each letter a number in the alphabet with, say, A=1, B=2, C=3 and so on, then add a pre-defined set of numbers to that numerical value as a key, wrapping values above 26 back around so that 27=A, 28=B etcetera. The end result would look something like this:

Given a long enough set of numbers (or “key”) then One-Time pads were functionally unbreakable.

All the above are examples of symmetric encryption, and follow the same rules. First, they apply a shared key to a message – by “shared” key I mean simply that both the person sending and the person receiving the message have a piece of knowledge that they share that let them know how to encode/decode that message. Secondly, that shared key can be a string, a character, or an integer. Thirdly, that key can be an operation.

Let’s say that I’m Bob and my friend Alice and I want to share a piece of encoded information. The process would look something like this.

First, I’d encrypt my message with a key (a substitution or shift-substitution cypher like the Egyptian hieroglyphs or the Roman shift substitution or a one-time pad, or possibly an operation or algorithim-based approach like AES-128).

Next, I’d send that key to Alice so that when I sent her the message she’d have the key to open it. If the key is intercepted en route or doesn’t get through then it’s just the key – it doesn’t reveal anything about the message because the message hasn’t been sent yet.

Then I’d send Alice the encoded message.

Finally, Alice could open the message sing the key I’d sent her:

While these traditional, straightforward substitution cyphers aren’t exactly sophisticated in the modern world, they were sort of the bleeding edge of encryption back in the day, but even if you were using something as well-designed as a One-Time pad you were still stuck with the essential flaw at the root of this approach: key distribution. How you got the key from one party to another was problematic; you could go and meet the person face-to-face and give them the key, you could use an existing secure channel of communication to get the key to them, or you could give the key to someone you trusted and have them hand the key over for you. None of those are iron-clad secure options, and all of them are rife with breakpoints and weaknesses.

Next time: The History of Encryption (1970AD to today)…