Cyber Security

Cryptography and Defences

Every defence on this page has a specific, understandable reason it works, and understanding why is what turns "use a strong password" from advice you're told into something you can actually calculate for yourself.

Section 2

The Caesar cipher

The simplest possible cipher: shift every letter along the alphabet by a fixed amount. Type a message and pick a shift.

Shift amount: 7

Section 3

Why the Caesar cipher is trivially weak

There are only 25 possible shifts, ever. That means a computer (or even a patient human) can just try every single one and instantly spot which one reads as real English.

Controls

This message was encoded with a secret shift. Find it.

Section 4

Frequency analysis: cracking a harder cipher

A substitution cipher (each letter mapped to a completely different, random letter) has 26! possible keys, brute force genuinely is not realistic here. But English letters are not used equally often, and that pattern survives encryption.

Letter frequency: ciphertext (blue) vs typical English (green)

Controls

Section 5

Password strength: the maths made concrete

This is exactly the same combinatorics idea from earlier work, applied to something you actually use every day. Pick a password style and watch worst-case crack time explode.

Assumed attack speed

1 billion guesses per second, realistic for modern password-cracking hardware.

Exam tips

  • Length matters more than most people expect, adding characters multiplies the keyspace, it doesn't just add to it.
  • A longer, simpler password (like a random phrase) can genuinely beat a shorter, complex one.
Section 6

Symmetric encryption: one key, both directions

This is a real, working cipher, not an analogy. It uses XOR, the same logic gate from earlier, applied byte by byte between your message and a key. Type both in and watch it actually encrypt, then watch the exact same key decrypt it straight back.

Encrypted (shown as hex byte values, since XOR output isn't printable text)

Decrypted, using the exact same key

The problem this creates

Symmetric encryption is fast and simple, but both sides need the identical secret key before they can communicate at all. If you've never met the other person, for example buying something from a website you've never visited before, how do you agree on a secret key over a connection that might itself be intercepted? Sending the key itself would be exactly as risky as sending the unencrypted message. This exact problem is what asymmetric encryption solves.

Why real symmetric keys are so much longer

The toy XOR cipher above uses a short, guessable key. Real symmetric encryption (AES) uses 128 or 256-bit keys instead, using the exact same keyspace idea from the password section: a 256-bit key has 2256 possible values, so large that brute-forcing it would take vastly longer than the age of the universe, even at trillions of guesses per second.

Section 7

Asymmetric encryption: two different keys

The padlock analogy: imagine an open padlock anyone can snap shut (the public key), but only one specific physical key can open it again (the private key). You can hand out copies of the open padlock to the entire world. Nobody needs a shared secret in advance, they just lock their message with your public padlock, and only you can unlock it.

A real, working toy example (small numbers, so you can follow every step)

Proof of asymmetry

Exam tips

  • Symmetric: one shared key, fast, but requires safely exchanging that key first.
  • Asymmetric: two mathematically linked keys, solves the exchange problem, but is significantly slower to compute.
  • In practice HTTPS uses both: asymmetric encryption just to safely exchange a one-time symmetric key, then fast symmetric encryption for the actual data, the best of each.
  • Real RSA uses primes hundreds of digits long specifically so factoring n back into p and q is computationally infeasible, unlike this toy example where n=187 factors easily by hand.
Section 8

Hashing: not encryption, and not just for data structures

If you've seen hash tables elsewhere, you've seen a hash function used purely for speed, mapping data to array slots. This is a completely different use of the exact same idea: a one-way function used to protect passwords, where the entire point is that it cannot be reversed. Type something below, this is real SHA-256, computed genuinely in your browser, not a simulation.

computing...

Encryption vs hashing, the actual difference

EncryptionHashing
Reversible?Yes, with the right key (as you saw above)No, deliberately one-way, there is no key that reverses it
PurposeProtect data in transit or storage, while still needing it back laterVerify something without ever needing the original back, e.g. checking a password is correct without storing it
Real exampleHTTPS traffic, encrypted filesPassword storage, verifying a download hasn't been corrupted or tampered with
Section 9

Why hashed passwords still need a salt

Two users pick the exact same password. Watch what their stored hashes look like, first without a salt, then with one, and this time the salts themselves are genuinely random, generated fresh, not fixed demo values.

What a salt actually is

A salt is just a random string, generated using a cryptographically secure random number generator (not an ordinary "random" function, which can be predictable), a fresh one for every single password stored, never reused between users. It gets stuck onto the front of the password before hashing, then stored right alongside the resulting hash, in plain view, it isn't secret at all. Its job isn't to hide anything, it's purely to make sure identical passwords never produce identical hashes. Real systems typically use salts of 16 bytes (128 bits) or more, this demo uses a short one purely so it fits on screen.

Controls

Section 10

Rainbow tables: why salting defeats them

Attackers don't have to guess your password live. They can precompute the hash of every common password once, then just look up a stolen hash instantly. This table below is real, genuinely precomputed with the same SHA-256 used above.

Precomputed table (common passwords \u2192 their SHA-256 hash)

A stolen hash just appeared in a leaked database

Exam tips

  • A rainbow table is only useful against unsalted hashes, since it's built once and reused against every stolen hash.
  • Salting means the attacker would need a separate precomputed table per possible salt value, which, combined with a genuinely random salt, makes precomputation practically useless.
  • The salt itself is not secret, it's typically stored right alongside the hash. Its job isn't secrecy, it's making every password's hash unique even when the passwords match.
Section 11

Other defences

Cryptography is one layer. Real systems combine several defences, because no single one covers every threat from the previous page.

Section 12

Check your understanding