Cryptography for Practitioners

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Cryptography is the math that makes confidentiality and integrity possible — and it is everywhere: every HTTPS connection, every stored password, every signed update. But here’s the practitioner’s truth: you will almost never break cryptography, and you must never invent it. What you will do constantly is spot it being misused. This page teaches you to use crypto correctly and recognize when others haven’t.

Part 1: The Problem

Cryptography intimidates people, so they treat it as a black box — and black boxes get misused. The real-world pattern is striking: the underlying algorithms (AES, RSA, SHA-256) are battle-tested and effectively unbreakable when used properly. Almost every crypto-related breach is not broken math — it’s crypto applied wrong: passwords stored with the wrong function, encryption used where signing was needed, keys left lying around, outdated algorithms still in service.

So you don’t need to be a cryptographer. You need to understand what each tool does, pick the right one, and recognize misuse. That’s this section.

Part 2: The Concept — Encryption (Keeping Secrets)

Encryption scrambles readable data (plaintext) into unreadable data (ciphertext) using an algorithm and a key. With the correct key you can reverse it (decrypt); without the key, the ciphertext is useless noise.

The critical principle — Kerckhoffs’s principle: the security must rest entirely in the key, not in keeping the algorithm secret. Good crypto algorithms are public, published, and studied by everyone. The secret is the key, only the key. “Secret homemade algorithm” is a giant red flag, not a feature.

There are two families of encryption.

Symmetric encryption — one shared key. The same key both encrypts and decrypts. Fast and ideal for bulk data. The catch: both parties need the same key, so how do you share the key securely in the first place? (The standard here is AES.)

   plaintext ──[encrypt with KEY]──► ciphertext
   ciphertext ──[decrypt with KEY]──► plaintext
              same key both ways

Asymmetric encryption — a key pair. Each party has two mathematically linked keys: a public key (shared with everyone) and a private key (kept absolutely secret). Anything encrypted with the public key can only be decrypted with the matching private key.

   Anyone ──[encrypt with your PUBLIC key]──► ciphertext
   Only you ──[decrypt with your PRIVATE key]──► plaintext

This elegantly solves key-sharing: people can send you secrets using your public key without any shared secret existing beforehand. It’s slower than symmetric, so in practice systems combine them — asymmetric to safely exchange a symmetric key, then fast symmetric encryption for the actual data. (That combination is exactly what the TLS handshake does — see Part 5. The standard here is RSA, and increasingly elliptic-curve crypto.)

Part 3: The Concept — Hashing (Verifying, Not Hiding)

Hashing is constantly confused with encryption. They are fundamentally different, and the difference matters enormously.

A hash function takes any input and produces a fixed-size string (the hash or digest). Its defining property: it is one-way. You cannot reverse a hash back into the original input. (The standard here is the SHA-2 family, e.g. SHA-256.)

   ENCRYPTION  →  two-way:  plaintext ⇄ ciphertext   (reversible with key)
   HASHING     →  one-way:  input → hash             (NOT reversible)

Properties of a good hash function:

• Deterministic — the same input always gives the same hash.
• One-way — you can’t compute the input from the hash.
• Avalanche effect — change one character of input and the hash changes completely.
• Collision-resistant — it’s infeasible to find two inputs with the same hash.

What hashing is for: verification, not secrecy.

• Integrity checking — hash a file before and after transfer; if the hashes match, it wasn’t altered.
• Password storage — see Part 4; this is the big one.

🔑 Encryption is for confidentiality (keep data secret, then get it back). Hashing is for integrity (prove data is unchanged; never get it back). Mixing these up causes real, common vulnerabilities.

Part 4: Password Storage — Where Beginners Go Wrong

A web app must check your password at login — but it must never store the actual password. If the database leaks (and databases leak), stored passwords mean every account is instantly compromised, on that site and everywhere users reused that password.

The progression of how to do it, from terrible to correct:

❌ Plaintext. Store the password as-is. Catastrophic — a database leak exposes everything immediately.

❌ Plain hashing. Store SHA-256(password). Better, but attackers precompute hashes of millions of common passwords (rainbow tables) and simply look yours up. Identical passwords also produce identical hashes — visible in the leaked data.

⚠️ Salted hashing. Add a unique random value — a salt — to each password before hashing, and store the salt alongside. Now identical passwords get different hashes, and precomputed tables are useless. Necessary, but still not enough on its own.

✅ Salted hashing with a slow, purpose-built password-hashing function. Use a function designed for passwords — deliberately slow and resource-intensive — such as bcrypt, scrypt, or Argon2. General hashes like SHA-256 are built to be fast, which helps an attacker guess billions per second. Password-hashing functions are deliberately slow, making mass guessing impractical, and they handle salting for you.

   login: user types password
        → add the stored unique SALT
        → run a SLOW password-hash (bcrypt / Argon2)
        → compare result to the stored hash
   The real password is never stored, anywhere.

This single topic — “how are passwords stored?” — is one of the most common real findings in security assessments. Knowing the correct answer makes you immediately useful.

Part 5: Digital Signatures and TLS — Crypto You Use Daily

Digital signatures — proving authenticity and integrity. Asymmetric keys work in reverse too: sign something with your private key, and anyone can verify it with your public key. Since only you hold the private key, a valid signature proves you produced it (authenticity) and that it wasn’t altered afterward (integrity). This is how software updates prove they really came from the vendor.

TLS — all of this, working together, on every HTTPS connection. Section 0.3 promised a closer look at the HTTPS handshake. Here it is, in plain terms:

1. Browser connects to the server.
2. Server presents its CERTIFICATE — its public key, plus a
   signature from a trusted Certificate Authority vouching
   for its identity.  → solves AUTHENTICATION
3. Browser verifies that certificate's signature chain.
4. Using ASYMMETRIC crypto, the two sides securely agree on a
   shared SYMMETRIC session key.   → solves KEY EXCHANGE
5. All further traffic uses fast SYMMETRIC encryption with
   that session key.   → solves CONFIDENTIALITY + INTEGRITY

Every concept from Parts 2–5 appears here: symmetric and asymmetric encryption, hashing, signatures, certificates. The padlock in your browser means this whole dance completed successfully.

Part 6: How Crypto Actually Fails in the Real World

Since you’ll be finding crypto problems, here are the misuse patterns that come up again and again — none of them “broken math”:

• Wrong tool. Passwords stored with fast hashes (or, horrifyingly, encrypted-but-reversible, or plaintext) instead of a slow password-hash.
• Outdated algorithms. MD5 and SHA-1 are broken for security use; old protocol versions have known weaknesses. Still found in production constantly.
• Homemade crypto. Someone invented their own algorithm or scheme. It is, essentially without exception, weak. Never roll your own crypto.
• Key mismanagement. Encryption keys hard-coded in source code, committed to public repositories, or shipped inside the app. The math is perfect; the key is on GitHub.
• Missing encryption. Sensitive data sent over plain HTTP, or stored unencrypted “in transit” or “at rest.” Often the simplest finding of all.
• Bad randomness. Crypto needs unpredictable random numbers. Using a predictable random source for keys or tokens undermines everything built on them.

The takeaway: as a practitioner you use well-established crypto libraries correctly and you hunt for these misuse patterns. You don’t break AES, and you certainly don’t write your own.

📓 Key Terms

🧪 Hands-On Lab

Task 1 — See hashing’s properties. In a terminal:

echo -n "password123" | sha256sum
echo -n "password124" | sha256sum

Compare the two hashes — one character changed, yet the outputs are completely different. That’s the avalanche effect. Run the first command again: identical output every time — that’s determinism.

Task 2 — Witness the salt effect. Hash the word password on its own. Then hash password with a made-up salt appended (passwordX7g2k). Different hashes. Now imagine every user gets a different salt — identical passwords no longer look identical in the database, and precomputed tables are worthless.

Task 3 — Crack weak vs strong, conceptually. Read about how password-cracking tools (e.g. Hashcat, John the Ripper) work. Note why a fast hash like raw SHA-256 lets attackers test billions of guesses per second, while a slow function like bcrypt or Argon2 throttles them to a crawl. You don’t need to crack anything here — understand the speed difference.

Task 4 — Inspect a real certificate. Revisit the certificate task from 0.3, now with new eyes. Find: who issued it (the Certificate Authority), what identity it vouches for, its validity dates, and the public key. Connect each field to Part 5.

Task 5 — Spot the misuse. For each scenario, name the Part 6 misuse pattern:

• A login system stores md5(password) with no salt. → Outdated algorithm + plain hashing.
• A developer’s public repo contains SECRET_KEY = "...". → Key mismanagement.
• An internal API sends login credentials over plain HTTP. → Missing encryption.
• A startup proudly advertises its “proprietary encryption.” → Homemade crypto.

⚠️ Common Mistakes

• Confusing hashing and encryption. Encryption is reversible (with the key) and is for secrecy; hashing is one-way and is for verification. This confusion causes real bugs — e.g. “encrypting” passwords so they can be decrypted later.
• Storing passwords with fast hashes. SHA-256 is excellent for integrity, wrong for passwords. Use bcrypt, scrypt, or Argon2 — slow, salted, purpose-built.
• Rolling your own crypto. Homemade algorithms are essentially always weak. Use established, audited libraries — never invent.
• Treating the algorithm as the secret. Per Kerckhoffs’s principle, only the key is secret. A “secret algorithm” is a warning sign.
• Forgetting “at rest” and “in transit.” Data needs protection both while moving across the network and while sitting in storage. Beginners secure one and forget the other.

✅ Recap & What’s Next

• Encryption is reversible and protects confidentiality; hashing is one-way and protects integrity — never confuse them.
• Passwords must be stored salted and run through a slow, purpose-built password-hashing function (bcrypt/scrypt/Argon2) — never plaintext, never a fast hash alone.
• You will not break good cryptography; you will spot its misuse — wrong tool, outdated algorithms, homemade schemes, mismanaged keys, missing encryption.

Next (1.4): Crypto proves who someone is and protects what they send. Next we examine the systems that decide who someone is and what they’re allowed to do — authentication and authorization, the most-attacked machinery in any application.