Why do different applications of hash functions demand different properties of the hash function?

Question

A strong cryptographic hash function in general must guarantee several properties, including: Preimage resistance, second preimage resistance and collision resistance. It turns out, however, that certain applications only require a subset of the properties while others require all of them. The table below gives a summary of which applications require which properties (from Stalling's book). Can someone give an explanation for the properties required by each application? For example, it makes sense that one-way passwords require preimage resistance since we don't want a person to compute the password from the hash. But I would not understand why one-way passwords do not require collision resistance (i.e., if two different passwords give the same hash, then an impostor could more easily break in). Anyone with an explanation for the different properties? The table is from an authoritative textbook in the area (Stalling's book).

Answer 1

Hash + digital signature

If the hash is not collision resistant, the attacker can produce two messages having the same hash. They'll request a signature on the first and present the signature on the second, a forgery.

When second pre-image resistance is violated, this attack becomes much more severe, since now the attacker doesn't need control over both messages, they can simply use any (signature, message) pair they observed.

First pre-image resistance is not directly required, since signatures make no promise about hiding the message, But for common definitions first pre-image resistance is implied by second pre-image resistance.

IDS / virus detection

If second-pre-image resistance is violated an attacker can give their malware the same hash as an existing benign software, preventing blacklisting of the malware without the collateral damage of also blacklisting the benign software.

If collision resistance is violated an attacker can create one benign and one malicious piece of software. That's probably not a big deal, since the blacklisting will only affect the decoy software and not software somebody else developed. Still I'd strongly recommend using a collision resistant hash so you have a clear 1-to-1 mapping between hashes and executables, preventing confusion and misunderstandings.

Password hashing

Clearly the attacker must not learn anything about the password input, which is closely related to first pre-image resistance.

Lack of collision resistance only allows the attacker to construct two different but equivalent passwords which are valid for their own account. Second pre-image resistance requires knowledge of the correct password, and is thus harmless as well. The popular PBKDF2 password hash suffers from certain trivial collisions and second pre-images.

MAC

A MAC is keyed, a normal hash is not. So you need to specify how you construct a MAC from the hash. The standard choice is HMAC, which does not require collision resistance. As an example, HMAC-MD5 is still secure as MAC/PRF while the collision resistance of MD5 is utterly broken.

Key recovery is related to first pre-images, so you probably need that property. You also don't want any key independent collisions, but those are much harder to construct that plain collisions.

For a detailed description of sufficient conditions for HMAC security you can consult the HMAC proof of security.

Hash + symmetric encryption

If you want both integrity and confidentiality, we use authenticated encryption. The standard approach is first encrypting the message and then computing a MAC over the ciphertext. This is known as Encrypt-then-MAC and requires the same security properties as the MAC above.

Encrypting a hash of the message is insecure for many popular encryption algorithms, no matter how strong the hash. Don't do that, unless you really know what you're doing.