3
$\begingroup$

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?
$\endgroup$
3
  • 1
    $\begingroup$ "HMAC (it uses this as the default algorithm) as a way to produce signatures" - HMACs aren't (in crypto parlance) signatures. On the other hand, if both the server and the client can share the same secret key (and you can trust the client not to generate its own HMACs), then HMAC (or CMAC or KMAC) is a better solution than a 'real' signature algorithm - for one the tag is much shorter (and you could truncate it with predictable security loss) $\endgroup$
    – poncho
    Jan 6, 2023 at 19:07
  • $\begingroup$ "HMACs aren't (in crypto parlance) signatures" - yes, that's why I was a bit confused when I saw they also provide hmac (in fact, as the default) as an option for signing. I suspect for HMAC using a salt is more meaningful than for a proper signature algorithm? $\endgroup$ Jan 7, 2023 at 18:41
  • 2
    $\begingroup$ Naah, you don't need a salt with HMAC; it wouldn't actually buy you anything. And, because you're interested in minimizing the length of the opaque string, it costs you something, so I'd just omit it. $\endgroup$
    – poncho
    Jan 7, 2023 at 18:48

1 Answer 1

4
$\begingroup$

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.

$\endgroup$
1
  • 2
    $\begingroup$ One case where adding unpredictable salt at the beginning of a signed message is required is when it's used a hash which collision-resistance is broken, like SHA-1. That restores security. It's used for digital certificates when SHA-1 is the safest compatible option, where the certificate serial number is chosen randomly by the certification authority, is put in the first 64 bytes of what's signed, and doubles as salt. It's not a bad idea even for currently unbroken hashes, like SHA-256. $\endgroup$
    – fgrieu
    Mar 16, 2023 at 13:03

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.