Digital signature and salt

I'm wondering whether is of any use to add salt when computing a signature of a piece of data. I looked around but didn't find an answer to this, although there's a very similar question: Why hash or salt when signing?

My use case is the following:

• I have a small JSON-like document that I want to encode & sign on the server and deliver to the client

• The client must be able to verify that it comes from the server and decode the data itself

• The result (the encoded data + signature) should be an opaque string, the shorter, the better

Right now, I'm using a Clojure library (buddy-sign) which is a small wrapper around standard Java/JDK crypto classes. The compact-sign/sign function that I use is computing the signature like this:

1. Encode the input document with binary encoding (nippy)
2. Generate salt and timestamp
3. Concatenate encoded input with salt and timestamp and compute a signature of it
4. Concatenate the four components, base64 encoding each one of them, and produce the result: <nippy-encoded-data>.<signature>.<salt>.<timestamp>

I'm specifically interested in the role of salt in this process and whether it provides any benefits. Is it perhaps used because the library also offers HMAC (it uses this as the default algorithm) as a way to produce "signatures"?

Tangential questions:

• Is timestamp useful for preventing replay attacks?
• Is the described solution a classic approach when one needs to bundle the message and the signature together?

Adding salt generally does not provide any additional security benefits while signing. Replay attacks can be prevented by either nonce, or in this case, by timestamp.

However, it is situational.

With salt, we will get different signature for the same message. So when two messages are sent and you don't want the attacker to know if it's the same message, this will help you. It may also help if the input is too short or predictable.

Is timestamp useful for preventing replay attacks?

Yes, but not fully. Timestamp gives an expiry window. Till then, replays are possible. If you want to prevent all replays, use nonces. Or keep the expiry window short.

Is the described solution a classic approach when one needs to bundle the message and the signature together?

Yes, the above approach is actually the recommended approach - (Encrypt-then-MAC). For added security you can choose to send the message and signature over different channels, although it is considerably safe (and usual) to send it over the same channel.