TransWikia.com

Why would I use MAC over digital signature?

Information Security Asked on December 24, 2021

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 Answers

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.)

Answered by Gilles 'SO- stop being evil' on December 24, 2021

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.

Answered by Wolfgang on December 24, 2021

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.

Answered by A. Hersean on December 24, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP