4

Our application requires some 'mild' form of 'proof of origin' for the tokens we issue (~200 bytes), however, the value of each is trivial. The requirement is to provide 'tamper resistance' rather than 'unforgeable', to not bloat the token size, and to use commonly available 'standard' libraries and tools.

In the token, we include a hash of the request we received, and I understand we can crop this down to the last n (e.g. 48) bits easily enough, and do the same with the token hash/digest before signing.

Is something similar possible with the signature, or do we need to just generate the smallest key and a tiny digest to get the output as small as possible?

I've been mucking about with openssl rsautl - is this as good as any other given our requirements as above? The signatures are coming out at ~24 bytes, I'd like to reduce that a bit further if possible.

EDIT TO ADD

For us, the ability to forge a single signature within a few minutes is perfectly fine, sub-minute is getting problematic. The ability to derive our private key, and subsequently bulk-produce counterfeit signatures with negligible time/energy cost is the primary risk.

With the advice of those below I've been looking at ECDSA and the secp112r1 OpenSSL built-in curve, assuming that is better than a 256bit RSA primary key.

2 Answers2

2

Suppose you have an asymmetric algorithm that creates a 48-bit signature. Then an attacker can simply test possible 48-bit signatures and find one that verifies in $2^{47}$ tries on average. Even with a relatively slow asymmetric algorithm that would be feasible, especially if the attacker can test the same signature for multiple tokens. And that is only a brute force attack, asymmetric systems usually allow much faster attacks.

If you can establish a symmetric secret, even a short MAC is much better, because while the attacker still has a $2^{-48}$ probability of success with a random guess, they can no longer verify those guesses offline.

otus
  • 32,462
  • 5
  • 75
  • 167
2

A similar (later) question asks:

what digital signature schemes can be used to generate a small signature of 16-32 bits only?

None. Any Digital Signature that size would be insecure. Elementary argument: the mere fact that the verification procedure is public (the defining property of Digital Signature) allows to forge a $b$-bit signature with at most $2^b$ signature verification operations. And that's far from the best attack in practice.

Based on known signature schemes, it seems we need at least $2b$-bit signature to resist $\mathcal O(2^b)$ effort (I have no articulated argument to prove that must hold for any signature scheme, though). BLS signature, the most compact we have, only approaches that threshold. Even with 128-bit signature, recovering a private key from a public key is feasible with modest means. That then allows to compute a signature of anything as fast as the legitimate holder of the private key does.

Any signature which is strong enough to not be broken within few nanoseconds at hardware level is fine for my application which is time critical.

The fact the question's signatures are short-lived does not help against attacks that recover the private key. What would help to a small degree is that keys would be short-lived, but that's not practical.

For authentication with 32-bit cryptogram or lower, only symmetric cryptography is possible. That requires a secret on the verifying side. That's Message Authentication Code, not Digital Signature, and does not match any of the question's tag.

fgrieu
  • 149,326
  • 13
  • 324
  • 622