Hashing, salting and digital signatures: Security+ guide
A hash function turns input of any length into a fixed-length value that cannot practically be reversed, so a changed input gives a different hash. Salting adds a unique, non-secret value to each password before hashing so identical passwords store differently. A digital signature applies the signer's private key to a hash of the data, which gives integrity, source authentication and non-repudiation.
Hashing
A cryptographic hash function maps input of any length to a fixed-length output called a hash value or message digest. Approved hash functions are one-way (you cannot practically find an input for a given output) and collision resistant (you cannot practically find two inputs with the same output).
To check integrity, compute a hash of the data, store or send both, and later hash the received data again. If the two hashes match, the data has not changed.
Attacks on SHA-1 show it gives less security than first thought, and NIST now disallows it for generating digital signatures. The SHA-2 and SHA-3 families are the current choices.
Salting stored passwords
NIST SP 800-63B requires verifiers to store passwords salted and hashed with a suitable password hashing scheme. The scheme takes a password, a salt and a cost factor and produces the stored hash.
The salt must be at least 32 bits and chosen so salt values rarely repeat. It is stored next to the hash. It is not secret. Its job is to make each stored hash unique, so two users with the same password get different stored hashes.
The cost factor should be as high as practical and raised over time as computers get faster. A higher cost makes every offline guess more expensive for an attacker who has stolen the hashes.
HMAC versus digital signatures
A message authentication code (MAC), such as an HMAC, is computed with a symmetric key that both sides share. NIST says a MAC gives authenticity and integrity protection but not non-repudiation: either key holder could have produced it.
A digital signature uses a key pair. The signer hashes the data, and the message digest is input to the signature algorithm with the signer's private key. Anyone with the public key can verify it. Because only the signer holds the private key, a recipient can show a third party that the claimed signer made it. FIPS 186-5 calls this non-repudiation.
Example: two banks that protect payments with a shared-key HMAC cannot prove to an arbiter which bank sent a disputed message. Digital signatures would settle it.
Where the exam catches people
Believing a salt must be kept secret: it is a non-secret value stored alongside the hash; its job is to make each hash unique.
Believing hashing is encryption: a hash is one-way and has no key to reverse it.
Believing an HMAC gives non-repudiation: both parties hold the same key, so either could have made it; only a digital signature does.
Believing the signer signs the whole file directly with the public key: the signer's private key is applied to the file's hash, and the public key verifies.
Believing a digital signature keeps a message confidential: it gives integrity and origin; confidentiality needs encryption as well.