21.1 6 Lab Hashing Things Out

You're staring at a terminal. Worth adding: 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 Which is the point..

Welcome to hashing. On top of that, 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. Also, that output is the hash. Sometimes a fingerprint.

The same input always produces the same hash. That said, this is the avalanche effect, and it's not a bug. Day to day, unrecognizably. Plus, change one bit — flip a single 0 to a 1 — and the entire output changes. It's the whole point.

Not Encryption. Not Encoding.

This trips people up constantly. Hashing isn't encryption. Think about it: encryption is two-way: you encrypt, you decrypt. Also, you get your data back. Hashing is one-way. There's no "unhash" button. So no reverse gear. Also, you can't take a SHA-256 digest and reconstruct the original file. That's not a limitation — it's a feature Turns out it matters..

Encoding? Still, that's just representation. Because of that, base64, hex, URL encoding — these are reversible transformations. In real terms, they don't provide security. They're just different ways to write the same bytes Surprisingly effective..

Hashing sits in its own category: irreversible, deterministic, fixed-length transformation.

Why It Matters / Why People Care

You use hashing every day. Every single day It's one of those things that adds up..

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

Real talk — this step gets skipped all the time.

File integrity? You run the hash locally. Day to day, if they match, the file wasn't corrupted — or tampered with — in transit. The site lists a SHA-256 checksum. So naturally, could be a supply chain attack. If they don't, something's wrong. Same idea. Could be a bad download. In practice, you download an ISO. Either way, you know Nothing fancy..

People argue about this. Here's where I land on it.

Git uses hashes (SHA-1, moving to SHA-256) to identify commits. 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 The details matter here..

Blockchains? Hash chains. On top of that, each block contains the hash of the previous block. Change one transaction three blocks back, and every subsequent hash breaks. The math enforces immutability Worth keeping that in mind..

Digital signatures? Consider this: hash the message, encrypt the hash with your private key. Anyone with your public key can verify. Day to day, 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.That hands-on piece? 1.You're generating hashes. On the flip side, comparing them. On top of that, you're doing it. On top of that, 6 in many curricula — you're not just reading about this. Breaking things on purpose to see what breaks. That's where the concept clicks Took long enough..

How It Works (or How to Do It)

Let's walk through what actually happens when you hash something. In real terms, 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 Not complicated — just consistent. Practical, not theoretical..

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. Day to day, exit code 0 = match. Non-zero = mismatch Turns out it matters..

What the Lab Actually Has You Do

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

Generate hashes for a set of known files. Maybe a text file, a binary, an image.
Modify one file — add a space, flip a byte with xxd or sed — and re-hash. Watch the output change completely.
Compare two "identical" files that differ by one invisible character (BOM, line ending, trailing space).
Verify a downloaded file against a published checksum.
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. Same hash. Consider this: you see the breakage. Not theoretical. Real files. Different content No workaround needed..

Hashing Passwords: A Different Beast

File hashing = fast. Password hashing = slow.

This distinction matters enormously.

If you store passwords with SHA-256, an attacker with a GPU can try billions of guesses per second. Plus, 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. Still, 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. Even so, without salts, identical passwords would map to the same hash, allowing an attacker to reuse pre‑computed tables (rainbow tables) to accelerate cracking. The salt is a random value that is concatenated (or otherwise mixed) with the password before hashing. Because the salt is stored in clear text, it does not secretly protect the password, but it ensures that identical passwords produce distinct hashes. 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 Worth keeping that in mind..

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

Generate a random salt (e.g., 16 bytes) using a cryptographically secure RNG.
Combine the salt with the password and feed the concatenated value into the chosen KDF.
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.
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. On the flip side, 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 reliable 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 The details matter here..

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 confirm 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 That's the whole idea..

Counterintuitive, but true.

Conversely, password storage demands a fundamentally different approach. Because of that, 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.

Honestly, this part trips people up more than it should.

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.