13.3 Hashing, MACs & Integrity
Key Takeaways
- A cryptographic hash is deterministic, one-way, and avalanche-sensitive: the same input always yields the same digest, but the digest should not reveal the input, and tiny input changes scramble the output
- SHA-256 is a widely used modern hash producing a 256-bit digest for integrity checks, fingerprinting, and as a building block inside signatures and HMACs
- Hashing is not encryption — there is no key that ‘decrypts’ a digest back to the original message
- MACs/HMACs use a shared secret plus a hash construction to detect tampering and prove the message came from a key holder; encryption alone does not guarantee integrity
- Password storage should use slow, salted password hashing (or equivalent KDFs), not reversible encryption and not a fast raw hash of the password alone
Encryption protects confidentiality. Many cyber problems instead ask: “Was this data altered?” or “Is this the same file I downloaded yesterday?” Those are integrity questions. Cryptographic hash functions, MACs, and HMACs are the core tools. This section also covers why password storage uses specialized hashing — a frequent conceptual trap when candidates confuse hashing with encryption.
What a Cryptographic Hash Does
A cryptographic hash function takes an arbitrary-length input (a password, a firmware image, a network packet payload) and produces a fixed-length output called a digest or hash value. For Cyber Test reasoning, lock in three properties:
- Deterministic. The same input always produces the same digest. If
SHA-256("flight-plan.txt")is computed twice on identical bytes, the results match. That is why hashes can verify downloads: publish the digest; recompute locally; compare. - One-way (preimage resistance). Given only the digest, it should be computationally infeasible to recover a useful original input. You cannot “decrypt” a hash — there is no decryption key because hashing is not encryption.
- Avalanche effect. A tiny change in the input — one flipped bit — should produce a drastically different digest. That sensitivity makes accidental or malicious modifications obvious when digests are compared.
Related goals you may see named in study materials: collision resistance (it should be hard to find two different inputs with the same digest) and second-preimage resistance (given one input, it should be hard to find a different input with the same digest). You do not need formal security proofs; you need the operational meaning: matching digests strongly suggest identical inputs; mismatched digests prove a change.
SHA-256 in Practice
SHA-256 (part of the SHA-2 family) produces a 256-bit digest, usually shown as 64 hexadecimal characters. It is a modern default for:
- File and firmware integrity verification.
- Fingerprints of certificates and keys (human-comparable digests).
- Building blocks inside digital signatures (sign the hash of a message, not the entire multi-megabyte message).
- Building blocks inside HMAC constructions.
Older algorithms such as MD5 and SHA-1 are considered broken or unsafe for collision-resistant uses; prefer SHA-256 (or stronger SHA-2/SHA-3 variants) in modern guidance. For the exam, associating SHA-256 with “strong, common integrity hash” is the main payoff.
Example mental check: if a vendor posts SHA256: 3a7f… next to an ISO download and your computed digest differs, do not install the image — integrity failed, regardless of whether the download “looked” complete.
Hashing Is Not Encryption
This distinction is heavily tested:
| Hashing | Encryption | |
|---|---|---|
| Goal | Integrity / fingerprinting | Confidentiality |
| Reversible? | No (one-way) | Yes, with the correct key |
| Key required? | No for a plain hash | Yes (symmetric or asymmetric) |
| Output size | Fixed (e.g., 256 bits) | Roughly related to plaintext size (plus overhead) |
Storing “encrypted passwords” by running them through SHA-256 alone is a misuse of language and often a misuse of cryptography. A digest is not ciphertext. Conversely, encrypting a file with AES does not by itself prove the ciphertext was unmodified in transit unless you also use an integrity mechanism (MAC, AEAD tag, signed hash, and so on).
MACs and HMACs: Integrity With a Shared Secret
A plain hash answers “does this match the published digest?” Anyone who can modify a file can also recompute and republish a new hash if they control the channel where the hash is posted. When two parties share a secret and need to detect tampering on messages they exchange, they use a Message Authentication Code (MAC).
A MAC takes message + secret key and produces an authentication tag. The receiver recomputes the tag with the same key and compares. If the tags match, the message was not altered and was produced by someone who knows the key (within the MAC’s security model).
HMAC is a specific, widely standardized way to build a MAC from a cryptographic hash (for example HMAC-SHA-256). You will see HMAC in APIs, TLS-related constructions historically, and secure token designs. Key points:
- MAC/HMAC provides integrity and authenticity relative to a shared key.
- MAC/HMAC does not encrypt the message; the message may still be readable unless separately encrypted.
- Encryption without integrity can leave room for certain manipulation attacks depending on mode; modern systems prefer authenticated encryption or explicit MACs.
Compare roles quickly:
- AES encrypt → hide contents.
- SHA-256 hash → fingerprint contents (no secrecy of the fingerprint process itself).
- HMAC-SHA-256 → prove a keyed party produced this exact content.
- Digital signature (asymmetric) → prove a specific private-key holder signed the content; verifiable with a public key / certificate (no shared MAC key required between verifier and signer).
Password Hashing Intuition
User passwords should not be stored in plaintext. They also should not be stored with reversible encryption if the goal is “even the database thief cannot easily recover passwords.” Best practice uses password hashing / key-derivation functions designed to be:
- One-way, so the stored value is a verifier, not the password.
- Salted, so identical passwords for different users do not produce identical stored hashes, blocking precomputed rainbow-table reuse across users.
- Slow / memory-hard (intentionally expensive), so online and offline guessing is costly — unlike fast SHA-256 alone, which GPUs can try at enormous rates.
Algorithms in this family (bcrypt, scrypt, Argon2, PBKDF2-style constructions) are password-oriented. The Cyber Test may not demand a specific algorithm name, but it will expect the intuition: passwords → slow salted password hash, not “AES-encrypt the password with a key sitting next to the database,” and not “raw unsalted SHA-256 of the password.”
When a user logs in, the system hashes the offered password with the same salt/parameters and compares verifiers — it does not decrypt a password back to plaintext.
Integrity Workflows You Should Recognize
- Software supply chain: vendor publishes SHA-256 sums; admins verify before install.
- Secure messaging/storage: encrypt for confidentiality, MAC or AEAD for integrity.
- Authentication tokens / API requests: HMAC tags prove a request was not altered and came from a key holder.
- Forensics / evidence handling: hashing disk images documents that evidence was not changed later.
If a question emphasizes “detect change” or “verify identical file,” think hash. If it emphasizes “detect change using a shared secret between two parties,” think MAC/HMAC. If it emphasizes “hide contents,” think encryption. Keeping those three lanes separate is the highest-yield study strategy for this section.
Which property means a cryptographic hash always produces the same digest for the same input?
Why is hashing not the same as encryption?
What does an HMAC provide that a bare SHA-256 digest of a message does not?
Which approach best matches modern password-storage intuition?