Cryptography · Study deck

Hash Functions and Data Integrity

Picture a field unit downloading new software and a short check value.

Shield Shelly is your guide for this deck.

hash-functionsintegrityhmac

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Many signature schemes hash the message before or during signing, so a hash with practical collisions (MD5, SHA-1) can break that binding; use approved schemes and suitable hashes for new security decisions.
Explain: A plain digest detects change, HMAC adds shared-key proof, a signature protects artifacts many devices must trust, a KDF derives scoped keys, and a password hash slows offline guessing.
Explain: A cryptographic hash maps any input to a fixed-size digest; it is one-way and keyless, so it detects change but is not encryption and not a signature.

KDF and password-hashing paths compared by input and evidence

Major section

Start With the Fingerprint Question

A match can show that the bytes equal the expected copy, but it cannot show who chose that copy unless the expected value is protected.

The first test changes one byte and names the trust source.
A gateway means a device or service that joins two system paths.
Telemetry means measurements and status sent for remote use.

Major section

Start With the Fingerprint Question (continued)

Hash one known file, change one byte, use an attacker-chosen expected value, repeat an old release, and restart the verifier.

This runway does not prove identity, secrecy, or freshness from a plain hash.
The digest can tell whether the bytes match an expected value, but it cannot say who chose that value unless the expected value is protected.
A plain digest detects change, HMAC adds shared-key proof, a signature protects artifacts many devices must trust, a KDF derives scoped keys, and a password hash slows offline guessing.

Major section

A Fingerprint for Data, Not a Lock and Not a Signature

The release branch then asks whether the primitive, context, failure behavior, and migration path fit that role.

This map supplies the distinctions the rest of the chapter will prove.

Hash-based constructions mapped to their distinct security roles

Major section

Choose the Construction and Protect the Expected Value

Anyone can replace both a message and its unprotected digest, whereas only a holder of the HMAC key should create a valid tag.

The receiver still needs exact byte and context rules and a constant-time comparison.

A plain hash flags a mismatch but anyone can recompute it; HMAC mixes in a secret key, so a valid tag also proves the sender knew the key.

Major section

Pin One Firmware Image to One Digest

For hash integrity, in this hash-function check, the device may hash the downloaded image and compare it with a signed manifest digest.

At the firmware integrity boundary, a matching hash shows the checked bytes match that authenticated expectation.
A password KDF adds salt and deliberate work to slow each guess.

Major section

Summary

A cryptographic hash maps any input to a fixed-size digest; it is one-way and keyless, so it detects change but is not encryption and not a signature.

Security needs preimage, second-preimage, and collision resistance plus the avalanche effect; collision resistance is bounded by roughly half the digest length.
A plain digest only authenticates when the expected value is protected by a signed manifest, certificate chain, or authenticated channel.
Many signature schemes hash the message before or during signing, so a hash with practical collisions (MD5, SHA-1) can break that binding; use approved schemes and suitable hashes for new security decisions.

Deck summary

Key takeaways

A match can show that the bytes equal the expected copy, but it cannot show who chose that copy unless the expected value is protected.

Hash one known file, change one byte, use an attacker-chosen expected value, repeat an old release, and restart the verifier.
The release branch then asks whether the primitive, context, failure behavior, and migration path fit that role.
Anyone can replace both a message and its unprotected digest, whereas only a holder of the HMAC key should create a valid tag.

Retrieval practice

Recall check 1 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q1A team needs to store a user password and derive separate device keys. Which pair of hash-based tools fits?

AA fast plain digest for passwords and device keys, without salt or context.

BHMAC for password storage and no derivation context.

CStore slow salted hashes; use a context-bound KDF for device keys.

DEncryption of the stored password with the same device data key.

Show answer

Answer: C Password storage must resist guessing, while derived keys need distinct contexts.

Retrieval practice

Recall check 2 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q2A vendor says, 'We hash the sensor readings, so they are encrypted and safe.' What is the strongest correction?

AA long hash digest encrypts readings strongly enough for confidentiality.

BHashing is one-way and keyless; it gives neither secrecy nor sender proof.

CA hash both hides readings and proves which device sent them.

DReadings become confidential because a digest cannot be reversed.

Show answer

Answer: B A hash is not encryption: it cannot be reversed to hide and reveal data, and anyone can recompute it, so it does not authenticate the sender.

Retrieval practice

Recall check 3 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q3Two devices share a secret key and need each message to prove it came from the peer and was not altered. A developer appends a plain SHA-256 digest; the proposed replacement is HMAC with the shared key. Why is the plain digest insufficient?

AIt is sufficient, because SHA-256 is collision resistant

BIt is fixed by also sending the message length alongside the digest

CAnyone who can change the message can recompute the plain digest.

DEncrypting the digest with the same hash a second time would authenticate it

Show answer

Answer: C A keyless digest authenticates no one.

Retrieval practice

Recall check 4 of 4

Shield Shelly says: answer from memory, then check your reasoning.

Q4A team keeps signing firmware manifests with a hash that has known practical collisions, arguing the digest is long enough to be safe. Why is this unsafe specifically for signatures?

ATreat the manifest as safe because its signature protects integrity independently of the hash used.

BThe only issue is that the digest takes more storage than necessary

CSwitching to a longer digest from the same broken algorithm fixes it

DA signature over one colliding manifest can verify another.

Show answer

Answer: D Signatures bind to a digest, so a usable collision lets a valid signature transfer to a different document.

Print reference

Answers

Answer key.

C · Password storage must resist guessing, while derived keys need distinct contexts.
B · A hash is not encryption: it cannot be reversed to hide and reveal data, and anyone can recompute it, so it does not authenticate the sender.
C · A keyless digest authenticates no one.
D · Signatures bind to a digest, so a usable collision lets a valid signature transfer to a different document.