No. 04 — Lab 01
Bob & Amaka
tampered
Bob writes a 300-word message and records its SHA-256 hash. Amaka intercepts the message and changes one character. The hash of her version has almost nothing in common with Bob's.
01 — Before
Bob's message
A 300-word message on a topic of my choice: why unpatched software gets breached. The highlighted word is the one Amaka goes after.
Most breaches do not start with a clever new attack. They start with a known weakness that nobody fixed. When a vendor publishes a security update, it also tells the world exactly where the old version was broken. Attackers read those notes as carefully as defenders do, and they build working exploits within days. Every system that runs the old version after that point is a target with a published map to the door. This is why patching is a race, and why the winner is decided by routine rather than skill. A good patching routine starts with knowing what you own. You cannot update a server that nobody remembers, a plugin that was installed years ago, or a router in a cupboard that came with the office. Keep an inventory of every system, its version, and who is responsible for it. Next, rank the updates by risk. A flaw that lets a stranger run code over the internet needs fixing within 7 days, while a low risk bug in an internal tool can wait for the next maintenance window. Test the fix on a copy first, because an update that breaks the business creates its own kind of damage, but do not let testing turn into delay. Turn on automatic updates wherever the risk of a bad update is smaller than the risk of an old one, and check that they ran. Finally, measure the result. Track how long it takes from the day a fix is released to the day it is installed everywhere. If that number keeps shrinking, the organisation is getting safer. If it keeps growing, no firewall or antivirus product will make up for it. Security is rarely about stopping the perfect attack. It is about being too well maintained to be the easiest victim.
ebd64f158907aaf282b37b1d615f438049f0453828662ab1b48f52e8b70e2d70
02 — The disruption
Amaka's change
Amaka changes the word 7 to 70. That is a single added character, and it turns "fix critical flaws within 7 days" into advice that sounds almost the same but is ten times too slow. The message is still 300 words long.
Show Amaka's full version
Most breaches do not start with a clever new attack. They start with a known weakness that nobody fixed. When a vendor publishes a security update, it also tells the world exactly where the old version was broken. Attackers read those notes as carefully as defenders do, and they build working exploits within days. Every system that runs the old version after that point is a target with a published map to the door. This is why patching is a race, and why the winner is decided by routine rather than skill. A good patching routine starts with knowing what you own. You cannot update a server that nobody remembers, a plugin that was installed years ago, or a router in a cupboard that came with the office. Keep an inventory of every system, its version, and who is responsible for it. Next, rank the updates by risk. A flaw that lets a stranger run code over the internet needs fixing within 70 days, while a low risk bug in an internal tool can wait for the next maintenance window. Test the fix on a copy first, because an update that breaks the business creates its own kind of damage, but do not let testing turn into delay. Turn on automatic updates wherever the risk of a bad update is smaller than the risk of an old one, and check that they ran. Finally, measure the result. Track how long it takes from the day a fix is released to the day it is installed everywhere. If that number keeps shrinking, the organisation is getting safer. If it keeps growing, no firewall or antivirus product will make up for it. Security is rarely about stopping the perfect attack. It is about being too well maintained to be the easiest victim.
1e6e124711571443629dfbc07a431a889ee8acfb68276c62f6c584b8aa568593
03 — Result
One character, a different fingerprint
58 of the 64 hash characters changed, and 114 of the 256 bits flipped. A strong hash function behaves like this on purpose: flip about half the bits for even the smallest change. This is the avalanche effect. It means Amaka cannot nudge the message and keep a similar-looking hash.
What the hash gives Bob: integrity. If the hash he published no longer matches the message the receiver holds, the message was changed.
What it does not give him: protection. If Amaka can replace both the message and the hash, nobody notices. A hash proves a change happened only when the hash itself is safe. Fixing that takes a secret key, through an HMAC or a digital signature, which is where the encryption lab goes next.
04 — Verify it yourself
Do not trust my numbers
Download both files, then hash them with any of these commands. The files are plain ASCII text, so every tool gives the same answer.