Hashing, salting, digital signatures and obfuscation

Objective 1.3 is about choosing the appropriate cryptographic solution. The two previous lessons took PKI and encryption. This one takes the remaining tools -- hashing algorithms, salting, digital signatures and obfuscation -- and ends by putting all of them side by side, because the exam's real question is which one a stated requirement calls for.

Why this matters

Three of the four things in this lesson are routinely confused with encryption, and the exam knows it. Hashing is not encryption. Obfuscation is not encryption. A signature is not encryption of the message. Each has a property the others lack, and the questions are built on exactly those differences.

This is also the last lesson in Domain 1, so it is where the cryptography threads get pulled together into decisions. If you can read a requirement -- "prove the file was not altered", "prove who approved it", "keep it secret", "let developers test without real data" -- and name the right tool, you have most of this objective.

The lesson

What a hash proves, what it does not, and choosing a hashing algorithm

A hash function takes input of any size and produces a fixed-size digest. Three properties matter:

• Deterministic -- the same input always gives the same digest.
• One-way -- you cannot work back from the digest to the input.
• Collision resistant -- it should be infeasible to find two different inputs with the same digest.

A small change to the input produces a completely different digest, which is what makes hashes useful for spotting change.

What a hash proves is integrity: if the digest matches, the data has not changed. What it does not prove is authenticity -- anyone can compute a hash, so a matching digest tells you nothing about who produced the data. If an attacker can change a file, they can usually change a digest published beside it too. That is why a download page that lists a hash on the same server as the file offers limited assurance, and why signed hashes (two sections down) are the stronger control.

Choosing an algorithm depends on the job:

• General integrity -- file verification, signatures, certificates: use the SHA-2 family (SHA-256, SHA-384, SHA-512) or SHA-3.
• Deprecated -- MD5 and SHA-1 both have practical collision attacks and appear in questions as the wrong answer for anything security-relevant.
• Storing passwords needs something different: an algorithm that is deliberately slow and costly to compute, such as bcrypt, scrypt, Argon2 or PBKDF2. A fast hash like SHA-256 is a good integrity tool and a poor password store, because speed helps an attacker guessing billions of candidates.
• Integrity between two parties who share a secret -- an HMAC combines a hash with a secret key, so only someone holding the key can produce or verify the digest. That adds authenticity to integrity, though not non-repudiation, because both parties hold the key.

Salting, and why two users with one password must not share a hash

Hashing is deterministic, and for passwords that is a weakness. If two users choose the same password, their stored hashes are identical -- so cracking one cracks both, and anyone reading the table can see which accounts share a password. Worse, attackers can precompute the hashes of millions of common passwords once (rainbow tables are a compact form of this) and then look up any stolen digest instantly.

A salt is a unique random value generated for each password, stored alongside its hash and mixed into the input before hashing. The effects:

• identical passwords now produce different digests, so sharing is invisible and each account must be attacked separately;
• precomputed tables become useless, because they would have to be rebuilt for every possible salt.

The salt is not secret; its job is uniqueness, not concealment. And salting defeats precomputation, not guessing -- an attacker can still try candidate passwords against one salted hash at a time. That is why salting is paired with the slow password-hashing algorithms above, and with controls such as account lockout and MFA that limit guessing in the first place.

Digital signatures: integrity, authenticity and non-repudiation in one operation

A digital signature is produced by hashing the message and then processing that digest with the signer's private key. With RSA this is often described as encrypting the hash; elliptic-curve signature schemes work differently inside but give the same guarantees.

Verification uses the signer's public key to check that the signature matches a fresh hash of the message the recipient received. If it does, three things are true at once:

• the message has not changed -- integrity;
• it was signed by the holder of that private key -- authenticity;
• and the signer cannot credibly deny it -- non-repudiation.

What is not true: the message is not confidential. Signing and encrypting are separate operations, and a question describing a signed message as protected from eavesdroppers is wrong. If you need both, you sign and then encrypt.

Hashing first is not a detail to memorise, but the reason is testable: asymmetric operations are slow, so you sign a small fixed-size digest rather than the whole document.

Code signing is the everyday application. A signed installer or update lets the operating system confirm that the publisher is who they claim and that the bytes have not been altered since. It is also why a stolen code-signing key is such a severe compromise -- malware signed with it is trusted -- and why such keys belong in an HSM.

Obfuscation by steganography, tokenisation and masking, and how each differs from encryption

Obfuscation makes data harder to read, find or misuse by means other than encryption with a key. Three techniques matter.

• Steganography hides the existence of data, typically inside another file -- an image, an audio track, unused space in a document or packet. Encryption says "here is a secret you cannot read"; steganography says "there is nothing here". The hidden content is not necessarily protected once found, so it is usually combined with encryption. Defenders mostly meet it as a way to smuggle data out unnoticed.
• Tokenisation replaces a sensitive value with a meaningless substitute -- a token -- and keeps the mapping in a separate, heavily protected vault. The real card number never enters the application database. The property the exam tests: there is no key and no mathematical relationship between token and value, so a stolen token database cannot be decrypted. It can only be resolved by the vault.
• Data masking replaces part or all of a value with placeholder characters or realistic fake values -- **** **** **** 4471. It is used on screens, reports and in test environments. Static masking of test data is normally irreversible by design, so developers get realistically shaped data without holding real data.

Masking and tokenisation reappear in Domain 3 as methods for protecting data; here the point is how they differ from encryption, which is always reversible by anyone holding the key.

Choosing between hashing, signing, encrypting and obscuring for a stated requirement

Most questions in this objective come down to matching a requirement to a tool. Read the requirement for its key verb.

Three traps recur. Hashing is wrong whenever the data must be recovered. A signature is wrong whenever the requirement is secrecy. And encryption is wrong for password storage, because anyone with the key -- including an attacker who steals it -- can recover every password.

What to take into the exam

• Hashing gives integrity only. Signing gives integrity, authenticity and non-repudiation. Neither gives confidentiality.
• SHA-2 and SHA-3 are current; MD5 and SHA-1 are wrong answers. Passwords need a slow, salted algorithm.
• A salt is unique and not secret; it defeats precomputed tables and shared hashes, not guessing.
• HMAC adds authenticity between parties sharing a key, without non-repudiation.
• Tokenisation has no key and no reversible relationship; masking is normally irreversible; steganography hides existence.
• Match the verb: detect change, prove origin, keep secret, avoid holding the data at all.