Does adding a salt to the message before HMAC processing add any security?

Question

An HMAC function is designed to verify message integrity, i.e., that the message has not been tampered with. It is generally (always?) implemented by using a hashing function H, and calculating the hash H(key + H(key + message)), where + signifies concatentation (Source). The key is secret, and is reused for multiple HMAC calculations.

A related cryptographic technique is "salting." This is commonly used when storing passwords: each password will have a unique salt (or "nonce"), and you store the hash H(salt + key) and the salt together in the database. The salt is not encrypted, is not reused for other passwords, and is not a "secret" like the HMAC key.

My question is: does it add any security to add a random salt to the message you are validating with HMAC?

In my situation, the "message" I am validating is a six digit number. My "gut" was to use a salt (perform HMAC on salt + my six digit number) to protect against rainbow tables, but then it occurred to me that, since I'm using a 512-bit HMAC key generated by a cryptographically secure random number generator, there may be no added security. If I'm understanding it correctly, this answer (to a question about HMACing short inputs) means that there is no added security.

However, I am not completely certain. So, can someone clarify? Is there any value in adding a salt to your message prior to determining the HMAC?

Answer 1

My question is: does it add any security to add a random salt to the message you are validating with HMAC?

This depends on what the HMAC is used for.

If you use a key to sign more than one secret message, a salt will prevent an attacker from knowing whether two of them are equal. (Or brute forcing a message if the key is revealed...)

It is more common that you send the message and its HMAC value through the same channel, in which case protecting the secrecy of what is authenticated does not matter (unless you encrypt and use encrypt-and-MAC). What may matter, however, is that an attacker could do replay attacks, reusing a previous message and HMAC pair.

To protect against replay attacks you need to add not just a salt, but one that the receiver can verify has never been used before. For example, an incrementing counter (that both parties store and compare), a close enough (monotonic) timestamp, or a salt that the receiver chooses e.g. randomly.