# Do I need to send the RSA public exponent with the public key?

I used RSA to provide confidentiality for a protocol. As I know the public key of RSA has two values: $e$ and $n$. Of these two, $e$ usually has value 65537.

When the public key is sent, does the sender need to send $e$ and $n$ or just $n$?

RSA key pair generation can be performed with a static $e$ or with an $e$ that is calculated after the private key has been calculated. Generally software chooses to perform the calculation using a set public key, the fifth prime of Fermat (F4 where 4 is the index) with that value 65537 (0x010001 in hexadecimals).

For compatibility reasons it is generally preferred to allow more values than just F4, even if your own software only uses F4 for key pair generation. However if you are writing your own closed protocol then setting a static value such as F4 for $e$ is perfectly fine. Note that you may however still preclude some (admittedly weird) libraries / hardware solutions that generate random 16 bit values of $e$.

The RSA public key format is specified in PKCS#1. Most libraries will able to handle this key format and/or the SubjectPublicKeyInfo format found in X.509 certificates (this format contains the PKCS#1 format, but additionally indicates the type of key). So one advantage of leaving it in there is direct software support. Furthermore, you are also freed from thinking about how to encode the modulus & length of the modulus (in case multiple key sizes need to be supported).

Here is the ASN.1 module from PKCS#1 Appendix C:

RSAPublicKey ::= SEQUENCE {
modulus           INTEGER,  -- n
publicExponent    INTEGER   -- e
}


So even if you do only use one value, it is a question if you don't want to send the value of $e$. In the end you'll just save 3 bytes not calculating overhead and to 9 to 12 bytes if you include all the ASN.1 overhead that is required to split the modulus and the exponent. If space is at a premium you may want to switch to elliptic curve cryptography (ECDH or ECIES) because of the smaller key sizes.

• Are there any popular libraries out there which actually use a random $e$? – forest Aug 18 '18 at 3:07
• @forest I used an HSM that defaulted to a 16 bit value for $e$ – Maarten Bodewes Aug 18 '18 at 3:23

The big question is e always 65537, or just usually 65537? In particular, what happens if someone wants to use e equal to 17 or 737452189? While 65537 is a common value for e, both of these other values for e are valid (subject to the usual constraints), but if you send only n, these alternate values of e would cause the system to fail since the sender would use the wrong exponent.

Also, if you are using (for example) a 2048-bit n, are you worried about adding another 32 (or so) bits for a typical e?

• Also, if you are using (for example) a 2048-bit n, are you worried about adding another 32 (or so) bits for a typical e?, What do you mean? As I know the typical e is 56637 – Aymn Alaney Aug 18 '18 at 8:52
• On your first point, the value of e is small relative to n in most cases. So with a 2048-bit n, then adding a 32-bit e makes a total of 2080 bits.As far as a typical e, do you KNOW that no other values will occur, or is it possible (even if rare) that other values of e might occur? – Eugene Styer Aug 18 '18 at 13:12