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.

Justin Maxwell
  • 41
  • 4
  • The shortest standard signatures are ECDSA with P-256 resulting in 32 bytes. There are some signature schmes (BLS) that drop this even further to 16 bytes with some fancy math. Smaller signatures are unlikely to be available in crypto libraries as they're likely to be trivially broken (seconds?) – SEJPM Oct 12 '15 at 16:53
  • 1
    If you require verification of signature without secret (that is, proper digital signature), 48 bits is way too little. If you can live with a secret key on both sender and verifier side, use a MAC such as HMAC. – fgrieu Oct 12 '15 at 17:08
  • 2
    I think Ultra Short Weakly Secure Signatures are the closest thing known to what you're asking about. $;;;;;;$ –  Oct 12 '15 at 17:22
  • 2
    @SEJPM Your numbers are too small by a factor of two. A 256 bit curve like P-256 (offering 128 bits of security) produces a 512 bit or 64 byte signature. BLS cuts that in half, to 32 bytes. At 16 bytes you're down to 64 bits of security, which might still be okay for some applications, especially if you throw in a proof-of-work. – CodesInChaos Oct 12 '15 at 17:37
  • 2
    I don't understand the sentence "The requirement is to provide 'tamper resistance' rather than 'unforgeable'". Tamper residence implies unforgeability, because if a a cipher is forgeable, then there is no need for a more expensive tamper attack. –  Oct 12 '15 at 21:21
  • @SEJPM thanks for pushing me down the EC road - I'm more comfortable with a slightly longer sig that with the 256bit RSA private key that we were thinking about. However, as per @ CodesInChaos, I was getting double the length sigs, so have switched to the 'smallest?' curve in OpenSSL that is outputting ~34 bytes (secp112r1) on an uninformed assumption that EC is 'better'. – Justin Maxwell Oct 13 '15 at 11:29
  • @RickyDemer From the title, that sounds exactly like what I need :-) Except for the lack of OpenSSL support ;-) – Justin Maxwell Oct 13 '15 at 11:31
  • @Cryptostasis I use these terms in the same sense as they are used offline. From your comment, I infer that 'tamper attack' has some particular cryptographic meaning, which is not what I meant to imply. Sorry for the confusion. – Justin Maxwell Oct 13 '15 at 11:34
  • @user152408 : $:$ Make sure you read the paragraph I gave the title to, rather than just other parts of the paper that paragraph is in. $;;;;$ –  Oct 13 '15 at 11:39
  • @RickyDemer I did. Apols, I should have said 'headline', not 'title'. I think I even mostly understood the first half of the paragraph. No risk of me reading the rest of the paper! :) – Justin Maxwell Oct 13 '15 at 12:04
  • 1
    Forgot that 256 bits = 32 bytes. Oops. Thx @CodesInChaos. Concerning your question according to the bear BLS is pretty optimal. You may actually be able to live with 96-bit security level, which would give you 24 byte signatures with BLS. Or if you consider your adversaries to be common people with their common desktops even 64-bit security is enough giving 16 byte signatures with BLS. And yes ECC is much better than RSA at the considered lengths. (I can break 256 bit RSA within seconds IIRC but 128-bit ECC is unbreakable for me) – SEJPM Oct 13 '15 at 12:09
  • Who is asked to need a few minutes to forge a signature? Your neighbor? Some small company? Some big company (amazon, MS, ...)? NSA? – SEJPM Oct 13 '15 at 12:10
  • 1
    @user152408 : $;;;$ (I noticed an assumption I was making, that I should check.) $:$ Do you specifically want short signatures or just want the length of the signed_message object to not be much longer than the length of the message? $:$ If the latter, then there's a much better approach. $;;;;;;;;$ –  Oct 13 '15 at 13:14
  • I shiver, when I read the combination of "rsa" and the number "256". Pretty much anything is better than that, since such a number can be factored within seconds most likely. – tylo Oct 13 '15 at 13:14

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,132
  • 5
  • 70
  • 165
  • Thanks Otis. In our application, the forging of an occasional signed document is not a concern - the energy cost probably outweighs the value - Is there somewhere I can look up how long 2^n attempts would take (on, say, a modern gaming PC) -- my googling came up empty. I'm much more concerned about the (short) private key being derived. A symmetric secret is, unfortunately, not viable for us. – Justin Maxwell Oct 13 '15 at 11:21
  • @user152408, in that case the link Ricky Demer gave in the comments would be your best bet. I haven't seen anything like that implemented in libraries, however. ($2^n$ attempts usually takes $2^{n-30}$ to $2^{n-10}$ seconds on a single computer, depending on the algorithms used.) – otus Oct 13 '15 at 12:17
  • Note that 48 bits will get really weak if the attacker applies a Time Memory Trade Off. Details depend on the actual algorithm, but a simple, and mostly wrong, back of the napkin calculation could be: 1 Terabyte drive ~ $2^{37}$ stored 48-bit values -> ~$2^11$ lookup operations per attack -> several attacks per second (for SSD) to few seconds per attack (for HDD). – Henryk Plötz Oct 13 '15 at 14:06
  • @HenrykPlotz : $:$ Can those specifically target short signatures, rather than just going after the private key? –  Oct 13 '15 at 16:14
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
  • 140,762
  • 12
  • 307
  • 587
  • The obvious argument shows that a signature must be at least $b$ bits in length to require $O(2^b)$ to forge - I don't know of a generic argument that claims it must be at least $2b$ bits in length. Could you care to elucidate? – poncho Mar 01 '22 at 13:22
  • @poncho: I don't have an articulated argument that we need at least $2b$-bit signature to resist $\mathcal O(2^b)$ effort. It's a mere observation. I clarified that. – fgrieu Mar 01 '22 at 13:48