As far as I've read, there is no benefit of a MAC over a digital signature - except the fact that it is faster to generate and process.

Is this true? Digital signatures (asymmetric encryption) seem to have gotten fast enough that almost every website uses them. So it can't be that big of a drawback nowadays.

Am I missing something important?

  • 3
    what do you want to do with a MAC or digital signature?
    – schroeder
    Aug 24, 2017 at 8:52
  • I'm thinking that your question can be answered by Wiki: en.wikipedia.org/wiki/…
    – schroeder
    Aug 24, 2017 at 12:07
  • Asymmetric cryptography tends to be really really slow, relative to symmetric cryptography.
    – user253751
    Apr 16, 2018 at 5:56
  • 1
    There may be some overlap in use cases, but HMACs require a shared secret, i.e. any holder of the secret can use the HMAC to verify the integrity of a message. Digital signatures can be verified by anyone who in possession of the public key certificate of the signing key, provided they trust the issuer and perform all appropriate validations. The biggest drawback to DS is the size of the signature. An HMAC using SHA-1 (still safe in this case) is 20 bytes. An RSA-2048 signature is 256 bytes. In low bandwidth applications using short messages, that's a ton of additional overhead.
    – Lampshade
    Jul 24, 2020 at 15:09

3 Answers 3


Performance alone is a reason to use MAC.

Consider a TLS connection. For every packet, the receiving party needs to verify that the packet wasn't modified in transit by a man-in-the-middle attacker. So for every packet, the sender needs to calculate a MAC/signature and the receiver needs to verify it. If you want, say, a 10MB/s transfer rate and an average of 10kB/packet, that means you only have a fraction of 1ms to calculate or verify the signature. That's too slow for a digital signature.

The amount of time it takes to create and verify an asymmetric signature is small enough to be a non-issue if you do it once when a connection is established, assuming you have high-end hardware such as a PC, server or smartphone (it can be an issue on embedded devices). But it doesn't work if you need to do it once per packet.

A digital signature has the advantage that it can be verified by a party that isn't able to generate a fake signature. This isn't useful in a case like a TLS connection. For TLS, the two parties set up a session key, which is a symmetric key that is generated randomly at the start of the connection. After that, the only two parties that know the key are the client and the server. If the client sees a valid MAC (that it didn't generate itself), it can only have been produced by the server, and vice versa. Similarly, once the session key has been generated, it (and not asymmetric cryptography) is used for encryption.

(Properly speaking, the same key shouldn't be used for different purposes such as MAC and encryption, even if it happens to have the right format. I simplified things a little above. The “session key” is actually some secret material from which an encryption key and a MAC key are derived — or, in some ciphersuites, a single authenticated encryption key is derived, although the AE algorithm then derives two keys internally.)


Both HMAC and signature can be used to verify the data integrity and the authentication of messages. However signatures also provides the property of non-repudiation: given a message and its signature, you can prove that the message has indeed been written by the sender.

You might not want this property. For example, you might want to exchange messages privately with someone that you don't trust. If your messages are signed, the other party will be able to disclose a compromising message and prove that you wrote it. Using HMAC, you can still be assured of the privacy of the conversation, but the other party will not be able to prove that you wrote this compromising message because they also could have written it.


I think I might have thought up a possible answer.

With a signature the receiver (client app) can be sure that the message came from the sender (server app). But if the client app now sends something back to the server (another HTTP request posting some data) the server cannot be sure if the message really came from the same client app - any possible client could use the server's public key to create such a message.

On the other hand if they share a secret (as in HMAC), there is at least some measure of certainty that the message originated from the expected client app.

The problem with this seems to be, that a secret salt for MAC creation is not really worth much with untrustworthy clients (javascript or mobile apps) since they can always be breached.

  • 1
    The client can sign too.
    – A. Hersean
    Aug 24, 2017 at 11:53
  • @A.Hersean: Sure - but it does not matter who the client is, because every possible client can sign with the public key. Only the server can sign with its private key. The client knows definitively that a message come from the server (if it validates with the servers public key). But the server can not know if the client is a particular client (some trusted application) or just a random attacker. Is this a false assumption?
    – Wolfgang
    Aug 24, 2017 at 11:57
  • 1
    The client sign with the client's private key. Please read again the protocol. Each client has a different private key. The server knows that a particular client stays the same. The server cannot differentiate between a client, a misused client, or an attacker this way; but the server can differentiate between two clients (or a client and an attacker, it's the same), same as with an HMAC.
    – A. Hersean
    Aug 24, 2017 at 12:32
  • I understood you, but you obviously cannot understand what I am trying to say.
    – Wolfgang
    Aug 24, 2017 at 12:35
  • 1
    Same with signatures.
    – A. Hersean
    Aug 24, 2017 at 12:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .