We are implementing https with a third-vendor SSL library in our embedded system. Because of the chosen small public exponent in RSA 2048, encryption is much faster (approx 120ms) than decryption (approx 3100ms).

Could we exchange the public and the private exponent after key generation? That would shift the heavy lifting to the client (usually a PC) and makes it easier for our embedded system. I don't know, if there are some restrictions e.g. in certificate structure what forbids this.

1 Answer 1


Exchanging the public and private exponents in RSA incurs two problems:

  1. It does not work.
  2. It is insecure.

The "does not work" is about existing deployed implementations of SSL in clients. Though the formal definition of RSA allows for an arbitrarily long public exponent, some widely deployed implementations of RSA expect the public exponent to fit in a 32-bit integer (in particular, Windows' CryptoAPI).

The point about insecurity is that a too short private exponent weakens the system. An attack has been demonstrated, which shows how to recover the private key if the private exponent length is less than 29% of the modulus length; this means that if you use a 2048-bit RSA modulus (as you should), and you set the private exponent length to less than 600 bits, then an existing, already described an implemented attack applies. The collective wisdom of cryptographers is that private exponents significantly shorter than the modulus are too huge a risk.

Therefore: no, you should not try to shorten RSA private exponents, however tempting it may be.

If you are short in computing power, then you might want to investigate alternative algorithms based on elliptic curves. An "ECDSA_ECDHE" cipher suite would avoid RSA computations, and should provide substantially better performance for the TLS handshake (however, it won't be compatible with IE 8 on Windows XP as a client).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .