What must stay in working memory
- Hashing is one-way and does not provide confidentiality or a decryption operation.
- A trustworthy comparison value—such as a digest in a signed manifest—is needed to turn recomputation into a meaningful security check.
- Password verifiers need a unique salt and a deliberately expensive password-hashing/KDF construction; a separately protected pepper can add another barrier.
Concrete examples
- A responder hashes a disk image before and after transfer to demonstrate that the acquired bytes did not change.
- A password database stores a unique salt and a slow derived verifier, never reversible plaintext.
Decision rules you’ll retrieve
Choose hashing only for goals it satisfies
Choose a hash for a one-way content fingerprint; choose encryption when authorized recovery of plaintext is required, and a keyed authenticator when both integrity and source authentication are required.
Retrieval cue: Explain which security goals a plain cryptographic hash does and does not provide before choosing a primitive.
Separate salts, stretching, and peppers
A unique public salt defeats reused precomputation and exposes equal passwords as different verifiers; a work factor raises each guess's cost; an optional pepper is a secret stored outside the verifier database.
Retrieval cue: Define salt, work factor or stretching, and pepper by the attack each one changes and where its value is stored.
Verify integrity against a trustworthy value
Recompute the digest over the received bytes and compare it to an authenticated, independently trusted reference; matching an attacker-replaceable digest proves little.
Retrieval cue: Describe the full integrity-verification process, including where the expected digest must come from.