I'm wondering if considerations of key-length are different when thinking about signing vs encryption. If for some reason, it was safter to use smaller keys for signing that would be interesting.


No, the security is about identical, as the underlying RSA problem is the same.

Besides that, non-repudiation is usually managed differently with regards to legal requirements. Providing confidentiality (encryption) is a rather different use case than non-repudiation (signing a contract).

It is also possible to use signatures for authentication rather than non-repudiation. In that case you may be able to get away with smaller signatures if the authentication and key is only valid for a limited amount of time.

All in all, the key strength should be considered given the use cases, threat model and of course the system parameters. Defining a minimum RSA key size without considering the system is not a good idea.


  • It could be possible to assign a notary that immediately signs the document after signature generation by the other party. The notary should of course use a key of sufficient strength.
  • I've used the notion of a larger key, but what you're really after is a stronger key. Usually larger keys are stronger for the same algorithm though.
  • If you go over a 16Ki key size then the key size doesn't matter much anymore. The key will only be broken if RSA itself is broken (e.g. using a hugely powerfull Quantum Computer).
  • 2
    $\begingroup$ There is a reason sometime given to use longer/stronger keys for encryption of things that are intended to remain secret "forever"; when often, signatures become pointless after a shorter time. $\endgroup$ – fgrieu Apr 4 '16 at 11:56
  • $\begingroup$ @fgrieu Yeah, the use case and thread model should define the required key strength. But if the ciphertext is available to the entity that posesses the private key it is at least possible to upgrade the key strength by re-encrypting or adding another layer of encryption. $\endgroup$ – Maarten Bodewes Apr 4 '16 at 11:59
  • 1
    $\begingroup$ I thing that you mean the other way around. It is always possible to re-sign the original message with a stronger key, and that gives the signature the strongest strength; but re-enciphering the original secret message with a stronger key is pointless if the adversary has the cryptogram made with the weaker one. $\endgroup$ – fgrieu Apr 4 '16 at 12:00
  • $\begingroup$ Yeah, that does depend on leaking the ciphertext - you're right about that. But with signing it may be that you don't have the right to sign. Often signing is performed by another party (not always of course, but it is pretty common). I'll remove that paragraph, it requires too much knowledge about the system anyway, and the system hasn't been defined. Use strong keys, it saves a lot of headaches :) $\endgroup$ – Maarten Bodewes Apr 4 '16 at 12:02
  • 1
    $\begingroup$ @BT not remotely close. The only numbers in that keylength.com page relevant to RSA are the column labelled Factoring, and after 2040 is level 8 which is 15424. $\endgroup$ – dave_thompson_085 Apr 4 '16 at 20:59

The best-known method of breaking RSA is to factor the modulus. Once factored the attacker cna use the resulting factors to rebuild the private key and can perform signing and encryption with equal ease. So it's reasonable to say that as faar as we know the key length required for a given level of break-resistance is the same for signing and encryption..

However that is only one side of the story, the other side of the story is what happens if the key is compromised.

Take ssl/tls for example, it uses RSA keys for three things.

  1. Signing certificates.
  2. Signing key exchanges for DHE and ECDHE ciphersuites
  3. Encrypting the main shared secret for tradtional RSA cipher

For 1 and 2 the keys only have to remain secure for as long as the certificates remain valid. OTOH for 3 the keys need to remain secure for as long as the data needs to be kept secret.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.