Unit 2ConceptsObjective 1.49 min read

Hashing, Salting, Signatures, and Key Stretching

Unit 2: Change Management and Cryptography. Lesson 7 of 54 in SecPlus Academy.

A hash is a fixed-length fingerprint of data. Change one bit of the input and the fingerprint changes completely. Hashes are one-way: you cannot get the data back from the hash. That makes them the tool for integrity, passwords, and signatures.

Algorithms and lengths

MD5: 128-bit output, broken; collisions can be manufactured. Recognize, never recommend.
SHA-1: 160-bit, deprecated for the same reason.
SHA-256 (and the SHA-2 family): the current standard. SHA-3: a newer alternative design.

A collision is two different inputs with the same hash. Strong hashes make collisions computationally impractical.

Checking a hash yourself

Vendors publish the SHA-256 hash of a download so you can confirm the file arrived intact. Compute it and compare every character with the published value; any difference at all means the file is not the one the vendor shipped.

Linux: sha256sum installer.iso prints the hash followed by the file name. shasum -a 256 installer.iso gives the same hash from the shasum tool.
Windows: certutil -hashfile installer.iso SHA256 prints the hash. The order is fixed: the file name first, then the algorithm name.

HMAC

A hash mixed with a secret key. Only someone with the key can produce the right value, so HMAC proves both integrity and that the sender knew the key. Used in API authentication and in TLS.

Passwords: salting and key stretching

Systems store password hashes, not passwords. Two problems remain. Identical passwords produce identical hashes, and attackers precompute tables of hashes for common passwords.

Salting adds random data to each password before hashing. Same password, different salt, different hash. Precomputed tables become useless.
Key stretching runs the hash thousands of times, or uses a deliberately slow function, so each guess costs the attacker real time. PBKDF2, bcrypt, scrypt, and Argon2 are key-stretching functions.

Digital signatures, step by step

Hash the message.
Encrypt the hash with the sender's private key. That encrypted hash is the signature.
The receiver decrypts the signature with the sender's public key to get the original hash.
The receiver hashes the received message and compares. Match means the message is intact and came from the private key holder.

Signatures deliver integrity, authenticity, and non-repudiation. They do not provide confidentiality.

Blockchain and the open public ledger

A chain of blocks where each block contains the hash of the previous one. Altering an old block changes its hash and breaks every block after it, and the ledger is copied across many participants, so tampering is evident. Exam questions frame it as an open public ledger with integrity built in.

Exam tip: "two files produce the same hash" is a collision, and the fix is a stronger algorithm. "Identical passwords stored with different hashes" is salting. "Make brute force slow" is key stretching. Signatures never encrypt the message itself.

Remember

Hash: one-way fingerprint, MD5 and SHA-1 broken, SHA-256 fine. Salt makes duplicates differ; stretching makes guesses slow. Signature = hash encrypted with the private key. HMAC = hash plus a key.

Deeper explanation

Hashing, Salting, Signatures, and Key Stretching, explained slowly

A fingerprint for data

A hash function takes any input, a word or a ten-gigabyte file, and produces a fixed-length string of bits. Three properties make it useful:

The same input always gives the same hash.
Any change to the input, even one bit, gives a completely different hash.
You cannot work backward from the hash to the input.

That is a fingerprint. You can compare fingerprints to prove two things are identical without comparing the things, and you cannot rebuild a person from a fingerprint.

Algorithm   Output     Status
MD5         128 bits   broken: collisions can be created on demand
SHA-1       160 bits   deprecated: collisions demonstrated
SHA-256     256 bits   current standard (SHA-2 family, also SHA-512)
SHA-3       256+ bits  newer design, also acceptable

A collision is two different inputs with the same hash. If an attacker can make one, they can substitute a malicious file for a legitimate one and the hashes will still match. That is why MD5 and SHA-1 are out.

Where hashes show up

Integrity checks: a download page lists the file's SHA-256; you hash your copy and compare.
Password storage: the system stores the hash, never the password. At login it hashes what you typed and compares.
Digital signatures: you sign the hash, not the whole document.
HMAC: a hash computed with a secret key mixed in. Only someone with the key can produce the right value, so it proves integrity and origin at once. APIs and TLS use it.

Passwords: the two attacks and the two fixes

Attackers who steal a password database attack the hashes offline.

Attack 1: precomputed tables. They hash millions of common passwords in advance and look up matches. Also, everyone who chose "Summer2024" has the same hash, so one crack reveals them all.

Fix: salting. Add a random value to each password before hashing and store the salt beside the hash. Now "Summer2024" produces a different hash for every user, and precomputed tables are useless.

without salt:  hash("Summer2024")            = a1b2...   same for every user
with salt:     hash("x7Qp" + "Summer2024")   = 9f3e...   user 1
               hash("Lm2v" + "Summer2024")   = 04cc...   user 2

Attack 2: fast guessing. Modern hardware computes billions of SHA-256 hashes per second.

Fix: key stretching. Use a function designed to be slow, or iterate the hash thousands of times, so each guess costs the attacker milliseconds instead of nanoseconds. PBKDF2, bcrypt, scrypt, and Argon2 do this. Users never notice a 100 ms login; attackers trying a billion guesses do.

Digital signatures, step by step

SENDER                                     RECEIVER
1. hash the message                        4. decrypt the signature with the sender's PUBLIC key -> original hash
2. encrypt that hash with PRIVATE key      5. hash the received message
3. send message + signature                6. compare: match = intact and authentic

Why sign the hash and not the message? Asymmetric encryption is slow and the hash is small. What a signature provides: integrity (any change breaks the match), authenticity (only the private key holder could sign), non-repudiation (they cannot deny it). What it does not provide: confidentiality. The message travels in the clear unless separately encrypted.

Blockchain

A chain of blocks where each block stores the hash of the block before it. Change anything in block 50 and its hash changes, which breaks block 51's stored hash, and so on to the end. Copies of the chain sit with many participants, so a tamperer would have to rewrite every copy. The exam calls this an open public ledger: a record anyone can read and nobody can quietly edit.

How the exam asks it

"Ensure a downloaded file has not been modified." Compare hashes.
"Two users with the same password have different stored values." Salting.
"Make offline password cracking impractically slow." Key stretching.
"Verify the sender and that the message is unaltered." Digital signature.
"Which hash algorithm should be replaced?" MD5 or SHA-1.

What to memorize

MD5 128 broken, SHA-1 160 deprecated, SHA-256 fine.
Salt defeats precomputed tables; stretching defeats fast guessing.
Signature = hash encrypted with the sender's private key.