21.1 6 Lab Hashing Things Out

You're staring at a terminal. And the cursor blinks. You've just run sha256sum on two files that look identical — same name, same size, same everything — and the output doesn't match.

Welcome to hashing. Plus, it doesn't care what you think. It only cares about bits.

What Is Hashing

Hashing is the process of taking input data of any size — a password, a text file, a 50 GB disk image — and running it through a mathematical function that spits out a fixed-length string of characters. Sometimes it's called a digest. In practice, that output is the hash. Sometimes a fingerprint.

The same input always produces the same hash. Change one bit — flip a single 0 to a 1 — and the entire output changes. This is the avalanche effect, and it's not a bug. That said, unrecognizably. It's the whole point Simple, but easy to overlook..

Not Encryption. Not Encoding.

This trips people up constantly. Consider this: hashing isn't encryption. In real terms, encryption is two-way: you encrypt, you decrypt. Hashing is one-way. You get your data back. Day to day, you can't take a SHA-256 digest and reconstruct the original file. There's no "unhash" button. No reverse gear. That's not a limitation — it's a feature Turns out it matters..

Encoding? That's just representation. Base64, hex, URL encoding — these are reversible transformations. They don't provide security. They're just different ways to write the same bytes The details matter here. Worth knowing..

Hashing sits in its own category: irreversible, deterministic, fixed-length transformation Easy to understand, harder to ignore..

Why It Matters / Why People Care

You use hashing every day. Every single day.

When you log into a website, your password isn't stored in plain text (hopefully). That said, it's hashed. The server compares the hash of what you typed to the hash it has on file. Match? You're in. No match? Try again. The site never sees your actual password. If their database leaks, attackers get hashes — not passwords.

File integrity? If they match, the file wasn't corrupted — or tampered with — in transit. Could be a bad download. The site lists a SHA-256 checksum. If they don't, something's wrong. Could be a supply chain attack. You download an ISO. Consider this: same idea. You run the hash locally. Either way, you know Small thing, real impact..

Git uses hashes (SHA-1, moving to SHA-256) to identify commits. But every commit, every tree, every blob — all addressed by hash. That's how Git knows if history changed. That's how it stays distributed and trustworthy.

Blockchains? Each block contains the hash of the previous block. Change one transaction three blocks back, and every subsequent hash breaks. Hash chains. The math enforces immutability Not complicated — just consistent..

Digital signatures? Hash the message, encrypt the hash with your private key. So anyone with your public key can verify. On the flip side, they hash the message themselves, decrypt your signature, compare. Match means: you signed it, and it hasn't changed.

The Lab Context

In a typical networking or security lab — like the one numbered 21.1.6 in many curricula — you're not just reading about this. You're doing it. Here's the thing — you're generating hashes. Comparing them. Breaking things on purpose to see what breaks. That hands-on piece? That's where the concept clicks.

How It Works (or How to Do It)

Let's walk through what actually happens when you hash something. Even so, not the math — the mechanics. The stuff you'll touch in a lab.

The Algorithm Zoo

You'll see these names constantly:

• MD5 — 128-bit output. Fast. Broken. Collision attacks are trivial. Don't use it for security. Still fine for checksums on non-adversarial data (like verifying a download from a trusted mirror where you also verify GPG signatures).
• SHA-1 — 160-bit. Also broken for collision resistance. Git still uses it (with mitigations). TLS certificates stopped using it years ago.
• SHA-256 — 256-bit. Part of the SHA-2 family. Current workhorse. Used in TLS, Bitcoin, SSH, Linux package managers, you name it.
• SHA-3 — Different internal structure (Keccak). Not a replacement for SHA-2 — more of a hedge. Slow adoption.
• BLAKE2 / BLAKE3 — Faster than SHA-2, equally secure. Gaining traction in tools like b3sum, hashdeep, some language standard libraries.

In a lab, you'll probably use sha256sum, md5sum, maybe openssl dgst. Same idea, different flags Worth keeping that in mind. Worth knowing..

The Command Line Basics

# Hash a file
sha256sum ubuntu-22.04.iso

# Hash a string (note: echo adds a newline by default)
echo -n "hello" | sha256sum

# Compare two files
sha256sum file1.txt file2.txt

# Verify against a known checksum
echo "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  empty.txt" | sha256sum -c

That last one? That's the pattern you'll use constantly. The -c flag reads "hash filename" pairs and verifies them. Exit code 0 = match. Non-zero = mismatch.

What the Lab Actually Has You Do

A typical "hashing things out" lab walks you through:

1. Generate hashes for a set of known files. Maybe a text file, a binary, an image.
2. Modify one file — add a space, flip a byte with xxd or sed — and re-hash. Watch the output change completely.
3. Compare two "identical" files that differ by one invisible character (BOM, line ending, trailing space).
4. Verify a downloaded file against a published checksum.
5. Maybe — if it's a security-focused lab — demonstrate a collision with MD5 using fastcoll or similar tools. Show that two different files can have the same MD5 hash.

That last one is the "aha" moment. You see the breakage. Real files. Because of that, same hash. Not theoretical. Different content Most people skip this — try not to. Simple as that..

Hashing Passwords: A Different Beast

File hashing = fast. Password hashing = slow The details matter here..

This distinction matters enormously.

If you store passwords with SHA-256, an attacker with a GPU can try billions of guesses per second. They'll crack "Password123" in microseconds. They'll crack "Tr0ub4dor&3" in hours.

Password hashing algorithms — bcrypt, scrypt, Argon2, PBKDF2 — are designed to be slow. They use memory-hard or CPU-hard constructions. They take a "work factor" (cost parameter) that you tune so each hash takes ~100–300ms on your

Password hashing is fundamentally different from the file‑level digests described earlier. While a file hash is meant to be computed quickly so that users can verify integrity on the fly, a password hash must be deliberately expensive to thwart brute‑force attacks. The cost factor in algorithms such as bcrypt, scrypt, or Argon2 controls how many iterations (or how much memory) are required for each verification. By inflating the work factor, an attacker’s GPU or ASIC farm is forced to spend seconds — or even minutes — on a single guess, turning what would be a trivial crack into a prohibitive operation.

A second line of defense is the use of a unique salt for every password. Because the salt is stored in clear text, it does not secretly protect the password, but it ensures that identical passwords produce distinct hashes. The salt is a random value that is concatenated (or otherwise mixed) with the password before hashing. Without salts, identical passwords would map to the same hash, allowing an attacker to reuse pre‑computed tables (rainbow tables) to accelerate cracking. Modern password‑hashing schemes automatically incorporate the salt into the derived key, so the verification process can still locate the correct entry without exposing the raw password.

In practice, you’ll typically see a workflow that looks like this:

1. Generate a random salt (e.g., 16 bytes) using a cryptographically secure RNG.
2. Combine the salt with the password and feed the concatenated value into the chosen KDF.
3. Store both the salt and the resulting hash (often together in a single string) in your user database. The hash itself contains enough information about the parameters (algorithm name, cost factor, iteration count) that verification can be performed without additional metadata.
4. During login, retrieve the stored salt and parameters, recompute the hash with the supplied password, and compare the result using a constant‑time comparison routine to avoid timing leaks.

If you were to use a fast, generic hash like SHA‑256 for passwords, you would be vulnerable to offline dictionary attacks. An attacker who obtains the password database could simply feed millions of candidate passwords through the hash function on a modest GPU cluster, quickly finding matches. The slow, memory‑hard nature of modern KDFs dramatically raises the bar, making such attacks economically unfeasible for all but the most determined adversaries.

Beyond the algorithmic choices, consider the following operational guidelines:

• Set a sensible cost factor that balances response time for legitimate users with enough computational load to deter attackers. For bcrypt, a factor of 12 (equivalent to 2¹² rounds) is a common starting point on contemporary servers; for Argon2id, a memory cost of 64 MiB and a parallelism level of 2 often provides strong protection without noticeable latency.
• Rotate parameters over time. As hardware improves, the same cost factor may become too fast, so periodically increase the work factor and re‑hash passwords on the next successful login.
• Enforce strong password policies (minimum length, diversity, disallow common passwords) to reduce the effective size of the attack space, complementing the cryptographic safeguards.
• Avoid custom implementations. put to work well‑vetted libraries (e.g., libsodium, OpenBSD’s crypt(3), or language‑specific modules) that handle salting, encoding, and constant‑time verification correctly.

By marrying a dependable KDF with per‑user salts and diligent operational practices, you transform password storage from a trivial target into a resilient component of your security architecture.

Conclusion

Hashing serves two complementary purposes in the modern computing landscape. For data integrity, fast, deterministic digests such as SHA‑256 provide a practical way to detect accidental modifications, verify downloads, and check that files remain unchanged across transfers. The command‑line tools that ship with most Unix‑like systems make this process straightforward, and the underlying algorithms — while some are showing signs of age — remain secure when used with appropriate mitigations.

Conversely, password storage demands a fundamentally different approach. Plus, because the stakes are higher and the threat model includes offline attackers, the hashing process must be deliberately slowed and fortified with salts and memory‑hard parameters. Modern key‑stretching functions address the weaknesses of legacy algorithms like MD5 and SHA‑1, delivering a level of resistance that aligns with today’s computational capabilities.

When both use cases are understood and applied correctly, cryptographic hashes become a versatile building block: they safeguard the bits we transmit and store, while also protecting the secrets we entrust to systems. Mastering their proper use — whether through sha256sum for file verification or bcrypt for credential protection — is an essential skill for anyone working with Unix‑style environments, security tools, or software development pipelines Still holds up..