A vastly oversimplified explanation of public-private key encryption

Years ago, I worked at a hosting company called Brightbox. Being a hosting company and being responsible for their customer's data meant that security was a high priority for them. One day, we were discussing some new feature and the CTO, John, pointed out a security flaw in my proposed design. This prompted a bit of a discussion, and John came up with the simplest description of how public/private key encryption works I've ever heard. And as I'm shit at maths, it was the first time I'd heard an explanation that made sense to me.

When computers were first networked together, the connections were assumed to be friendly and so data was passed around unencrypted. But now that the network dominates our entire lives, encryption is vital to keeping our information safe from prying eyes. And public/private key encryption is one of the fundamental ways of doing that.

As the name suggests, public/private key encryption has two keys - a public one, that can be shared freely, and a private one that needs to be kept safe. If Alice wants to send Bob a message, Alice obtains Bob's public key (which is not a risk as it can be shared freely with anyone), uses that to encrypt the message, then, when Bob receives it, he uses his private key (which is kept secret) to decrypt the message.

Which is all well and good. But John's description helped me make sense of it.

Sending encrypted messages

When Alice wants to send Bob a message, she gets Bob's public key. This is a small box with a lid on it. Alice writes her message on a scrap of paper, puts it in the box and snaps the lid shut. The box then locks and Alice puts the box in the post. Now, even if the message is intercepted in transit the message is safe, because the box is locked.

Bob then receives the message, finds his private key (in this analogy, it's a literal key) and unlocks the box. Bob can then read the message and reply to Alice, using a public key box that he has got from Alice.

Pretty simple eh?

There's a further step that this type of encryption allows, which, unfortunately, does not fit the analogy quite as well.

Digital signatures

If Bob wants to send a message to lots of people, he needs all of their public keys. Which is fine, as they are freely available. But sometimes you don't need full encryption, you just want to be able to prove that the message was sent by you.

So Bob writes a new message, then uses his private key to generate a small tag that he clips to the message. He then attaches the message onto the side of a lamp-post for anyone to read. When Alice reads the message, she wants to be sure that Bob actually wrote it, so she grabs one of Bob's public keys (the boxes) and inserts the tag into a slot in side of the box. If it fits, this proves that the tag was generated by Bob's private key, if it does not, then she knows to distrust the contents of the message.

All of this is based on maths that I don't really understand. The public and private keys are two, related, numbers, that when fed into the correct equations, produce known results. When Alice writes her message and feeds it in to the "encrypt this message" equation using Bob's public key, the message gets rewritten into gibberish. When Bob takes that gibberish and feeds it into the "decrypt this message" equation, using his private key. The encryption is reversed and the message becomes readable. Likewise, when Bob takes his message and feeds it into the "generate a signature" equation with his private key, it generates a long number that is based on both Bob's private key and the contents of the message. When Alice takes that number and feeds it into the "validate this signature" equation, along with the message itself and Bob's public key, the equation checks that the message contents and the generated signature match. If the wrong public or private key is used, then more gibberish is produced. If the second, public, message is tampered with after Bob has "signed" it, then the "validate" equation will let Alice know.

Backdoors

One common refrain at the moment is that law enforcement should have access to encrypted messages. Unfortunately, this is a huge risk. If the private key were, as described above, a physical key, then that would probably be OK. You could make a copy, then keep it in some vault in the Tower of London, only to be used when needed.

But the private key is just a number. Which means it can be copied and transmitted around the world in the blink of an eye. You might think it's possible to keep this number secure in some vault somewhere, but digital information always leaks somehow. Microsoft had their signing keys for the Windows source code compromised recently, even though they were stored in air-gapped computers with no access to any networks and extremely strict restrictions on who had physical access to the machines. (Apparently, one of the machines had crashed and the key was visible within the system traces that were being examined to find out what was went wrong - a very sophisticated attack but, nonetheless, one that shows that no system is safe).

That's why the best encrypted data is unrecoverable. The private key is stored in one place and one place only. If that key is lost, the encrypted data is lost forever. But that also means that the risk of compromise is limited to that one place and nowhere else.

End to end encryption

So far, we've described "encryption in transit". Alice's message is locked in the box while it is travelling to Bob, but once Bob has unlocked the box, the message is visible for anyone to read. When Bob takes the message and puts it into his "messages from Alice" folder, anyone breaking into Bob's house can find that folder and read it.

This is why we need need end-to-end encryption.

Once Bob has read the message, he puts it back in the box, locks it again and puts it into a cupboard. When the attacker breaks into Bob's house and empties the cupboard, all they have are locked boxes. Without Bob's private key (which he sensibly keeps in a safety deposit box at his bank), the messages cannot be read.

This is equivalent to your laptop being stolen and someone accessing the files on the hard drive. Or, more likely, a cloud server being hacked and someone reading your data within the databases on that server. If that data is encrypted by a key that is stored somewhere else (just like Bob with his safety deposit box), breaking in to the server is pointless.

Which is why WhatsApp periodically asks you to confirm your PIN. WhatsApp messages are end-to-end encrypted, so Meta themselves, let alone any evil hackers, cannot read them. And that private key is stored on your phone (and nowhere else), secured with a PIN. Because this key is so valuable to you (and anyone who wants to sneak a look at your messages), WhatsApp has to make sure that you still know the PIN, otherwise you lose access to your data and no-one can help you recover it.

Now, I'm sure there are many inaccuracies in this massive over-simplification of how public/private encryption works. But I think it's a pretty good overview and I hope you've found it useful.