// networking basics — module 07

Module 7 — Cryptography Fundamentals

Thesis: Crypto underpins passwords, HTTPS, SSH, signatures, and disk encryption. You don't need the math — but you absolutely must stop conflating three different things beginners constantly mix up: encoding, hashing, and encryption. "Is this encoded, hashed, or encrypted?" is a question you'll answer on the job daily, and getting it wrong wastes hours.

Prerequisite: Module 6 — How the Web Works (Because Everything Is Web Now) (you met base64 auth, TLS, and JWTs there and will now understand what they actually are).

7.1 The three things people confuse — get this crystal clear

Before anything else, burn this table into memory. These three are not variations of one idea — they have different purposes, different reversibility, and different roles.

• Encoding (Base64, hex, URL-encoding) is about representation, not secrecy. It's reversible by anyone, needs no key, and hides nothing. Base64 is not encryption. Say that ten times. Anyone can decode it in one step.
• Hashing (SHA-256) is one-way. You cannot reverse a hash back to its input. The same input always produces the same fixed-length output. It's for checking that data is unchanged and for storing passwords.
• Encryption is reversible only with a key. Without the key it's unreadable noise. This — and only this — provides confidentiality.

Almost every beginner mistake in crypto is calling one of these another. When you see a blob of unfamiliar characters, your first question is always: is this encoded, hashed, or encrypted? — because the answer tells you whether you can trivially reverse it (encoding), never reverse it (hashing), or reverse it only with a secret (encryption).

7.2 Encoding in practice

Encoding transforms data into another representation for transport or compatibility — never for secrecy.

• Base64 turns arbitrary binary into a safe set of 64 text characters (A–Z, a–z, 0–9, +, /), often ending in = padding. You'll see it everywhere: binary data embedded in text, tokens, email attachments, HTTP Basic auth (Module 6), and malware "obfuscating" its payload. Recognizing base64 on sight — and knowing it's trivially decodable — is a real skill.
• Hex represents each byte as two hex digits (0x41 = A). Ubiquitous in dumps, hashes, and low-level output.
• URL-encoding (%20 for space, %2F for /) makes text safe inside URLs (Module 6).

The security lesson: attackers frequently encode data to slip it past naive filters or to make it look scrambled. A defender who mistakes encoding for encryption thinks data is protected when it's one base64 -d away from plaintext.

7.3 Hashing in depth

A cryptographic hash function takes any input and produces a fixed-length digest. Its defining properties:

• Deterministic — same input always gives the same output.
• Fixed length — SHA-256 always outputs 256 bits, whether you hash one letter or a movie.
• One-way — infeasible to reverse the digest back to the input.
• Avalanche effect — change one bit of input and roughly half the output bits flip. Similar inputs give completely different hashes; there's no partial resemblance.
• Collision resistance — it should be infeasible to find two different inputs with the same hash.

Uses: integrity ("does this downloaded file match the published hash? then it wasn't tampered with or corrupted") and password storage (below).

Broken vs. sound: MD5 and SHA-1 are broken for security — practical collisions exist — so never rely on them to prove integrity or store passwords, though you'll still see them used for non-security checksums. The SHA-2 family (SHA-256, SHA-512) is the current workhorse; SHA-3 exists too.

Passwords: salting and slow hashes

You must never store passwords in plaintext. But naive hashing isn't enough either, because attackers precompute the hashes of common passwords in giant lookup tables (rainbow tables). Two defenses:

• Salt — a unique random value added to each password before hashing. Now the same password produces a different hash for every user, so precomputed tables are useless and identical passwords aren't visibly identical. Salting is non-negotiable.
• Slow / work-factor hashes — general hashes like SHA-256 are fast, which helps an attacker guess billions per second. Purpose-built password hashes (bcrypt, scrypt, Argon2, PBKDF2) are deliberately slow and tunable, so each guess costs real time. That turns a feasible crack into an infeasible one.

So: passwords should be stored salted and with a slow hash. Plain, unsalted, fast hashes (or worse, plaintext) are a jackpot for an attacker who steals the database — which is exactly the red/blue tension in §7.8.

7.4 Symmetric encryption

Symmetric encryption uses one shared key for both encryption and decryption. The standard is AES (Advanced Encryption Standard). It's fast and handles bulk data efficiently — which is why it does the actual heavy lifting in TLS, disk encryption, and VPNs.

Its one hard problem is the key-distribution problem: both parties need the same secret key, but how do you get that key to the other person securely over an insecure channel without an eavesdropper grabbing it? You can't just email it. This single problem is what asymmetric crypto was invented to solve.

   Symmetric:   [same key] 🔑 encrypts  ──►  ciphertext  ──►  [same key] 🔑 decrypts
                  Fast. But how did both sides get the shared key safely?

7.5 Asymmetric encryption

Asymmetric (public-key) encryption uses a key pair: a public key you can share with the world and a private key you guard absolutely. The magic is that they're mathematically linked so that:

• For confidentiality: anyone encrypts with your public key; only your private key can decrypt. So people can send you secrets without ever sharing a secret first — the key-distribution problem, solved.
• For signatures: you sign with your private key; anyone verifies with your public key. A valid signature proves the message came from the private-key holder and wasn't altered (integrity + non-repudiation from Module 0).

The common algorithms are RSA and ECC (elliptic curve — same job, smaller keys). Asymmetric crypto is slow and suited to small data, which sets up the hybrid design below.

   Encrypt for Bob:   [Bob's PUBLIC key] locks  ──►  only [Bob's PRIVATE key] unlocks
   Sign as Alice:     [Alice's PRIVATE key] signs ──► anyone verifies w/ [Alice's PUBLIC key]

This is the basis of SSH keys (you prove identity with your private key) and much more.

7.6 Hybrid systems — why the real world combines both

Symmetric is fast but can't safely share its key; asymmetric can safely establish a secret but is slow. So real systems use both, playing to each one's strength:

1. Use asymmetric crypto once, at the start, to securely agree on a fresh random symmetric key (called a session key).
2. Then use fast symmetric crypto (AES) for the bulk of the actual data.

This is exactly how TLS (HTTPS, Module 6) works: the slow public-key step happens once during setup to exchange a session key, then everything else is fast symmetric encryption. Best of both worlds.

7.7 PKI, certificates, and the TLS handshake

Asymmetric crypto lets you encrypt to a public key — but how do you know a public key really belongs to example.com and not an impostor who handed you theirs? That's the job of PKI (Public Key Infrastructure) and certificates.

• A certificate binds a public key to an identity (a domain name) and is signed by a Certificate Authority (CA) — a trusted third party.
• Your operating system and browser ship with a list of trusted root CAs. A certificate is trusted if it chains — via intermediate CAs — back to one of those roots. This is the chain of trust.
• So a certificate proves "a CA that your system trusts has vouched that this public key belongs to this domain." That's what stops an impostor from impersonating a site.

The TLS handshake (high level) ties §7.6 and this together: the server presents its certificate; your browser verifies it chains to a trusted CA and matches the domain; then the two sides use asymmetric crypto to agree on a session key; and the rest of the connection is fast symmetric encryption. That's the padlock from Module 6, mechanically. (This is also why a self-signed or expired certificate throws a warning — the chain of trust is broken.)

7.8 Where it all shows up

Everything in this module is load-bearing infrastructure you now recognize:

• HTTPS/TLS — hybrid crypto + certificates (Module 6).
• SSH keys — asymmetric identity.
• Signed software / updates — signatures prove authenticity.
• Encrypted disks — symmetric (AES) at scale.
• Password databases — salted, slow hashes.
• Base64 tokens — encoding, not protection.

7.9 → Red/Blue

Red teams crack weak or unsalted password hashes (fast, unsalted MD5/SHA is a gift), decode data that was merely encoded and mistaken for secret, and abuse weak or misconfigured crypto (expired certs, downgrade attacks, hardcoded keys). Blue teams enforce strong salted-slow hashing and modern TLS, validate certificates and watch for invalid ones, and — critically — spot when sensitive data is only encoded (not protected) or when broken algorithms (MD5/SHA-1/DES) are still in use. The single question "is this encoded, hashed, or encrypted?" drives decisions on both sides.

Lab 7

CyberChef (a browser tool) is ideal for these; echo/sha256sum/base64 on Linux work too. Stay in your lab / your own data.

1. Prove encoding is reversible and keyless. Base64-encode a string (echo -n 'hello' | base64), then decode it (echo -n 'aGVsbG8=' | base64 -d). No key was involved. Convince yourself: this hid nothing.

2. Watch the avalanche effect. Hash a word twice (echo -n 'password' | sha256sum) and confirm the output is identical both times (deterministic). Now change one letter (passwerd) and hash again — observe that the entire digest changes, with no resemblance to the first. Same length every time.

3. See why salt matters. Hash password and imagine an attacker with a precomputed table of common-password hashes — yours is in it. Now prepend a random salt and hash saltXYZ:password; note it's a totally different digest that no generic table contains. Explain in writing why per-user salts defeat precomputed attacks.

4. Inspect a real certificate. In your browser, click the padlock on an HTTPS site → view the certificate. Identify: who issued it (the CA), to whom it was issued, its validity dates, and the chain up to a trusted root. Connect each to §7.7.

5. One sentence each. Write, without notes, one sentence explaining when you'd use hashing, symmetric encryption, and asymmetric encryption. If any is fuzzy, re-read.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

1. Encoding vs. hashing vs. encryption: for each, is it reversible, does it need a key, and what is it for? Why is "Base64 is encryption" wrong?
2. List the defining properties of a cryptographic hash. What is the avalanche effect and collision resistance?
3. Why is a plain SHA-256 of a password not good enough? Explain salting and slow hashes and what each defeats.
4. What is the key-distribution problem, and which kind of crypto solves it?
5. In asymmetric crypto, which key encrypts and which decrypts for confidentiality? Which signs and which verifies? Why are those opposite?
6. Why do real systems (like TLS) use both symmetric and asymmetric crypto? Which does which job?
7. What does a certificate prove, and what is the chain of trust? Why does an expired or self-signed cert warn you?

And perform cold:

• Base64-encode then decode a string; hash a word and show the avalanche effect by changing one character.
• Open a real site's certificate and state its issuer, subject, and expiry.

When all of that is effortless: Module 8 — Operating Systems Under a Security Lens: Linux & Windows