1

I'm trying to figure out how it is composed the RSA key. Follow what I know :

  • For a RSA 2048, 2048 is the bit length of the module.

  • The public key is composed by $(e,M)$ when $e$ is the public exponent and $M$ is the module.

  • The private key is composed by $(d,M)$ when $d$ is the private exponent and $M$ is the module.

Now, I tryed to find info about the standard bit lentght of the exponent without lack. Does anyone have info ? I need to define the max value that $d$ and $e$ can reach. I think that it useless to have the same exponent bit lenght of the module. Is it right ?

haster8558
  • 227
  • 3
  • 8
  • It should be noted that, if an arbitrary message of size of n bits is to be processed by RSA, the modulus M must be chosen to be greater than 2**n. – Mok-Kong Shen Feb 24 '15 at 11:30
  • Well, I think that I could also divide the message to get more than one crypted messages. – haster8558 Feb 24 '15 at 11:40
  • @Mok-Kong Shen: $2^n<M$ where $n$ is the message size in bits, and $M$ the public modulus, applies to Textbook RSA, which is insecure in many use cases, and in good practice mostly used for largely random messages. It does NOT apply to secure versions of RSA used in practice, like RSAES-PKCS1-V1_5 or RSAES-OAEP, which have a significantly smaller message capacity $n$ for a given modulus $M$. And that does not apply to hybrid encryption (as used in practice for any sizable message), where the message size $n$ is practically unconstrained. – fgrieu Feb 24 '15 at 11:43
  • @haster8558: No, you should not "divide the message to get more than one crypted messages", see e.g. this. Use hybrid encryption. – fgrieu Feb 24 '15 at 11:45
  • 1
    @fgrieu I know that, for example, ssh work with hybrid encryption, RSA for key exchange and AES for communication. But actually I don't need to encrypt/decrypt more than plain/cypher message. I need only a system to authenticate ( I could use HMAC, but it doesn't like to my supervisors ), so there isn't the need to use a hybrid encryption. Thanks for the help – haster8558 Feb 24 '15 at 11:54
  • Right. Notice that for RSA signature verification, $e$ can be small ($3$ or $65537$) and software on a modern 32-bit CPU (rather than anything done in VHDL) is typically adequately fast. In either case you want signature padding, e.g. RSASSA-PKCS1-V1_5 or RSASSA-PSS or ISO/IEC 9796-2, which is almost exclusively done in software, except for the hashing part. – fgrieu Feb 24 '15 at 12:03
  • @fgrieu: I was worrying that one might have different interpretations of "a number of n bits". A number with bits e.g. "1001" would be called by someone as a 4-bit number but it is less then 2**4. I just wanted to call to the fact that, in case one uses that interpretation, then a n-bit M could be less than 2 to the power n and processing a block having n bits could fail to work in the RSA equations. – Mok-Kong Shen Feb 25 '15 at 18:00

1 Answers1

-1

Generally speaking, the bit length of the exponents are the same as the modulus. Depending on the implementation, there may also be some extra data in the public/private key structure.

Here is a good discussion on the concept of key length as it relates to the public/private values: Private key length bytes

Community
  • 1
Sean Kornish
  • 122
  • 1
  • @Haster8558: Beware, this answer is wrong in practice: in most actual use of RSA, the public exponent is small; most often $65537$, or $3$, $5$, $17$, or within some limit; I have seen such limits of $2^{32}$, $2^{64}$, $2^{128}$, $2^{256}$. In particular the later limit is enforced in FIPS 186-4, thus many HSMs. – fgrieu Feb 24 '15 at 11:32
  • 1
    Ok, the public exponent is usually small, but I need to decrypt too, so I need that exponent of my VHDL module is big enough ( same core for decrypt and encrypt ). – haster8558 Feb 24 '15 at 11:38
  • @haster8558: Right for private key in $(M,d)$ form. But if you care for speed or power, you'll want to support RSA with CRT when doing the part (use of private key) that requires large exponents; the potential savings approaches a factor of 4 with common RSA keys (the aforementioned FIPS 186-4). $;$ If you care for security, you'll have to study if your threat model requires protection against at least fault attacks, timing attacks, power analysis and other variants of side-channel attacks. – fgrieu Feb 24 '15 at 11:49
  • 1
    @fgrieu The only problem with Chinese reminder algo is that I have to save also $p$ and $q$ and at the end I need to perform an addition. I don't know the effect on area occupation. I need to check the free area in FPGA – haster8558 Feb 24 '15 at 12:05
  • 1
    @haster8558: In many hardware implementations of RSA using CRT, the recombination after exponentiation is performed in software, and still does not dominate the execution time. CRT may actually significantly reduce silicon requirement for a given public modulus size, since all quantities manipulated in the time-critical part are only half as wide as in regular RSA (assuming balanced primes as in FIPS 186-4); that will be the case if there's hardware to make modular multiplication over the full modulus width. $;$ Another design choice will be using Montgomery arithmetic, or regular one. – fgrieu Feb 24 '15 at 12:24
  • Actually I already use the montgomery for modular multiplication. Now I'm looking for a way to make the modular exponetiation using the montgomery. Maybe the CRT could be a very good solution, because I have enough available DSP module in FPGA. – haster8558 Feb 24 '15 at 12:41
  • @haster8558, I confirm fgrieu advices, that CRT mode requires less memory occupation with a theorical gain of 400% in performances in execution. Implementing Montgomery arithmetic is certainly the best choice as it avoid long modular reduction and allows parallel computation. However be aware that operands in this mode, must beforehand be converted in a special N-residue representation, and post processing requires to return back to regular representation. – Robert NACIRI Feb 24 '15 at 15:04
  • @RobertNACIRI Maybe I'm wrong, but I can use both to gain in performances. About the conversion I've found it's a zero cost area operation because I have to multiply the inputs with a precomputed constant ( $2^{(2*k)} \mod n $ with $k$ the bit length of operands and $n$ the module ) using Montgomery multiplier. Am I wrong ? – haster8558 Feb 24 '15 at 15:16
  • @haster8558, No You're right if you precompute the constant $R^2 = 2^{2.k} ; mod ; N$. Conversion to N-Residue is performed by a Montgomery multiplication of the operand data with $R^2$ while converting back to regular representation consists in Montgomery multiplying N-Residue with the constant 1. If you perform CRT mode, there is a additionnal trick to observe to be performant in conversion. – Robert NACIRI Feb 24 '15 at 16:14
  • Montgomery arithmetic's main advantages are 1) Quotient estimation is easier 2) Estimated quotient is always right, thus not exceptional case is needed, which is great from the perspective of resisting timing attacks (but beware of other timing dependencies during the extra steps) 3) It's slightly easier to perform multiplication and reduction without a wide intermediary result than with natural arithmetic. $;$ But it does NOT significantly lower the multiplications of elementary words, or the size of operands, compared to natural arithmetic; and does NOT pay for the public-key operation. – fgrieu Feb 24 '15 at 18:58