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).
Why do different applications of hash functions demand different properties of the hash function?
1$\begingroup$ What is Hash+Symmetric encryption supposed to be? $\endgroup$– CodesInChaosJul 3, 2016 at 10:58
$\begingroup$ I think it means hash followed by encryption -- a data integrity application in which the hash will be encrypted $\endgroup$– MinajJul 3, 2016 at 11:00
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.
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.
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.
$\begingroup$ You stress that MAC-then-encrypt is not good. I have read however that it is used in SSL. Is there something specific that makes it safe in SSL yet it would not be safe if used, say, in some application (application layer)? $\endgroup$ Jul 3, 2016 at 14:27
$\begingroup$ @Minaj Just because it is/was in SSL does not mean it is ideal. This is actually the case for a bunch of real world security programs, surprisingly. $\endgroup$ Jul 3, 2016 at 14:51
$\begingroup$ @CodesInChaos I see from your post that several elements in the table are wrong. $\endgroup$ Jul 3, 2016 at 15:28
$\begingroup$ @Ella Rose Did you say "was"? Is it not still used in TLS/SSL? $\endgroup$ Jul 3, 2016 at 15:29
1$\begingroup$ @Minaj I mainly blasted hash-then-encrypt. MAC-then-encrypt can be done right, but it's hard and has been the source of several security holes in TLS. It's just a historic mistake from a time where the problems with MtE were not generally understood. TLS 1.3 has done away with MtE and only uses the AEAD abstraction, where confidentiality and integrity are tightly fused in a single piece (even if it's internally built from some kind of MAC/encryption combination). $\endgroup$ Jul 3, 2016 at 15:37