Encryption

📘 Learn Encryption from zero

Start from the problem. You want to send a secret note across a crowded room where anyone can read whatever passes by. Write it in plain English and everyone sees it. Encryption is scrambling that note with a rule so only someone who knows the rule can unscramble it.

Analogy — the locked box. Picture a box with a padlock. Symmetric encryption uses one key that both locks and unlocks: fast and simple, but you and your friend must already share that one key — and handing it across the crowded room risks someone copying it. Asymmetric encryption solves this with two matched keys. Your friend publishes an open padlock (the public key) anyone can snap shut, but only their private key reopens it. You lock your note with their public padlock; only they can open it.

Worked example — how HTTPS (TLS 1.3) works. Your browser connects to a bank. (1) The bank sends a certificate containing its public key; the browser checks a Certificate Authority's signature to confirm it's really the bank. (2) Both sides run an ephemeral Diffie-Hellman key exchange — each sends a fresh, single-use public value, and from these they independently derive the same shared symmetric key without ever transmitting it. The bank's certificate key is used to sign its half so an attacker can't impersonate it. (3) The whole conversation then runs on fast symmetric AES-GCM. This is the hybrid model: asymmetric crypto only to authenticate and agree on a key, fast symmetric crypto for bulk traffic.

Key insight: because the session key is derived from ephemeral keys that are thrown away, even stealing the bank's long-term private key later can't decrypt past traffic — this is forward secrecy, and it's why modern TLS dropped the older "encrypt the session key with the server's RSA key" approach. Confidentiality always reduces to who holds the key, and for how long — design the key's lifecycle, not just the algorithm.

✨ Added by the guide to build intuition — not from the source course.

🎯 Guided practice

1. Easy — "Store user passwords." A candidate says "encrypt the passwords with AES." Step 1: ask what operation you ever need — you only need to verify a login, never to recover the original password. Step 2: recall encryption is reversible (a leaked key exposes every password), while a hash is one-way. Step 3: choose a slow, salted password hash (bcrypt, scrypt, argon2) — the per-user salt defeats precomputed rainbow tables and stops two identical passwords sharing a hash, the deliberate slowness (configurable work factor) throttles brute force. Step 4: on login, hash the input with the stored salt and compare. Pattern learned: match the tool to the operation — if you never decrypt, hash; encrypt only when you must read the plaintext back.
2. Medium — "Let users send each other private messages; the company should never read them." Step 1: parse the constraint — "company should never read them" rules out server-side encryption alone, because if the server holds the key, the server can decrypt. This forces end-to-end encryption. Step 2: keys live only on user devices. Each user generates a keypair; the public key uploads to a server directory, the private key never leaves the device. Step 3: apply the hybrid pattern — encrypt the message body with a fresh random symmetric key (fast AES-GCM), then encrypt that small symmetric key with the recipient's public key. The server stores and relays only ciphertext. Step 4: the recipient uses their private key to unwrap the symmetric key, then decrypts the body. Step 5: name the trade-offs — server-side search and message recovery become impossible (lost device = lost history unless keys are backed up), and you need key verification (safety numbers / fingerprints) to stop a man-in-the-middle swapping public keys, since the server hands out the keys. Pattern learned: "who must be unable to read this?" decides where keys live, and that location dictates the architecture.

✨ Added by the guide — work these before the full problem set.