Five hands-on terminal exercises covering MD5, SHA-256, batch verification, tamper detection, and HMAC authentication — the core tools for proving file integrity on Linux.
Generate the MD5 checksum of an ISO file and compare it against a known published hash. Understand why MD5 is no longer considered safe for security-critical verification.
Run md5sum against ubuntu-24.04.iso to generate a checksum. Compare the output against the published hash shown below.
MD5 produces a 128-bit (32 hex character) digest. In 1996 researchers demonstrated collision weaknesses. By 2004, full collision attacks were practical on commodity hardware — two different files can produce the same MD5 hash. This means an attacker can craft a malicious file with a matching MD5. Never use MD5 for security-critical integrity checks. It is only acceptable for detecting accidental corruption (bit rot) on trusted networks, where collision attacks are not a threat model.
Generate the SHA-256 checksum of the same ISO and compare it against Ubuntu's officially published hash. Understand why SHA-256 is the modern standard for download verification.
Run sha256sum against ubuntu-24.04.iso. The official published hash for Ubuntu 24.04 LTS desktop is shown in the output for comparison.
SHA-256 produces a 256-bit (64 hex character) digest — four times the bit length of MD5. No practical collision attack exists against SHA-256. The NSA Suite B standards mandated SHA-256 as the minimum for unclassified data. The Ubuntu project, Debian, Fedora, and virtually every major Linux distribution publish SHA256SUMS files alongside their ISOs for exactly this reason. For the highest assurance, also verify the GPG signature on the SHA256SUMS file itself — this proves the hash list was not tampered with in transit.
Use sha256sum -c to verify multiple files at once against a published SHA256SUMS manifest. This is the real-world workflow used when downloading Linux ISOs.
You downloaded ubuntu-24.04.iso and Ubuntu's official SHA256SUMS file. The -c flag reads each hash+filename pair from the manifest and checks them all automatically. Run the check command now.
OK means the computed hash matches the hash recorded in the manifest — the file arrived uncorrupted and unmodified. FAILED means they differ — either the download was corrupted in transit (partial transfer, bad media) or, in a worst case, the file was tampered with between the publisher and you. A FAILED result means you must discard the file and re-download. Never boot or deploy a FAILED ISO — you cannot trust its contents.
Hash a config file, simulate a single-byte modification, then re-hash to observe how completely the digest changes. This is the avalanche effect — the property that makes cryptographic hashes reliable tamper detectors.
You are a sysadmin who took a baseline hash of /etc/nginx/nginx.conf before deployment. After an incident alert, you want to check if the file was modified. Generate a fresh SHA-256 hash and compare it against the stored baseline to detect any tampering.
A cryptographic hash function is designed so that changing even a single bit in the input produces a completely different output — roughly half the output bits flip. This is the avalanche effect. Looking at the two hashes above, notice they share almost no characters in common, yet the files differed by only one byte. This property means you cannot reverse-engineer an input from a hash (one-way), and finding two different inputs with the same hash requires astronomical computation (collision resistance). These two properties are what make SHA-256 suitable as a tamper-detection primitive.
Use openssl dgst to compute an HMAC-SHA256 over a file using a shared secret. Understand the difference between a plain cryptographic hash and an authenticated hash, and when each belongs in your security design.
You are sending a configuration file to a remote server over an API. A plain SHA-256 hash proves the file was not corrupted, but does not prove who sent it. An HMAC ties the integrity proof to a shared secret — any party without the secret cannot produce a valid HMAC. Generate an HMAC-SHA256 for api-config.json using the secret key hexworth-secret-2024.
| Property | Plain Hash (SHA-256) | HMAC-SHA256 |
|---|---|---|
| Detects corruption | Yes | Yes |
| Requires shared secret | No | Yes |
| Proves sender identity | No — anyone can compute it | Yes — only parties with the secret |
| Resistant to length extension | No (SHA-256 vulnerable) | Yes — HMAC construction prevents it |
| Use cases | Download verification, deduplication, file change detection | API request signing, JWT validation, webhook signatures, message authentication |
| Linux command | sha256sum file |
openssl dgst -sha256 -hmac "key" file |
A lesser-known weakness of plain SHA-256 (and MD5, SHA-1) is the length extension attack. If you know H(secret || message) and the length of the secret, you can compute H(secret || message || extra_data) without knowing the secret. The HMAC construction — H(key XOR opad || H(key XOR ipad || message)) — eliminates this weakness by applying a second keyed hash over the inner result. This is why production API authentication always uses HMAC rather than a raw keyed hash.
Complete all five exercises to mark this lab finished and record your progress.