What Is Encryption? A Plain English Introduction

You have used encryption dozens of times already today, and you almost certainly did not notice once. Every time you saw a padlock in your browser, sent a message on a chat app, or tapped your card to pay, encryption was quietly doing its job in the background. It is one of the most important ideas in all of computing, and yet the core of it is simple enough to explain over a cup of coffee.

The word sounds far more intimidating than the idea behind it. So let us strip away the intimidating part and build it up from nothing. By the end of this you will understand what encryption actually is, the two main flavours it comes in, how real systems cleverly combine them, and, just as importantly, what encryption cannot do for you.

The core idea

Imagine you want to send a note across a crowded room, but you do not want anyone in between to read it. If you write it plainly and pass it along, every hand it touches can peek. So instead you agree on a secret scrambling method with your friend beforehand. You scramble the note, pass the gibberish along, and only your friend, who knows how to unscramble it, can read it.

That is encryption. Scramble information so that only someone with the right secret can turn it back into something readable.

plaintext   "meet me at noon"
   +  key (a secret)
   =  ciphertext   "8f2a9c1e77b430d5..."   (gibberish to everyone else)

Three words carry most of the weight, and they are worth learning properly:

• Plaintext: the original, readable information. Your note before scrambling.
• Ciphertext: the scrambled, unreadable result. The gibberish you actually send.
• Key: the secret that turns plaintext into ciphertext and back again. Without it, the ciphertext is useless.

The mathematical recipe that does the scrambling is called the algorithm or cipher. The key is the specific secret fed into that recipe. Same recipe, different key, completely different result.

The golden rule: protect the key, not the method

Here is a principle that surprises people. A well designed encryption system stays secure even if everyone knows exactly how it works. All the secrecy lives in the key, not in the method.

This feels backwards at first. Surely hiding how it works makes it safer? In practice, the opposite is true. Secret, homemade methods almost always have flaws that stay hidden until an attacker finds them. Methods that are public get studied by thousands of experts around the world, and the weak ones get weeded out. So the strongest encryption uses well known, heavily tested public algorithms, and puts all its trust in keeping the key secret.

The practical lesson: be deeply suspicious of anything that claims to be secure because its method is a secret. Real security comes from a strong, public algorithm and a well protected key.

Flavour one: symmetric encryption

The first flavour uses one shared key for both locking and unlocking. The same secret scrambles the data and unscrambles it. This is called symmetric encryption, because both sides use the identical key.

Alice ---[ locks with key K ]---> gibberish ---[ unlocks with the same key K ]---> Bob

Symmetric encryption is fast, which is why it does the heavy lifting for almost everything: encrypting the files on your laptop, the video on a streaming service, the contents of a phone call. The gold standard algorithm here is AES, the Advanced Encryption Standard, used everywhere from your bank to your government.

But symmetric encryption has one awkward problem. Both people need the same key, so how do you get that key to the other person safely in the first place? If you send it across the same untrusted room you were worried about, an eavesdropper grabs the key and the whole scheme collapses. This is called the key distribution problem, and for a long time it was a genuine headache. The second flavour is what solved it.

Flavour two: asymmetric encryption

The second flavour is cleverer. Instead of one shared secret, each person has a pair of keys that are mathematically linked: a public key they can hand out to anyone, and a private key they guard closely and never share. This is called asymmetric encryption, because the two keys are different.

The magic is in how the pair works together. Anything locked with your public key can only be unlocked with your matching private key.

Anyone ---[ locks with Bob's PUBLIC key ]---> gibberish ---[ only Bob's PRIVATE key opens it ]

This solves the distribution problem beautifully. You can shout your public key from the rooftops, publish it on your website, hand it to strangers, and it does not matter, because the public key only lets people lock things for you. The private key, which does the unlocking, never has to travel anywhere. Common asymmetric systems include RSA and the more modern elliptic curve cryptography.

The catch is that asymmetric encryption is slow, much slower than symmetric. So it would be painful to use it for everything.

How real systems use both

Here is the elegant bit that ties it together. Real systems do not choose one flavour, they combine both to get the best of each.

1. Use slow asymmetric encryption ONCE, just to safely agree on
   a fresh shared secret key.
2. Then switch to fast symmetric encryption, using that shared key,
   for all the actual data.

This is exactly what happens every time you visit a secure website. Your browser and the server use asymmetric encryption for a brief handshake to agree on a temporary shared key, then use fast symmetric encryption for the rest of the conversation. You get the safe key delivery of asymmetric, and the speed of symmetric. If you want to see that handshake step by step, it is the subject of how HTTPS works.

In transit and at rest

You will constantly hear two phrases, and they describe the two different moments your data needs protecting.

• Encryption in transit protects data while it is moving across a network. The browser padlock, your messaging apps, your WiFi. It stops anyone along the path from reading or tampering with your traffic.
• Encryption at rest protects data while it is sitting still on a device, like your laptop or phone disk. It stops someone who physically gets the storage from reading it.

They protect different things and need different tools. A file can be safely encrypted at rest on your laptop, then decrypted and sent in plain text across a network, which is why you need both. The BitLocker analysis on this site is a detailed look at what can go wrong specifically with encryption at rest.

What encryption is not

This is where a lot of beginners trip, so it is worth being crisp. Encryption often gets confused with two very different things.

• Hashing is a one way street. It scrambles data with no way back, so it is used to check whether something matches or has changed, and to store passwords, not to hide and later reveal secrets. It is covered in password hashing explained.
• Encoding, such as Base64, simply reshapes data into another format so it travels cleanly. It uses no key, and anyone can reverse it in a heartbeat. It provides zero security.

If someone tells you data is "encoded for security", raise an eyebrow. Encoding hides nothing.

The takeaway

Encryption means turning readable data into unreadable data using a key, so that only someone with the key can read it back. It comes in two flavours: symmetric, which uses one shared key and is fast, and asymmetric, which uses a public and private pair and solves the problem of delivering keys safely. Real systems combine the two, using asymmetric to agree on a key and symmetric to protect the data. You rely on it constantly, both in transit as data moves and at rest as data sits still.

Keep the key secret and the method can be completely public. Remember that encryption is not hashing and not encoding. And remember that the algorithms are the easy part, while protecting the keys is the real work. That single set of ideas quietly underpins almost all of modern security, and it is the foundation the rest of this site builds on. The natural next step is what is cryptography, which shows where encryption fits in the bigger picture.