🔐 07-01: Why Cryptography Matters¶
📌 The Problem: Networks Were Not Built to Keep Secrets¶
Every protocol you've studied so far in this course — ARP, IP, TCP, DNS — was designed to move data efficiently, not to hide it. By default, when your computer sends a packet across a network, that packet is plaintext: readable by anyone who can see it.
You've already seen what happens when that trust is abused:
- In Module 03, an attacker running ARP spoofing can position themselves between you and your router, silently reading (or altering) every packet you send — a man-in-the-middle (MITM) attack (see 03-05: MITM Attacks & Defenses).
- In Module 06, an attacker performing DNS cache poisoning can lie about which IP address a domain name maps to, redirecting you to a malicious server without you noticing.
💡 In both cases, the underlying problem is the same: the protocol has no way to tell truth from lies. Nothing in plain IP, TCP, or DNS stops an attacker from reading your data, changing it in transit, or impersonating someone else — because none of these protocols were built to verify anything.
Cryptography is the toolbox that fixes this. It doesn't change how packets are routed — it changes what's inside them, so that even if an attacker can see or touch every packet, they still can't do anything useful with them.
🔺 The Three Goals of Cryptography¶
Recall the CIA triad from 01-01: What Is Network Security?: Confidentiality, Integrity, and Availability. Cryptography is the primary tool for delivering the first two of these across a network, plus a third property that's closely related to integrity:
| Goal | Question It Answers | Network Example |
|---|---|---|
| Confidentiality | "Can anyone else read this?" | Encrypting a login form so a Wi-Fi sniffer sees only ciphertext, not your password |
| Integrity | "Was this modified in transit?" | Detecting that an attacker altered a bank transfer amount mid-flight |
| Authenticity | "Is this really from who it claims to be from?" | Proving a software update really came from the vendor, not an attacker |
💡 Availability, the third leg of the CIA triad, is mostly not solved by cryptography — it's solved by redundancy, rate-limiting, and capacity planning (see Module 04's coverage of flooding attacks). Cryptography's job is confidentiality, integrity, and authenticity.
Why All Three Matter Separately¶
It's tempting to think "encrypted = secure," but the three goals are independent, and a real system needs to reason about each one on its own:
- You can have confidentiality without integrity: an attacker who can't read your encrypted message might still be able to flip bits in it, corrupting it in a predictable way, without you noticing until it's too late.
- You can have integrity without confidentiality: a message can be signed (tamper-evident) while still being fully readable by everyone — that's fine for a public software update, but not for a password.
- You can have authenticity without confidentiality: you can prove who sent a message without hiding what it says.
A well-designed protocol like TLS (Module 09) explicitly provides all three, using different cryptographic tools for each — which is exactly why you need to understand each tool individually before you can understand TLS as a whole.
🧭 Roadmap for This Module¶
This module builds cryptography from the ground up, in the order each concept depends on the last:
| Lesson | Topic | Provides |
|---|---|---|
| 07-02: Symmetric Encryption Basics | Symmetric encryption fundamentals | Confidentiality (shared-key model) |
| 07-03: AES & Block Cipher Modes | AES and block cipher modes | Real-world confidentiality + integrity |
| 07-04: Asymmetric Encryption (RSA) | Asymmetric encryption (public-key cryptography) / RSA | Confidentiality without pre-shared secrets |
| 07-05: Diffie-Hellman Key Exchange | Diffie-Hellman key exchange | Solves the key-distribution problem |
| 07-06: Hashing & Message Integrity | Hashing and HMAC | Integrity |
| 07-07: Digital Signatures | Digital signatures | Authenticity + integrity |
| 07-08: Digital Certificates & PKI | Certificates and PKI | Trust — proving whose key you're using |
💡 By the end of this module, you'll have every building block needed to understand why TLS/SSL (Module 09) is built the way it is — TLS is essentially "all of these primitives, combined in the right order, to secure a live connection." VPN/IPsec (Module 08) reuses the exact same primitives for a different purpose: securing traffic between networks instead of between a browser and a server.
📌 Key Takeaways¶
- Network protocols like ARP, IP, TCP, and DNS were never designed to keep secrets or verify truth — cryptography is what adds those properties on top.
- MITM attacks (Module 03) and DNS cache poisoning (Module 06) both succeed because the underlying protocols cannot distinguish a legitimate message from a forged one; cryptography closes that gap.
- Cryptography delivers three distinct goals: confidentiality (nobody else can read it), integrity (nobody tampered with it), and authenticity (it really came from who it claims to).
- These three goals are independent — a system can have some without the others, so real protocols must deliberately provide all three.
- Availability, the third CIA triad property, is generally not solved by cryptography — it's solved by redundancy and capacity.
- This module builds up from symmetric encryption, through asymmetric encryption and key exchange, to hashing, signatures, and certificates — each lesson depends on the ones before it.
- Everything in this module is foundational for Module 09 (TLS/SSL) and Module 08 (VPN/IPsec), which combine these primitives into real-world protocols.