What is cryptography?

Key takeaways Cryptography scrambles information so only the key holder can read it. You turn readable plaintext into scrambled ciphertext and back again using a key. The crucial idea: security lives in the key, not in keeping the algorithm secret. And the golden rule for everyone who isn’t a cryptographer — don’t roll your own: use vetted, standard tools. This module builds on what cybersecurity is.

Almost every protection you’ll meet later in this path — private messages, secure logins, tamper-proof updates, the padlock in your browser — rests on cryptography. It’s the machinery that lets two parties trust data even when it travels across networks full of strangers. This lesson gives you the mental model; the rest of the module fills in how each piece works.

Encryption in one picture

At its core, encryption is a two-way trip:

  • Encrypt: take plaintext (the readable message) plus a key, run them through a cipher (the algorithm), and out comes ciphertext — scrambled, meaningless-looking data.
  • Decrypt: take that ciphertext plus the key, run it back through the cipher, and recover the original plaintext.

The whole point is what happens without the key. Someone who intercepts the ciphertext — on a network, on a stolen disk, over the air — should be left with noise. The key is the difference between a readable message and useless garbage.

plaintext encrypt ciphertext decrypt 🔑 key 🔑 key unreadable without the key
Plaintext plus a key becomes ciphertext; the same key turns it back. Intercept the ciphertext without the key and you have nothing.

The key is the secret, not the algorithm

Beginners assume good cryptography works by keeping the method secret. It’s the opposite. The guiding rule is Kerckhoffs’s principle: design your system so it stays secure even if the attacker knows everything about the algorithm — the only thing they must not have is the key.

That sounds backwards until you see why it’s strength, not weakness. A secret algorithm has been examined by exactly the people who wrote it. A public algorithm is attacked for years by cryptographers worldwide trying to break it, and the ones still standing are the ones we trust. Secrecy of the method is a crutch that snaps the moment someone reverse-engineers your software or leaks a document. Secrecy of the key is a promise you can actually keep — and can change if it’s ever exposed.

So the modern standards — AES, RSA, the algorithms behind HTTPS — are all completely public. Their safety rests entirely on the key.

Don’t roll your own crypto

Here’s the single most repeated piece of advice in the field: don’t roll your own crypto. Writing an encryption scheme that looks fine is easy. Writing one that survives expert attack is extraordinarily hard, and the failures are subtle — a predictable random number, a reused value, a timing quirk that leaks the key one bit at a time. None of these show up in normal testing. The code runs, the output looks scrambled, and it’s quietly broken.

The professional move is to use vetted, standard libraries and protocols built and reviewed by specialists, rather than inventing your own cipher or stitching one together from primitives you don’t fully understand. The danger is always in the details, and the details are exactly what a homegrown scheme gets wrong.

Encoding vs. encryption vs. hashing

Three ideas get confused constantly. They are not interchangeable:

  • Encoding (for example Base64) reformats data into another representation — say, to survive being sent through a text-only channel. It’s reversible by anyone, uses no key, and provides no secrecy at all. Base64 is not protection; treating it as such is a classic mistake.
  • Encryption is reversible only with the correct key. That’s the whole point — it hides the content from anyone without the key.
  • Hashing is a one-way transformation: it turns data into a fixed fingerprint that can’t be reversed back into the original. It’s used to detect tampering and to store passwords safely, and it’s covered in hashing & integrity.

If you remember one line: encoding is not secret, encryption is secret with a key, and hashing doesn’t come back at all.

What crypto does and doesn’t do

Used correctly, cryptography protects confidentiality (only the key holder can read the data) and helps guarantee integrity (you can tell if data was changed) — both for data in transit across a network and data at rest on a disk. That’s a lot of the security you rely on every day.

But cryptography is not magic, and it protects a narrow thing. It cannot fix:

  • Bad key handling — a key emailed in plaintext or hard-coded in your app is no longer secret, and the encryption around it is worthless. Handling keys well is its own discipline; see managing secrets & keys.
  • Weak passwords — if the key or password is guessable, the strongest cipher in the world folds instantly.
  • An already-compromised machine — if an attacker is already on the device reading your plaintext before it’s encrypted (or after it’s decrypted), encryption on the wire never sees the data they’re stealing.

Cryptography secures data as it moves and rests. It does nothing for the endpoints and the humans handling the keys — which is exactly why the rest of this path exists.

Quick check: in a well-designed cipher, what must stay secret for it to be safe?

Recap

  • Cryptography scrambles information so only the key holder can read it: plaintext + key → ciphertext, and back again.
  • Without the key, ciphertext should be useless to anyone who intercepts it.
  • Security lives in the key, not the algorithm — Kerckhoffs’s principle means good crypto is public and peer-reviewed.
  • Don’t roll your own — use vetted, standard libraries and protocols, because the failures are subtle.
  • Encoding (like Base64) is reversible and not secret; encryption needs a key; hashing is one-way — don’t confuse them.
  • Crypto protects confidentiality and integrity in transit and at rest, but can’t fix bad key handling, weak passwords, or an already-compromised machine.

Next up: symmetric & public-key encryption