What is cryptography?

You've already met cryptography scattered throughout this course — Base64 encoding in the CTF Zone, password hashing in Path 10, AES and RSA in ransomware's mechanics (Path 17). This path starts from zero and builds the foundation that makes every one of those moments make real sense, rather than feeling like scattered vocabulary.

The three things people confuse constantly

Almost everyone new to security mixes up three genuinely different concepts. Getting this distinction solid, right now, will save you real confusion for the rest of this course:

Concept What it does Can it be reversed?
Encoding Represents data in a different format Yes, by anyone — no secret needed
Encryption Scrambles data using a secret key Yes, but only with the correct key
Hashing Produces a fixed-size fingerprint of data No — one-way, by design

Encoding — not security at all

This course's CTF Zone crypto challenges already demonstrated this directly: Base64 is encoding, not encryption — anyone can decode it instantly, with no secret required. Encoding exists purely to represent data in a different, more convenient format (binary data as printable text, for instance) — it provides zero confidentiality. Treating encoded data as "protected" is a genuinely common, genuinely dangerous real-world mistake.

Encryption — scrambling with a recoverable secret

Encryption transforms readable data ("plaintext") into unreadable data ("ciphertext") using a key — and critically, it's designed to be reversed by anyone holding the correct key, and only by them. This path's next two lessons cover the two major families in depth: symmetric encryption (one shared key locks and unlocks) and asymmetric encryption (a public key locks, a different private key unlocks).

A simple, ancient example to build intuition — the Caesar cipher, referenced back in this course's CTF Zone: shift every letter forward by a fixed number of positions in the alphabet.

Plaintext:  ATTACK AT DAWN
Key:        shift by 3
Ciphertext: DWWDFN DW GDZQ

This is genuinely, trivially breakable (there are only 25 possible shifts to try), but it demonstrates the core idea every modern cipher builds on: a transformation, controlled by a key, that's easy to reverse if you know the key and hard to reverse if you don't.

Hashing — the one-way fingerprint

Hashing takes data of any size and produces a fixed-size output (a "hash" or "digest") — and, critically, this process is deliberately one-way: there's no key to recover the original data from its hash, by design. This is exactly why Path 10's passwords-and-hashing lesson insists passwords be hashed, never encrypted, for storage: even the service storing your password should never be able to recover its plaintext value, only verify a match by hashing whatever you type and comparing.

SHA-256("password123") = ef92b778bafe771e89245b89ecbc08a44... (always the same output for this exact input)
SHA-256("password124") = 8a9c1b5a...  (completely different output — even a tiny input change scrambles everything)

That last property — a tiny input change producing a completely different output — is called the avalanche effect, and it's exactly what makes hashing useful for detecting any tampering with data, not just passwords.

A brief history — why cryptography matters beyond computers

Cryptography is far older than computing itself, and knowing a little of that history helps ground why the field is structured the way it is today. Military and diplomatic communication drove cryptography's development for millennia — the Caesar cipher above genuinely was used by Roman military commanders; centuries later, the German Enigma machine's mechanical rotor-based encryption, and the Allied codebreaking effort at Bletchley Park (involving Alan Turing, widely regarded as a founder of computer science) that eventually broke it, is often cited as a pivotal moment in World War II and a direct ancestor of modern computing itself. The core lesson that keeps repeating across this entire history, right up to the present day: a cipher that seems unbreakable to its own designers often has a flaw invisible to them but findable by dedicated, motivated adversaries — which is exactly why "never roll your own crypto" (a phrase you'll see repeated throughout this path) isn't overcautious advice, but the hard-won, historically-proven lesson of a field with a long track record of confident designers being wrong.

Kerckhoffs's principle — a foundational design rule

A specific historical lesson worth naming directly, since it shapes essentially every modern cryptographic system: Kerckhoffs's principle, formulated in the 19th century, states that a cryptographic system should remain secure even if everything about it — the algorithm, the implementation, the design — is publicly known, with the sole exception of the key. This is precisely why AES and RSA (covered in the next two lessons) are open, published, publicly-scrutinized algorithms rather than secret proprietary designs — a system's security should never depend on attackers not knowing how it works, only on them not having the specific secret key. A corollary worth internalizing: "security through obscurity" (hiding how a system works, hoping attackers won't figure it out) is not a substitute for genuine cryptographic security, and a design that only holds up as long as its inner workings stay secret should be treated as fundamentally broken, not merely unproven.

Ask: "Do I need to get the original data back?" If yes, and you don't mind anyone being able to reverse it, that's encoding. If yes, but only someone with a secret should be able to, that's encryption. If no — you only ever need to verify, never recover — that's hashing.

Why is it a serious security mistake to "encrypt" a password with a reversible scheme instead of hashing it, even if the encryption key itself is kept perfectly secret?

Show answerEncryption is designed to be reversible by anyone holding the key — which means whoever controls that key (the service operator, or an attacker who steals it) can recover every user's actual plaintext password at once. Hashing has no key to steal in the first place; even the service itself cannot recover the original password, only verify a match. Since password reuse across sites is extremely common (Path 00's passwords lesson), a reversible scheme turns a single leaked key into a mass password-recovery event across every user, while a properly hashed database (even if stolen) requires attackers to crack each hash individually — dramatically slower and, with a strong unique password, often practically infeasible.

Key terms

  • Plaintext / ciphertext — readable original data, and its encrypted, unreadable form.
  • Key — the secret value controlling an encryption/decryption operation.
  • Encoding — a reversible data format transformation with no secrecy property.
  • Avalanche effect — a tiny input change producing a drastically different hash output.

Recap

  • Encoding, encryption, and hashing are three genuinely different tools, distinguished by whether a secret is involved and whether the transformation is meant to be reversed.
  • Encoding (like Base64) provides zero confidentiality — it's a format change, not protection.
  • Encryption is reversible only with the correct key; hashing is deliberately one-way, with no key to recover the original at all.
  • This distinction underlies password storage (hash, never encrypt), data confidentiality (encrypt), and data transmission formats (encode) throughout the rest of this course.

References

Next up → Symmetric Encryption