Note: I’ve decided to migrate my blog over to Substack due to changes to how Medium works for editing and updating content. It’s been a good run (zomg almost 10 years!) but excited to have a space and experience to better focus on what I love about writing.
To paraphrase the great philosopher Redman, in the modern world “C[ryptography] Rules Everything Around Me - C.R.E.A.M.” Whether it’s for protecting the privacy of conversations or sensitive data in a digitally native world, acting as the primary arbitrator for verifying identity, or being the mysterious force supporting various claims about blockchain and cryptocurrency, cryptography is arguably one of the most important fields of applied computing in in the modern world.
It’s also one of the most arcane. Most of crypto involves seemingly impenetrable math, is mired in confusing language and terms that don’t get a lot of use outside of its niche domain, and until recently its use has largely been reserved for defense or enterprise information technology.
I write for two reasons: to share stories and information I think needs to be told, and to reflect on my own experience to try and learn something new in the process.
There are some amazing stories to be told in how encryption works: how encryption does what it does, how its application can be be used to improve vital things like privacy and security, and what are the hard limitations and threats to modern cryptography that check those improvements. As someone who has a degree in the field and around a decade of post-graduate work in building, investing in, and even breaking cryptography I’m excited to be able to tell some of those stories.
This is the beginning of a blog series that seeks to tell the story of modern cryptography and encryption. More importantly, it seeks to tell that story as simple as possible and without math.
This isn’t to say that math is bad or that I won’t use terms from mathematics. In fact we’ll be covering a lot of how math is the foundation of crypto and what a lot of those fun mathematic terms like entropy, computational intractability, and the Discrete Log Problem mean and how they power modern and future technology.
But rather than how most cryptography and encryption is presented, I want to make this as dead simple to read as possible. At most this series will assume the reader has a basic knowledge of American high school algebra. We’ll work together to build terminology from real world examples of how it’s used rather than the typical “write a bunch of proofs and fucking hope for the best” that most cryptologists use to learn crypto.
And I firmly promise that I’ll work to ensure that the only thing arcane about how we talk about crypto are the various sometimes-less-than-subtle references to the Wu-Tang Clan, Tik Tok Memes, Electronic Dance Music, or nerd culture like Warhammer 40k and video games that I’ll flower throughout our exploration.
Gucci? Gucci. Let’s dive in and start with the beginning: keeping secrets.
Cryptology: The Ancient, Mysterious Art of Secrecy
We all keep secrets.
Sometimes we keep them because they’re uncomfortable truths. Other times they’re truths that don’t belong to just us: information shared with us for a singular purpose that may hurt us or the people who shared them if they became public.
Whatever the reason, keeping and discretely sharing secrets is a practice as old as language and conversation itself. That practice has a name: cryptology - literally the “study of secrets” in Ancient Greek. Cryptology is an ancient field; cryptologic study of heiroglyphs and old Minoan architecture are as old as Plato and Western Culture.
So too are the foundational uses of cryptologic study: the creation of mechanisms to keep and discretely share secrets as well as the mechanisms to decipher secrets protected by such means. These are respectively cryptography (the writing) and cryptanalysis (the “breaking” or “hacking”) of secrets. We also typically refer to applying cryptography as encryption - literally writing secrets - and collectively refer to the mechanisms of keeping those secrets as “crypto1.”
Ciphers and Keys
Example of an ancient scytale. Non-mathematic encryption like the scytale were the primary mechanisms for keeping secrets until the late sixteenth century. Source: CacheSleuth
We typically think of cryptography and mathematics as one in the same. But this is a relatively new phenomena. For most of cryptography’s life, even until as recently as the early 19th century, non-mathematic mechanisms were used in encryption.
Why? Well it’s simple: math is fucking hard. With widespread literacy being a similarly modern phenomena, it was a lot to ask someone to know what something like a “transposition matrix” is if they could barely read.
In fact even as late as the late 19th century very serious secrets were shared through non-mathematic encryption. My favorite example is how Charles Napier, the commander of the Bombay Army, messaged his conquest of the city of Sindh/Scinde across couriers during the mid-19th century campaign to take the province in what’s now modern day Pakistan.
Rather than come up with some complex math or scheme to keep a secret, he sent a one-word missive to his commanders at the time: peccavi. Peccavi is Latin - specifically the first person, perfect conjugation of the Latin word peccavo: I sin/transgress.
In English, peccavi literally means “I have sinned.” Or, for someone who likes dad jokes and like Napier was a poncy Englishman who studied Latin and had context on his mission, “I have Sindh.” Who said violent and frequently abhorrent colonialism can’t have some funny stories?
Whether you’re implementing encryption in a quantum computer or sending one-word Latin dad jokes, we call the mechanism to implement encryption a cipher. And for most of human history ciphers were either obscure languages (i.e.: Latin puns like peccavi) or were physical tools like the scytale - a strip of paper that was folded around a log or a stick.
With the scytale you wrote a message across the strip in such a way that it was legible only if someone had another stick of the same dimensions: size, width, etc. You could then take the paper and, assuming someone wasn’t a super genius or had a lot of time on their hands, hand it to a courier who probably was going to give it to the party that you wanted to share the secret with.
Assuming you and your intended party had a stick or wooden dowel of the same dimensions, the recipient of your paper could wrap it around their own stick/dowel and read your message. In encryption this is something called a key - a critical secret shared between you and an intended party/parties in order to discretely share messages between you and them.
Protocols and Channels with Alice, Bob, and Eve
Alice, Bob, and Eve. Most, if not all, modern cryptography uses this framework to discuss protocol and channel security
A common misconception we have about history is that our less technologically-advanced ancestors were less smart. Far from it. It didn’t take long for ancient humans to realize that the general of a Spartan army probably didn’t keep wooden dowels on them to bake cakes in the field. And as commerce and warfare advanced, so too did ciphers and keys to ensure that private communication could keep pace.
The advancement of ancient ciphers is a fascinating topic that’s well worthy of its own blog post (or PhD thesis to be honest). Given our goal here is to share how crypto works in modern technology, we’ll skip over that. But things basically started to get complicated relatively quick, and as such we needed to create new ways to frame how private conversations get shared between intended parties - as well as the threats to those private conversations.
The most common framework used in cryptology for studying a cipher is something we call the “Alice and Bob” Framework. It doesn’t really have a name, but just like every programmer in the world seems to know about functions via the phrase foo() and bar(), most cryptologists and cryptographers think about ciphers in the framework of two parties named Alice and Bob sharing a private conversation.
Who are Alice and Bob? Doesn’t matter. They’re two mythical people who are trying to have a private conversation over some medium - letters, telegraphs, a screaming match over a rugby field on a rainy day, etc.
That medium is very important though. We call that medium a channel, and depending on how secure that channel is the Alice and Bob’s conversation may need a lot more or a lot less security.
For example: if that channel is at private room behind six armed guards scrutinizing Alice and Bob’s identity, the amount of security Alice and Bob may need to employ for making secrets in their conversation stay discrete and away from someone eavesdropping them may be less than if it was screamed in public at a seemingly deserted rugby field on a rainy day.
Thus the relative security of the cipher used to encrypt a secret, and the keys that Alice and Bob share, often will be a function of the channel. Sometimes if the channel is secure enough we don’t really need a super secure cipher. Or maybe how Alice and Bob generate and share keys (a practice called key exchanges that we’ll go into in the future - oh boy we will we talk about key exchanges) may need to change depending on the security of the channel.
But we can’t talk about how secure a channel is without talking about the adversary - whoever is trying to spy/defraud/steal/otherwise fuck with Alice and Bob’s private conversation. In this framework we routinely use the term “Eve” to refer to an abstract adversary attempting to eavesdrop on Alice and Bob.
There are other terms to refer to Eve depending on what they are doing. You might hear words like “Mallory” denote that maybe the adversary isn’t trying to just eavesdrop, they’re doing to steal or destroy information in that private conversation between Alice and Bob. In reality most cryptologists don’t go into that level of detail of linking the adversary’s actions with their name: Alice, Bob, and Eve are good enough.
Final note here about this framework: while ciphers and keys are used to protect the secrecy of the messages Alice and Bob are trying to share with each other, they aren’t necessarily the same thing as the conversation. Often due to technological, logistical, or computational constraints, Alice and Bob may not encrypt everything they’re saying or require the same kinds of security for all of their conversation. Maybe not everything in the conversation is sensitive? Maybe some of it doesn’t need encryption?
This is why we have a special term for the conversation between Alice and Bob: a protocol. A protocol is an exchange between Alice and Bob, wherein some or all of the conversation may employ encryption. During the protocol keys may be exchanged (e.g.: Alice may slip Bob a wooden dowel), Alice and Bob may verify each other’s identity (e.g.: Alice may ask Bob about traffic to the rugby field to see if it’s actually him), or any host of other things.
Protocols are about a lot more than just the cipher or keys. If you want to look at the security of an encrypted conversation or system (or try to break that security) you’ll typically start with analyzing the protocol and assumptions about security of the channel and potential adversaries.
TLS is 1337
Let’s put all of this into practice and look at a real world secure protocol: the Transport Layer Security (TLS) Protocol. Or, for human beings, the thing that happens when I put a s at the end of https:// in a website’s URL.
TLS Handshake Protocol (source: Cloudflare)
This is the Handshake portion of TLS. Basically this is the introduction of where a client (i.e.: your computer’s browser) waves at a server (i.e.: whatever is at the DNS entry for “https://www.twitter.com”).
In this model your client is Alice, Bob is the server, and the channel is the internet - specifically the TCP/IP networking protocol.
You’ll notice here that there’s different colors for some of the data passed in the protocol. That’s because the protocol switches here from TCP/IP to TLS: once the server responds to syn/ack (basically the equivalent of “sup” and “yo what’s good”) the client and server exchange a series of cryptographic data. This data does two things:
Gets the client and server to agree upon what encryption they’ll use to verify each other and begin communicating.
Agree upon how they’ll share keys to encrypt data between them.
You’ll notice here that the layout of how this all happens starts to look a little easier to read if you know how the Alice/Bob relationship works. And rightfully if you’re trying to eavesdrop on Alice and Bob (or ideally stop eavesdropping) it’s a lot easier here to look at what data gets passed and how it gets passed once you speak the lingo.
Next Steps
So now we know the basics of encryption and cryptography: what ciphers are, what keys are, and how we use both to host secure conversations in the context of protocols.
Now that we’ve got this under our belt we’ll move onto examining the core, most foundation form of mathematic ciphers: symmetric cryptography. And in the process maybe we’ll learn some hacking and codebreaking 😈.
TL;DR
Secrets can be any kind of data or message we want to be discrete.
Cryptology is the practice of keeping secrets. Encryption/cryptography is the practice of writing secrets. Cryptanalysis is the practice of breaking encryption and stealing secrets (i.e.: codebreaking).
Ciphers are mechanisms to implement encryption. They don’t have to be mathematical, but most of our modern ciphers involve math because computers are good at codebreaking.
Keys are secrets shared between parties to decipher/decrypt encrypted secrets.
Protocols are conversations between parties (e.g.: “Alice and Bob”) that may have sensitive components. Not all parts of a protocol are encrypted.
Channels are the media wherein protocols are hosted. Depending on how secure the channel is and the potential adversaries accessing that channel, the protocol may need to be more or less secure.
Quick aside on this: most mathematicians and technologists that build encryption technology know how to both write and hack into secrets. To build a good bank vault you need to know some safecracking. Pedantry and being super specific about terms is important in this line of work, and it’s one of the reasons why the term “crypto” is so important to us. It’s one of the few, easy, single-syllable catch-all terms we have to describe a whole lot of stuff in a concise manner. It’s also why a lot of cryptographers were pissed when it was kind of molded into cryptocurrency, because its original purpose was to succinctly describe some of the really complex stuff we’re going to go over around how you keep secrets.