This is the second of two lead-up articles to How Blockchains Work, which will explain the foundation of blockchain-based technologies, such as Bitcoin and Ethereum. Stay tuned for it! In the meantime, read this and my post on cryptographic hash functions.
Encryption is an extremely important part of our digital world. It underpins our security, it bolsters privacy, and it improves our authentications.
The concept is simple (and is supposed to be). You have a message you want to send. You use a special sequence of numbers, letters, and characters - called a key - to transform the message into something completely unreadable - called a ciphertext. You send the encrypted message over to your contact, who then uses a key to decrypt the message back into plaintext in order to read it.
The simplest way to accomplish this is for both parties to have the same key. This is called symmetric encryption, since the key on both sides (encryption and decryption) is the same. Let's show this with an example.
In security parlance, people often refer to the various involved parties in their examples by the names Alice and Bob. If there are more than two people involved, there are other names that go further down the alphabet.
So let's suppose that Alice wants to send the message "hello" to Bob. To encrypt the message, they have agreed to shift each letter over by a certain amount. You may be familiar with doing something like this when you were a kid. They have a pre-arranged key of 2. So Alice adds 2 to each letter, like so:
h e l l o
+2 +2 +2 +2 +2
j g n n q
Alice sends "jgnnq" over to Bob, who then reverses the process to read "hello". Obviously, shifting every letter by a fixed amount is not very secure. In long messages for example, you can probably figure out what letters are by where and how often they appear in the text.
Instead of adding 2 to each letter, you can have a sequence of random amounts by which to shift each successive letter. Suppose the pre-arranged key is 39288:
h e l l o
+3 +9 +2 +8 +8
k n n t w
This particular example is a demonstration of the one-time pad. It is generally infeasible to use in practice, but this is very secure. In fact, as long as the key is at least as long as the message, it is the most secure encryption method there is.
And that's encryption! In real life, the messages and keys are longer and more complicated, but the concept isn't, really. Last thing to note is that computers deal exclusively with numbers, so messages and keys would be converted into big, long numbers using something like ASCII or Unicode.
One big problem with symmetric encryption demonstrated above is the "pre-arranged" part. How does Alice give Bob a key to decrypt her message? Alternatively, how might Bob give Alice a key to encrypt her message? Do they have to meet in person with a piece of paper or a flash drive every time they need a new key? Does she have to read the key out over a secured phone line? If they have a medium to send a key without fears that someone is snooping in to steal it, then they might as well send over the message using that medium. In short, transmitting a key is itself a message that would have to be encrypted - which cannot happen without a key!
This leads us to asymmetric encryption. As the name suggests, the key on both sides are not the same. The sender and the receiver have different keys. They come in pairs; one is used exclusively to encrypt, and the other is used only to decrypt. This system is also called public-key cryptography, and we'll see why in a moment.
If Alice wants to send a message to Bob, Bob (the receiver) uses a program to generate a new "key pair". This program outputs a public key and a private key.
Bob keeps the private key on his computer, making sure no one else has access to it. He then sends the public key to Alice, using any medium he prefers. He's not worried about someone stealing the key. In fact, the more public the public key is, the better, since it reduces the chance that someone will try to pretend to be him, and give Alice a fake public key.
Alice then uses the public key to encrypt her message. The public key can only encrypt a message; if you only have the ciphertext and the public key, there is nothing you can do to recover the original message. Only the private key can decrypt the message, and that's why Bob keeps that one secret.
Alice sends the ciphertext to Bob, who then uses his private key to read the original plaintext. If Bob wants to reply to Alice, she needs to generate her own public-private key pair, and they repeat the process in reverse.
How is it possible to have a key that encrypts but doesn't decrypt, and a another key that decrypts but doesn't encrypt? It involves some mathemagic that was discovered in the 1970s. Even though it took some geniuses to discover and implement it, it is remarkably simple to understand. I have written a separate article giving a brief overview, appropriately entitled "How Asymmetric Encryption Works Under the Hood". You can read that article now and then come back here, or you can read it afterwards... or you can skip it entirely (see if I care).
The important thing to remember is that Bob now has a pair of keys that work with each other. One encrypts only, and the other decrypts only, AND vice versa. One really cool property of all this math is that Bob can also encrypt something with the private key, and Alice (or anyone else) can decrypt it with the public key.
There are many uses for public-key cryptography, and I will highlight two.
The first is the one I described earlier, which is the most obvious. It is a system for securely sending messages where keys can be distributed in the open, without the need to hide them.
The second use case takes advantage of the fact that the process can be reversed - a message can be encrypted with a private key, and anyone with the public key (which can be... anyone) can decrypt it. What good is a message that anyone can decrypt? Because the public key and the private key can only decrypt each other's messages, then people can know with certainty that it could only have been you (the owner of the private key) that encrypted the message. This makes for a very efficient authentication system.
ssh is a program that uses this a lot. ssh allows a user to access the command line of another computer through the internet. Rather than using a password to grant access, the program simply checks if a certain message was encrypted using an authorized private key. To check this, it stores a list of allowed public keys, and uses the matching one to decrypt a test message. There is a back-and-forth conversation of encrypted messages called a handshake. If it actually works (does not produce gibberish), access is granted.
These applications work just as well for PGP/GPG (message encryption and signing program), TLS (the technology that secures webpages), and - as we'll see later on - digital signatures in blockchains.