• What encryption is and why it's needed, especially on wireless networks
• How wireless networks create and use a "master key" from the SSID + password
• How wired networks handle encryption differently (left to individual apps, e.g. HTTPS)
• The difference between plaintext and ciphertext
• Symmetric encryption — one shared secret key for both encrypting and decrypting
• Asymmetric encryption — a public key and a private key working as a pair
• Why large keys make encryption almost impossible to crack by guessing

Think about sending a postcard versus sending a sealed letter. A postcard can be read by literally anyone who handles it along the way — the postman, anyone who picks it up if it falls, anyone at all. A sealed letter, on the other hand, only makes sense to the person who's allowed to open it.

Data travelling across a network is like a postcard by default — anyone who intercepts it can read it. Encryption is the process of scrambling that data into a meaningless jumble before it's sent, so that even if it's intercepted, it's useless without the key to unscramble it.

You might wonder: if encryption matters on any network, why do your notes single out wireless networks as needing it "more"? Here's the reasoning: on a wired network, data travels down a physical cable — to intercept it, someone would need to physically tap into that cable, which is difficult and risky. On a wireless network, data is broadcast through the air as radio waves in all directions. Anyone with the right equipment sitting nearby — in a car outside your house, in the next office, even in the flat next door — can pick up those radio waves without ever touching a cable. That's what makes interception so much easier on wireless networks, and why strong encryption is critical there.

Every wireless network has an SSID (Service Set Identifier) — that's just the network's name, the one you see in your list of available Wi-Fi networks. When you connect to a network, you enter the SSID (by picking it from the list) along with the network's password. Your device combines these two things to generate something called the master key.

Here's the crucial part: every device that connects using the same SSID and password gets an identical copy of that master key. It's not sent across the network as a separate message — each device independently calculates the same key from the same inputs (SSID + password), the same way two people following the same recipe end up with the same dish without ever showing each other the finished product.

Why does that last point matter so much? Because if the master key were ever transmitted, a hacker intercepting the network traffic could simply grab it and use it to decrypt everything else. Since it's never sent, an intercepted stream of ciphertext is just useless noise to anyone who doesn't already possess the key.

Wired networks are encrypted using the same basic principle as wireless ones — a master key is used to encrypt data, and the same key is used to decrypt it. So the underlying mechanism (a shared key scrambling and unscrambling data) doesn't change.

What does change is who decides to use encryption and how. On a wireless network, encryption is essentially baked into the connection itself via the SSID/password/protocol (like WPA2) — it's automatic. On a wired network, there's no equivalent "automatic" layer forcing encryption on all data. Instead, it's left to individual applications to decide whether and how to encrypt their own data.

The classic example you need to know is HTTPS (HyperText Transfer Protocol Secure) — the padlock icon you see in your browser's address bar. A website using HTTPS is an application-level decision to encrypt the data flowing between your browser and that website's server, even though the underlying wired (or wireless) network connection itself doesn't force this to happen.

Before we can properly compare symmetric and asymmetric encryption, you need three vocabulary pieces locked down cold, because examiners will test whether you use them precisely.

One thing that trips students up: keys can vary hugely in size, and they function a lot like passwords — the person (or algorithm) that holds the correct key is the only one who can unlock the data. A longer key isn't just "a bit better" — it's exponentially harder to guess, which we'll come back to below.

Symmetric encryption is when both the sender and the receiver are given an identical secret key, and that one single key is used both to encrypt the plaintext and to decrypt the ciphertext. It's called "symmetric" because both operations (locking and unlocking) use exactly the same key — like a single physical key that both locks and unlocks the same padlock.

The obvious weakness here: if a hacker ever gains access to that secret key, they can decrypt any intercepted data — game over, the whole system is compromised. This creates a real practical problem: how do you get the secret key safely to the other person in the first place, without sending it over the same network you're trying to protect (since that network isn't secure yet)?

Your notes give three real ways this "key distribution problem" gets solved:

• Verbally, in person — the two parties simply meet and tell each other the key directly.
• Standard postage mail — writing the key down and sending it the old-fashioned way, physically, rather than electronically.
• An algorithm calculating the key — both parties exchange some secret non-key information (not the key itself), and each side runs the same algorithm on that shared information to independently arrive at the identical key — this is essentially the same trick the wireless master key uses (SSID + password → same key on both ends, without sending the key itself).

Asymmetric encryption solves the key-distribution headache above by using two different keys that work as a pair:

• Public key — known to everyone. You can hand this out freely, publish it, put it on a website — it doesn't need to be kept secret.
• Private key — known only to the receiver. This one is never shared with anyone.

Both keys are needed to complete the full encrypt-then-decrypt process, but crucially, they're used by different people at different stages:

Step by step, using your notes' exact process:

1. Person A uses Person B's public key to encrypt their message.
2. Person A sends the resulting ciphertext over the network or internet.
3. Person B decrypts the message using their own secret private key.

This is the elegant part: because anyone can grab Person B's public key and use it to encrypt a message for them, there's no awkward "how do we secretly swap a key first" problem like there is with symmetric encryption. Only Person B's private key — which never leaves Person B — can undo the encryption. Even if a hacker intercepts the ciphertext and knows the public key, they still can't decrypt it, because encrypting and decrypting require different keys here.

Why Large Keys Matter

Keys aren't small — they're long binary strings, and the number of possible combinations grows explosively as key length increases. Your notes give a striking example: a key using just 100 bits generates 1,267,650,600,228,229,401,496,703,205,376 different possible combinations. That's over 1.2 nonillion possibilities — a number so large that even the fastest computers imaginable would take longer than the age of the universe to try every combination by brute force. This is exactly why large keys are described as near impossible for a hacker to guess.

• I can define encryption in my own words
• I can explain why wireless networks need encryption more urgently than wired ones
• I can explain how the wireless master key is generated from the SSID and password
• I know the master key is never transmitted across the network
• I can name WPA2 as a wireless security protocol
• I understand that wired encryption is left to individual applications, e.g. HTTPS
• I can correctly define plaintext, ciphertext, key, and algorithm
• I can explain symmetric encryption and its key-sharing weakness
• I can list the three ways a symmetric key can be shared safely
• I can explain asymmetric encryption and the public/private key roles
• I can walk through the three-step asymmetric encryption process (A encrypts, sends, B decrypts)
• I understand why large keys are near-impossible to guess
• I can compare symmetric and asymmetric encryption clearly