This question is aiming at clarification related to message authentication codes (MACs).

Wikipedia’s Message Authentication Code article states:

In cryptography, a message authentication code (MAC), sometimes known as a tag, is a short piece of information used to authenticate a message—in other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed. The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content.

(emphasis mine)

Is it correct to say that MACs not only provide integrity information related to the data itself, but also validate the identity of the originator? Or does it make sense to verify/validate the identity of a sender using additional cryptographic means – maybe something along the lines of a Sender Identification Code, Originator Verification Code, or something like that?

Differently asked:

Should the identity of a sender be verified using additional means, or does a MAC suffice?


2 Answers 2


It is a recurring topic: what exactly is identity and how to prove it ? But related to your question: a MAC (correctly implemented) proves that the author of the message was in possession of the secret key (like you are, if you can verify it). Now, depending on the application you have in mind, that's a good enough proxy of identity, or it isn't.

In other words, a MAC takes as assumption that you trust that only the right entities have knowledge of the secret key (you included), and then prove that the message could only have been signed by one of these entities. The question of whether the right entity has the knowledge of the key is then another issue.

  • 2
    $\begingroup$ I think what should be spelt out more explicitly is that in this case, the receiving and sending side have the same cryptographic "identity". This may be fine if only the receiving side needs to verify that messages came from the sending side (because the receiving side probably knows they didn’t send the message). In some applications it would not be acceptable for the receiving side to be able to forge messages from the sending side; which is the case with a MAC (voting comes to mind). $\endgroup$ Dec 7, 2017 at 8:42
  • $\begingroup$ @Jonas: this is why I said "signed by one of these entities" and "(you included)". And this is why "entity who knows the key" as a proxy to identity, may be suited, or not, depending on the application. $\endgroup$
    – entrop-x
    Dec 7, 2017 at 10:03
  • $\begingroup$ @entrop-x I know you said that, I felt that a bit of emphasis on this one couldn’t hurt :-) $\endgroup$ Dec 7, 2017 at 10:19

Like entrop-x says, a valid MAC proves that the sender (or, more specifically, whoever computed the MAC) knows the secret MAC key. That can be sufficient to prove the sender's identity, e.g. if the only people who are supposed to know the key are you and whoever claims to have sent the message, and you know you didn't send it yourself.

That said, there are several edge cases that one should be aware of:

  • For example, there might be several people who all know the key. If the identity of the sender is included as metadata alongside the message, but is not fed into the MAC calculation, then an attacker may change the metadata without invalidating the MAC.

    So if Alice, Bob and Charlie all know the key, an attacker might be able to convince Alice that a message sent to her came from Bob, when it was actually sent by Charlie. Or the attacker might even be able to divert the message to Bob instead, and convince him that it was sent by Alice.

  • In some cases, even if there are only two parties who know the key, an attacker might be able to take a message sent by Alice to Bob and resend it back to Alice, claiming that it's from Bob.

  • Even if the sender's (and the intended recipient's) identity is included in the MAC input, this doesn't necessarily verify when the message was sent. So an attacker might be able to record a legitimate message to Alice from Bob and send it again to Alice seconds or days or years later.

The first two attacks can be prevented by ensuring that all relevant message metadata, including the sender's and the receiver's IDs, is included as input to the MAC calculation. In authenticated encryption terminology, such metadata is called "associated data". Note that the metadata does not always need to be actually transmitted with the message, if it can be inferred from context (e.g. the receiver likely knows what their own ID should be), but it should still be included when computing the MAC.

The third attack cannot be prevented by MACs alone, but requires some kind of a unique message number and/or a timestamp to let the receiver detect and reject duplicate or excessively delayed messages. Of course, the message number and the timestamp should also be considered associated data, and included in the MAC input, to prevent an attacker from modifying them.

The general rule to keep in mind is that a MAC only proves one thing: that whoever computed the MAC knew the key and all the inputs to it, and that they thought it was a good idea to feed those inputs to the MAC. It does not prove when or why they thought that, or what they intended to do with data after MACing it — unless, of course, that information is somehow encoded by the MACed data itself.

  • 2
    $\begingroup$ For the mirroring attack, having separate MAC keys for both directions will also help. $\endgroup$ Dec 7, 2017 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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