Encryption: Keeping Data Secret

Plaintext, Ciphertext, and Keys

An encryption algorithm transforms readable plaintext into unreadable ciphertext, using a key, a piece of information that controls exactly how the transformation happens. Change the key, and the same plaintext produces completely different ciphertext.

Try it below with one of the oldest encryption methods on record: the Caesar cipher, which shifts every letter a fixed number of places through the alphabet. The amount that each letter shifts is the key.

That's the core weakness of any scheme with too small a key space: if there are few enough possible keys, brute force finds the right one. Modern algorithms don't fix this by hiding how they work (the method is usually public); they fix it by making the key space astronomically large.

Symmetric vs Asymmetric Encryption

Every practical encryption system has to solve two problems: how to scramble the message, and how the sender and receiver agree on a key without anyone else getting hold of it. Symmetric and asymmetric encryption differ mainly in how they solve that second problem.

This is the reason HTTPS, secure messaging apps and online banking rely on asymmetric encryption to get started, even though it's slower than symmetric encryption. In practice, most systems use asymmetric encryption just long enough to safely agree on a temporary symmetric key, then switch to symmetric encryption for the rest of the conversation, because it's faster.

Hashing Isn't Encryption

Encryption is designed to be reversed: with the right key, ciphertext transforms back into original plaintext. Hashing is designed to be a one-way street. A hash function takes input of any length, from a single letter to a multi-gigabyte file, and maps it to a fixed-length string of characters called a digest. It achieves this by scrambling the input's bits through multiple rounds of mathematical operations like shifting, combining, and mixing until the output bears zero resemblance to the original.

Unlike encryption, which relies on a key to reverse the process, hashing cannot be undone for two fundamental reasons. First, the mathematical operations used during mixing have no clean inverse to run backward. Second, squeezing arbitrary amounts of data into a fixed-size digest intentionally discards information. Because multiple different inputs could technically yield the identical digest (a collision), there is no unique original to recover. It is less like locking a document in a safe and more like blending fruit into a smoothie: no amount of skill can run the blender in reverse to get your whole apple back.

That unpredictability, combined with the lack of any reverse key, means the only way to figure out what created a specific digest is to guess inputs, hash them, and compare results. This one-way design is precisely what makes hashing ideal for password security. A system verifies your login by hashing the password you type and comparing the result to the stored digest, allowing it to validate your identity without ever needing to store (or even know) your actual password.

Digital Certificates

Asymmetric encryption solves key distribution, but it raises a new question: if Bob's public key just appears from somewhere, how does Alice know it's really his, and not an attacker's? A digital certificate answers that. It's Bob's public key, bundled with his identity, and digitally signed by a Certificate Authority, an organisation both Alice's browser and Bob already trust.

When Alice's browser connects, it checks that signature before trusting the key at all. That check, repeated automatically thousands of times a day, is what the small padlock next to a web address is actually reporting.

Every one of those fields exists to answer the same question: does this public key really belong to who it claims to? Get that answer wrong, and it doesn't matter how strong the encryption is afterward: you'd just be encrypting very securely to the wrong person.