Scrambling data so attackers can't read or tamper with it. The three core ideas — symmetric, asymmetric, hashing — are fewer than most students think.
Three building blocks: Symmetric encryption — one secret key, used to both encrypt and decrypt. Fast. Used for bulk data. (AES is the standard.) Asymmetric encryption — a key pair: public and private. What one encrypts, only the other decrypts. Slower but solves key distribution. (RSA, ECC are standards.) Hashing — one-way function turning data into a fixed-size fingerprint. Can't be reversed. Used for integrity checks and password storage. (SHA-256 is the standard.)
Real systems (like HTTPS) combine all three — asymmetric to exchange a key, symmetric to encrypt traffic, hashes to detect tampering.
12.1 Why Cryptography Exists
Networks are fundamentally untrusted. Traffic passes through ISPs, routers, Wi-Fi radio waves, undersea cables — every step is a potential interception point. Cryptography solves this by making the data unreadable to anyone except the intended recipient, and making tampering detectable.
It gives you three things, cleanly mapped to the CIA triad:
Crypto primitive
CIA pillar protected
How
Encryption (symmetric or asymmetric)
Confidentiality
Data is scrambled; only key-holders can read it
Hashing
Integrity
Any change to data changes the hash, making tampering visible
Digital signatures (combines hash + asymmetric crypto)
Integrity + authenticity + non-repudiation
Proves who sent it AND that it wasn't modified
FOR THIS SUBJECT: You don't need to do any maths. You need to understand what each primitive does, when to use which, and how they combine in real systems. Exam questions ask you to apply these ideas, not to calculate modular exponents.
12.2 Symmetric Encryption — One Shared Secret
The classic form of encryption. Both parties have the same secret key. The sender uses it to encrypt, the receiver uses it to decrypt.
Symmetric encryption is fast and simple — but getting the key to the other party securely is the whole challenge.
Standard algorithm: AES (Advanced Encryption Standard), with 128-bit or 256-bit keys. AES-256 is the default for most modern applications. It's fast, well-studied, and considered unbreakable in practice.
Strengths:
Fast — can encrypt gigabytes per second on consumer hardware
Well understood; mathematically strong
Works for any data size
Weakness — the key distribution problem: Alice and Bob need the same key. How do they agree on it? They can't just send it over the network in plaintext (an attacker would grab it). Meeting in person to exchange keys doesn't scale to millions of users on the internet.
This is where asymmetric encryption enters.
REAL USES OF SYMMETRIC ENCRYPTION: Full-disk encryption (BitLocker, FileVault), encrypted backups, the bulk data transfer in HTTPS sessions, VPN tunnel data, Wi-Fi traffic encryption (WPA2/3 use AES). Anywhere large amounts of data need to move or be stored securely, symmetric encryption does the actual scrambling.
12.3 Asymmetric Encryption — Two Keys, Mathematically Linked
A counterintuitive idea that powers modern internet security: instead of one shared key, each party has a pair of mathematically related keys.
Public key — shared openly. Can be published on a website, printed on a business card. Everyone has it.
Private key — kept secret by the owner. Never shared.
The magic: what one key encrypts, only the other can decrypt. There's no way to derive the private key from the public key (given today's computing power).
Anyone can encrypt to Bob using his public key. Only Bob, with his private key, can decrypt. No prior secret exchange needed.
Standard algorithms: RSA (older, larger keys — 2048 or 4096 bits) and ECC (elliptic curve — smaller keys, faster, 256-bit ECC ≈ 3072-bit RSA in strength). Both are used widely; ECC is increasingly preferred for new systems.
Why it's slower: The math is much more intensive. Asymmetric encryption is ~1000× slower than symmetric per byte. So in practice, asymmetric crypto isn't used to encrypt bulk data — it's used to set up a shared symmetric key, and then symmetric encryption takes over.
Two uses of a key pair
The same key pair does two related but different jobs:
Goal
Which key is used to...
Result
Send a message only you can read
Encrypt with recipient's public key; they decrypt with their private key
Confidentiality
Prove you are the sender
Sign with your private key; anyone with your public key can verify
Authenticity + non-repudiation
TRAP: "You encrypt with the private key to sign it" — close, but imprecise for an exam. You sign by hashing the message, then encrypting the hash with your private key. The recipient hashes the message themselves, decrypts your signature using your public key, and compares. That's digital signature — and it combines hashing with asymmetric crypto. Covered in section 12.5.
12.4 Hashing — One-Way Fingerprints
Hashing is very different from encryption. It's a one-way function: easy to compute in one direction, effectively impossible in reverse.
You feed in any input (a password, a file, a message) and get back a fixed-length output — the hash. The same input always produces the same hash. Any tiny change to the input completely changes the hash.
Input
SHA-256 hash (first 16 hex chars)
"Hello World"
a591a6d40bf420...
"Hello World!"
7f83b1657ff1fc...
"hello world"
b94d27b9934d3e...
A single character difference, a completely different hash. This property — called the avalanche effect — is what makes hashes useful for detecting change.
Properties of a good hash function
Deterministic — same input always gives same output
One-way — computationally infeasible to recover the input from the hash
Collision-resistant — finding two different inputs that produce the same hash should be infeasible
Avalanche — small input changes produce dramatic output changes
Standard algorithms: SHA-256 (part of the SHA-2 family), SHA-3. Older algorithms like MD5 and SHA-1 are broken — collisions have been demonstrated. They should not be used in any security context, though they still appear in legacy systems.
What hashing is used for
Use
How
Integrity checks
Websites publish the SHA-256 hash of a file. You download the file and compute its hash. If they match, the file wasn't modified in transit.
Password storage
Instead of storing your password, servers store its hash. On login, they hash what you type and compare. If the database is stolen, attackers have hashes, not passwords.
Digital signatures
You sign a short hash rather than the whole message (since asymmetric crypto is slow). Covered below.
Blockchain / distributed ledgers
Each block links to the previous one by including its hash. Any tampering breaks the chain.
File deduplication
Cloud storage uses hashes to detect identical files and only store one copy.
Why password hashing needs salt
If every user's password is hashed the same way, attackers pre-compute hashes for common passwords (called rainbow tables) and match against stolen hash databases. Defence: salt. Each user gets a random unique string added to their password before hashing. So even if two users pick the same password, their stored hashes are different, and rainbow tables don't work.
Modern password-hashing functions (bcrypt, Argon2, scrypt) also deliberately run slowly — making brute-force attempts at cracking much harder even with stolen hashes.
EXAM-GRADE ANSWER for "how should passwords be stored?":
"Passwords should be stored as hashes using a modern, slow, salted algorithm such as bcrypt or Argon2. This ensures that (a) plain passwords are never stored, (b) identical passwords produce different hashes per user, and (c) brute-forcing stolen hashes is computationally expensive." Three clear points = full marks.
12.5 Digital Signatures — Combining Hashing and Asymmetric Crypto
A digital signature proves two things: this message came from the claimed sender, and the message hasn't been tampered with. It's how your browser knows a website's certificate is genuine.
Sign with your private key; verify with the sender's public key. Any tampering in transit breaks the verification.
What this achieves:
Authenticity — only the private-key holder could have produced this signature, so we know the sender
Integrity — if the message is changed in transit, the receiver's re-computed hash won't match the signed hash
Non-repudiation — the sender can't later deny sending it, since only they have the private key
Digital signatures are used to: sign software installers (so you know they're from the real vendor), verify email authenticity (DKIM from Chapter 6), prove certificate authenticity in HTTPS, sign blockchain transactions.
12.6 HTTPS / TLS — Crypto in Action
Everything above comes together in the TLS handshake — the protocol that secures HTTPS, and the most important practical use of cryptography you'll meet.
When your browser connects to https://instagram.com, here's what happens (simplified):
Client Hello. Browser sends "I want HTTPS. Here are the ciphers I support."
Server Hello + Certificate. Server replies with its chosen cipher and its certificate. The certificate contains the server's public key AND is digitally signed by a Certificate Authority (CA) that your browser trusts.
Certificate verification. Browser verifies the CA's signature on the certificate using the CA's public key (which came pre-installed in your browser/OS). If valid, the browser trusts that the public key really belongs to Instagram.
Key exchange. Browser and server agree on a symmetric session key — using asymmetric crypto to do so securely. Modern TLS 1.3 uses Diffie-Hellman key exchange with forward secrecy.
Encrypted session. From here on, all traffic is encrypted with the symmetric session key. Fast AES for bulk data; the asymmetric crypto was just used to set up the key.
A lot happens in ~200ms. Browsers do this thousands of times an hour, invisibly.
Why TLS uses both asymmetric and symmetric
Asymmetric crypto is great for key exchange (no prior secret needed) but slow. Symmetric crypto is fast but needs a shared key. TLS uses asymmetric to set up a shared symmetric key, then uses symmetric for everything else. Best of both worlds.
Certificate Authorities (CAs) and the trust chain
How does your browser know that the certificate Instagram sent really belongs to Instagram and wasn't forged by an attacker?
Your browser and OS come pre-loaded with the public keys of trusted Certificate Authorities (DigiCert, Let's Encrypt, Google Trust Services, and others). When Instagram got their certificate, a CA signed it — vouching for the fact that they verified Instagram controls that domain. Your browser verifies the CA signature using the CA's public key. If it checks out, you trust the certificate.
If a CA is compromised, the whole system's trust is shaken — which is why CAs are heavily scrutinised. Browser vendors can and do revoke trust in misbehaving CAs (Symantec, China CNNIC, Dutch DigiNotar have all been revoked at various times).
TRAP: "The certificate proves the website is safe" — no. The certificate proves the website controls the domain. A phishing site at paypal-login.net can get a valid certificate, because it genuinely controls paypal-login.net. HTTPS and valid certificates mean the connection is encrypted and you're talking to whoever owns that exact domain — not that the domain belongs to a legitimate business.
12.7 Forward Secrecy — A Modern Improvement
Old-style TLS used the server's long-lived private key to set up the symmetric session key. This meant that if someone recorded your encrypted traffic and later stole the server's private key (e.g., years later, via a breach), they could decrypt all that stored traffic.
Forward secrecy (also "Perfect Forward Secrecy") uses ephemeral key exchanges (Diffie-Hellman) so each session has its own unique keys that are thrown away afterwards. Even if the server's long-term private key is later compromised, past sessions stay secure.
Modern TLS 1.3 requires forward secrecy. WPA3 (Chapter 7) also provides it. It's an important defence against long-term passive surveillance.
12.8 End-to-End Encryption (E2EE)
Most encryption is in-transit (protects between you and the server) or at-rest (protects stored data). End-to-end encryption is stronger: only the two communicating parties can read the messages. Even the service provider running the infrastructure can't.
Service
E2EE?
Signal
Yes — the gold standard
WhatsApp
Yes (uses the Signal protocol)
iMessage
Yes (between Apple devices)
Facebook Messenger
Recently rolled out E2EE by default (2024)
Standard email
No — mail providers can read it. PGP/S-MIME add E2EE but adoption is rare
Google Meet / Zoom (default)
No — encrypted in transit but the provider can decrypt. E2EE modes available but not default.
THE POLITICAL DIMENSION: E2EE is a recurring policy flashpoint. Australian law enforcement and intelligence agencies have pushed for "lawful access" mechanisms — ways to decrypt messages with a warrant. Cryptographers have warned that any such backdoor weakens the protocol for everyone. The Australian TOLA (Telecommunications and Other Legislation Amendment) Act 2018 gives agencies powers to compel tech assistance in some circumstances. You may see this mentioned in Chapter 17 on ethics and law.
12.9 Quick Reference — When to Use What
Scenario
Use
Encrypt a large file for yourself
Symmetric (AES) — you have the key
Send secure data to someone you've never met
Asymmetric (encrypt with their public key)
Verify a downloaded file hasn't been tampered with
Hash (SHA-256) comparison
Prove a message really came from the claimed sender
Digital signature (hash + asymmetric)
Store user passwords
Hash with salt, using bcrypt/Argon2 — never encrypt, never plaintext
Secure a web connection
HTTPS / TLS (combines all three: asymmetric for key exchange, symmetric for bulk, hash for integrity)
Encrypted messaging
End-to-end encrypted app (Signal, WhatsApp)
Full disk encryption
Symmetric (AES) with a key derived from your password
12.10 Quiz Time
Why does HTTPS use both asymmetric AND symmetric encryption in the same connection?
Asymmetric encryption is used to securely exchange a shared key without requiring a prior secret. But it's computationally expensive — encrypting gigabytes of data with RSA would be painfully slow. Symmetric encryption (AES) is vastly faster per byte. So TLS uses asymmetric to negotiate a session key, then switches to symmetric to encrypt the actual traffic. This combines the key-distribution advantage of asymmetric with the speed of symmetric. In exam terms: the right tool for each job.
A system stores user passwords using MD5 with no salt. Explain the problems and how they should be fixed.
Three problems:
1. MD5 is cryptographically broken — collisions can be found in seconds. It's not a hash function suitable for security.
2. No salt means rainbow tables work — attackers pre-compute MD5 of common passwords and match instantly. Two users with the same password have the same hash.
3. MD5 is extremely fast — modern GPUs compute billions of MD5s per second. Even if it weren't broken, it's too fast for password use.
Fix: Migrate to bcrypt or Argon2 with a unique per-user salt. On each user's next login, re-hash their password with the new algorithm and replace the stored value. Old MD5 hashes can be left in place temporarily, but ideally force a password reset.
Explain how a digital signature provides non-repudiation.
A digital signature is created by hashing the message and encrypting the hash with the sender's private key. Only the sender possesses that private key. The recipient verifies by decrypting the signature with the sender's public key and comparing to their own hash of the message. Because the private key is (by definition) secret to the sender, no one else could have produced a valid signature. So the sender can't later claim "it wasn't me" — unless they claim their private key was stolen, which itself shifts liability in specific legal ways. Non-repudiation = strong proof of origin that can stand up legally. Used heavily in e-commerce, legal contracts, and software distribution.
A student says "I use HTTPS everywhere so I'm completely safe online." What's wrong with this claim?
HTTPS protects traffic in transit — no one between you and the server can read or modify it. It does NOT:
— Protect you from malicious websites themselves (a phishing site can use HTTPS)
— Protect you from malware you download over HTTPS
— Hide your metadata (which sites you visit, when, for how long)
— Protect stored data once it reaches the server
— Protect against compromised certificates from rogue CAs
— Protect you from being socially engineered, phished, or scammed.
HTTPS is necessary but not sufficient. True safety requires layered defences — good passwords + MFA, careful clicking, updated software, awareness of social engineering, and more.