Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

A message may be accompanied with a digital signature, a MAC or a message hash, as a proof of some kind.

Which assurances does each primitive provide to the recipient?

What kind of keys are needed?

share|improve this question
2  
Looks like a homework ;) –  Uwe Plonus Dec 10 '12 at 13:32
    
Why am I being downvoted? It's not homework, and any way, homework questions are allowed. –  Flimm Dec 10 '12 at 17:37
6  
Seems like an attempt to create a canonical question that explains the difference between commonly confused operations. –  CodesInChaos Dec 10 '12 at 19:01
1  
The phrase "in your answer, please discuss" makes it look like homework. Maybe we can reword it a bit? I think most of the bulleted points could better fit in your answer. (Questions just containing the assignment, or looking like this, are likely to be downvoted, which you just witnessed.) –  Paŭlo Ebermann Dec 10 '12 at 19:30
1  
@Flimm I only pointed out that this looks like homework. I did not cast any downvote and now I made an upvote because with this question it is of use for others also. –  Uwe Plonus Dec 11 '12 at 6:53

1 Answer 1

up vote 27 down vote accepted

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:

Cryptographic primitive | Hash |    MAC    | Digital
Security Goal           |      |           | signature
------------------------+------+-----------+-------------
Integrity               |  Yes |    Yes    |   Yes
Authentication          |  No  |    Yes    |   Yes
Non-repudiation         |  No  |    No     |   Yes
------------------------+------+-----------+-------------
Kind of keys            | none | symmetric | asymmetric
                        |      |    keys   |    keys

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.

share|improve this answer
1  
One interesting variation is using the result of a DH key exchange as the key for a MAC. That way you can use asymmetric keys, but you avoid non-repudiation. –  CodesInChaos Dec 11 '12 at 12:04
    
so basically: MAC is a Hash that uses a "symmetric" key, Signature is a Hash that uses an asymetric key. –  David 天宇 Wong Mar 17 at 3:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.