Encryption

Your repo crossed the public internet unread by every router along the way — because of a padlock icon and one mathematically stubborn idea from the 1970s. This is the reference for symmetric vs asymmetric keys, the TLS handshake, hashes, and every phrasing of the question the exam uses.

Symmetric — one shared key

The same key encrypts and decrypts. Fast, simple, and the cipher you have already built by hand (Caesar: shift letters by 3). Its fatal flaw is not strength — it is key distribution: to agree on a shared key you already need a private channel, and the public internet never offered one.

message + key → ciphertext  →  ciphertext + key → message

CAT  → (+3) → FDW  →  FDW  → (−3) → CAT

Caesar dies not to brute force but to the statistics of language — frequency analysis. The most common letters in English are ETAOIN; match their ciphertext patterns and the key falls out. Every real symmetric cipher since scrambles the pattern, but the lesson remains: a cipher that preserves any structure is a puzzle, not a lock.

Asymmetric — the public pair

The breakthrough: generate a KEY PAIR where one key encrypts and only the other decrypts. You publish the PUBLIC key (literally — on your website, in a certificate); you keep the PRIVATE key secret. Anyone can lock a message to you; nobody but you can open it. Publishing the lock reveals nothing about the key — that asymmetry rests on one math fact: multiplying two huge primes is easy, but factoring their product back into those primes is intractable for any computer you can buy.

	Symmetric (e.g. AES)	Asymmetric (e.g. RSA)
Keys	One shared secret	Public + private pair
Speed	Very fast	Slow
Solves	Bulk encryption	Key exchange + identity
Struggles with	Getting the key there	Volume

TLS — using both, for the best of both

HTTPS is the two working together. The asymmetric part builds trust once per session; the symmetric part does the actual work. The handshake, in six lines:

1. browser → server:          "hello"
2. server → browser:          certificate + public key
3. browser verifies the certificate against a trusted authority
4. browser:                   generates random session key,
                              encrypts it with the server's PUBLIC key
5. server:                    decrypts it with its PRIVATE key
                              (the only being that can)
6. both sides:                switch to fast symmetric, session key only

Step 3 is what "certificate" means: a third party vouches that this public key really belongs to github.com. Without that verification, anyone on your wifi could impersonate the site and hand you THEIR key — the man-in-the-middle attack. When your browser says a certificate is invalid, step 3 failed, and the correct move is to close the tab, not click through.

Hashing — encryption's cousin that is NOT encryption

A hash is a one-way fingerprint: any input becomes a fixed-size output, and no reasonable path leads back. password123 → ef92b778bafe.... There is no key because there is no decryption — login works by hashing what you type and comparing fingerprints. Salting (mixing a random per-user value in before hashing) makes every stored hash different even for identical passwords, defeating the precomputed-table attack. The exam phrasing to know: a hash provides integrity (did this change?) and password storage, never secrecy.

The exam-question shapes

• "Which is true of public key encryption?" — the public key cannot decrypt what it encrypted; only the private key can
• "Why are symmetric and asymmetric EACH used in a secure transaction?" — asymmetric to agree on identity and exchange a session key; symmetric for the fast bulk data
• "Lossy" trap: encryption is not compression (9.3) — nothing is sacrificed, everything is restored
• "A login system stores hashes of passwords" — why? So the service itself never possesses the passwords; a stolen database yields fingerprints, not secrets
• "What does a certificate prove?" — that the public key belongs to the named party, per a trusted authority

What can break it (and what cannot)

• Key in the lockbox with the treasure: your game encrypts saves with a key shipped inside the game. Every player IS the holder of the key — this is obfuscation, not security, and it is why client-side anti-cheat fails (9.8's leaderboard lesson: the client can lie; the server must verify)
• Quantum: if factoring huge numbers becomes easy, asymmetric crypto breaks (symmetric mostly survives) — which is why standards are migrating to post-quantum algorithms now
• Implementation bugs, not math bugs: the algorithms are fine; the code around them (random number generation, certificate checking) is where real attacks happen

Where you meet crypto this year

• 9.9 — Encryption — the lesson (Caesar by hand, reading your own certificate)
• The Internet reference — the packets TLS wraps
• Unit 9 — the full data & systems map