Hey Internet.

Since my last blog post, I've been meaning to write in more detail on digital privacy and how you can take it back. My last post was written very generally without going into specifics, and that's largely because it's such a vast topic that it would be impossible to cover the entirety of it in a single blog post—or perhaps even a single lifetime. Nevertheless, I'm going to do my best. My goal today is to attempt to demystify the subject of cryptography, another deep subject in and of itself. I don't like to pick the easy topics, do I?

The reason I'm choosing to write about cryptography is because it's such an essential concept in the overarching topic of digital privacy. In the digital world, pretty much everything relies on it, so having a basic understanding of what it is and why it's important is extremely useful. In this post, I won't be going into the detailed math behind how it works; I'm trying **not** to put my readers to sleep, after all. If you **are** interested though, Khan Academy has a pretty good course on it.

So let's start by explaining the problem that cryptography helps us to solve. When you use the internet, you're connecting your device to some other device somewhere in the world and exchanging information. Maybe that device is on another continent; maybe it's just a few meters away. What's important to understand is that this communication line usually isn't a direct one. The messages that get passed from one end to the other typically travel through multiple other devices to get there, often dozens or more. Any one of these devices could easily read, copy, modify or even forge these messages. Obviously, this is a big problem for privacy.

Modern cryptography allows us to do basically two things:

- scramble those messages in a way that can only be descrambled by the intended recipient, making them effectively useless to an eavesdropper
- digitally "sign" those messages, so that the recipient has a way of verifying that the message was in fact sent by the person it claims to be from

There are many, many different ways of doing this, so I'm only going to talk about the high-level concepts here, but cryptographic algorithms fall into basically two categories:

- symmetric key algorithms
- asymmetric (or public) key algorithms

I'll describe each of these in a little more detail below, but a cryptographic system is made up of basically four parts:

- the secret message you want to send (the plaintext)
- a procedure for scrambling (encrypting) and descrambling (decrypting) the message (the cypher)
- some piece of information that changes the way the message is encrypted/decrypted (the key)
- the scrambled message (the cyphertext)

Obviously, the plaintext needs to be kept secret; that's the whole point after all. If a cryptographic system is implemented properly, the cyphertext can then be broadcast as publicly as you want, since it'll be absolute nonsense to anyone who doesn't possess the decryption key. Without the decryption key, the cyphertext should be indistinguishible from random noise.

There are some things about a proper cryptographic system that might surprise you. For starters, a good system should not rely on keeping the cypher itself a secret. The basic idea behind this is that if the knowledge of how a lock works makes the lock less secure, then it was a bad lock to begin with. This is a mistake that literally helped to determine the outcome of World War II. This brings us to the second surprising point: it's considered unwise to rely on new cryptographic systems. The ones that are considered the most secure are typically older algorithms that every cryptographer worth their salt has tried (and failed) to crack. These are the algorithms that have stood the test of time.

With that out of the way, let's look at the difference between symmetric and asymmetric key systems. Symmetric systems are easer to understand, so we'll start there. In a symmetric system, the same key is used to encrypt and to decrypt the message. For a long time, this was the only way to do it. Symmetric keys suffer from one major issue though: at some point, the sender and receiver need to have gotten together privately to agree on a key to be used. This **has** to be done in person, because if someone else gets ahold of this key, it becomes useless.

Asymmetric, or public key encryption gets around this in a novel way. In a public key system, everyone generates **two** keys: a public key, and a private (or secret) key. These keys are mathematically linked together, and as their names would imply the private key needs to be kept a secret, while the public key can be freely shared. In fact, the more widely known your public key is, the more useful it becomes. It should not be possible to use the public key to determine what the private key is. When a message is encrypted using the public key, it can **only** be decrypted by using the private key. Conversely, in most public key systems, you can use the private key to digitally "sign" a message. That signature can be verified using the public key. If the verification passes, it ensures that the message hasn't been altered, and was signed using the private key.

Okay, that's a fair bit more complicated, so let's have a look at what this looks like in practice. Let's say that Alice and Bob want to send messages to each other. They each generate a key pair, and exchange public keys. This can be done in person or not, as long as they both have a way of being **certain** that they have a public key that belongs to the person they think it does. If Alice wants to send a message to Bob, she first signs the message using her private key, then she encrypts it using Bob's public key. She can then send the resulting cyphertext to Bob however she wants. She could broadcast it from a megaphone on the roof of a tall building if she so desired, and it would be perfectly safe (apart from the noise complaints).

Upon receiving this message, Bob can then use his private key to decrypt the message. Since Bob is the only person who has this key, Bob is the only person who can decrypt the message. Bob then uses Alice's public key to verify the signature of the message. If the verification passes, Bob knows that Alice was the person who signed it—or at least that the signer had Alice's private key. This is why it's so important to **never ever** share your private key with **anyone**.

Now this may all seem rather complicated, but if you're reading this blog post, you're probably already using public key encryption and perhaps didn't even know it. Your browser automatically took care of it for you. That's why you're suppoed to look for the padlock icon in the address bar; it tells you that your connection is encrypted. If encryption is done properly, it doesn't have to be difficult to use. Still, it's useful to have a basic understanding of what's going on under the hood.

I had hoped in this post to go into some of the things that some governments are doing that threaten to weaken cryptography and why we need to be diligent about making sure that doesn't happen, but this post is already getting pretty long, so I'll have to cover that later.

Have a good one.