These types of cryptographic primitive can be distinguished by the security goals they fulfill (in the simple protocol of “appending to a message”):
-
Integrity: Can the recipient be confident that the message has not been accidentally modified?
-
Authentication: Can the recipient be confident that the message originates from the sender?
-
Non-repudiation: If the recipient passes the message and the proof to a third party, can the third party be confident that the message originated from the sender? (Please note that I am talking about non-repudiation in the cryptographic sense, not in the legal sense.)
Also important is this question:
- Keys: Does the primitive require a shared secret key, or public-private keypairs?
I think the short answer is best explained with a table:
| Hash | МАС | Digital signature | |
|---|---|---|---|
| Integrity | Yes | Yes | Yes |
| Authentication | No | Yes | Yes |
| Non-repudiation | No | No | Yes |
| Kind of keys | None | Symmetric | Asymmetric |
Please remember that authentication without confidence in the keys used is useless. For digital signatures, a recipient must be confident that the verification key actually belongs to the sender. For MACs, a recipient must be confident that the shared symmetric key has only been shared with the sender.
The longer answer:
A (unkeyed) hash of the message, if appended to the message itself, only protects against accidental changes to the message (or the hash itself), as an attacker who modifies the message can simply calculate a new hash and use it instead of the original one. So this only gives integrity.
If the hash is transmitted over a different, protected channel, it can also protect the message against modifications. This is sometimes be used with hashes of very big files (like ISO-images), where the hash itself is delivered over HTTPS, while the big file can be transmitted over an insecure channel.
A message authentication code (MAC) (sometimes also known as keyed hash) protects against message forgery by anyone who doesn’t know the secret key (shared by sender and receiver).
This means that the receiver can forge any message – thus we have both integrity and authentication (as long as the receiver doesn’t have a split personality), but not non-repudiation.
Also an attacker could replay earlier messages authenticated with the same key, so a protocol should take measures against this (e.g. by including message numbers or timestamps). (Also, in case of a two-sided conversation, make sure that either both sides have different keys, or by another way make sure that messages from one side can’t sent back by an attacker to this side.)
MACs can be created from unkeyed hashes (e.g. with the HMAC construction), or created directly as MAC algorithms.
A (digital) signature is created with a private key, and verified with the corresponding public key of an asymmetric key-pair. Only the holder of the private key can create this signature, and normally anyone knowing the public key can verify it. Digital signatures don’t prevent the replay attack mentioned previously.
There is the special case of designated verifier signature, which only ones with knowledge of another key can verify, but this is not normally meant when saying “signature”.
So this provides all of integrity, authentication, and non-repudiation.
Most signature schemes actually are implemented with the help of a hash function. Also, they are usually slower than MACs, and as such used normally only when there is not yet a shared secret, or the non-repudiation property is important.
Source: What are the differences between a digital signature, a MAC and a hash?