On 09/23/2009 07:59 PM, Dave Thompson wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Klaus Heinrich Kiwi
Sent: Wednesday, 23 September, 2009 15:59
I noted that when generating a RSA public key pair using a
non-standard public exponent (particularly, 65538, or 0x01,
0x00,0x02), the RSA_generate_key never returns, and the
program keeps using 100% CPU until I kill it.
My question is: Is this behavior expected? If some non-standard publ.
exponent is problematic, shouldn't we abort with error before
attempting to use it?
RSA doesn't work if e (or d) has any common factors with phi(m)
= IIRC LCM(p-1,q-1). If this happens, the code just tries again.
Thanks for the clarification, Dave.
This means there are no p,q for which any even e can work,
hence the infinite loop. As mentioned on the man page, BTW.
For an e with a factor small but greater than 2, many p,q
won't work but some will. Is this a desirable case? I don't know.
The popular standard e (3 and 65537) were chosen to be (odd) primes
and for the latter the chance of a keygen try failing is tiny.
Or, to put it in another way, should the caller validate the
public exponent before issuing RSA_generate_key(), to avoid a
potential DoS?
If you're going to accept e from an untrustworthy source, probably.
Or it appears you can use the callback to impose a limit on the
number of tries, amount of time, etc. as you consider appropriate.
I see now that the manual describes a callback that is called upon each
step in the key generation process.
In order to abort the RSA_generate_key() after a number of retries,
first question would be if there is a way we could abort
RSA_generate_key() from within the callback. The manual isn't very clear
in this matter.
Secondly, it's still not clear to me if we should count the number that
callback(0, ..), callback(1, ...), callback(2, ...) are called
individually, or a combination of those, or both.
If you allow large e (any significant fraction of the modulus size)
it might be a covert channel for the keygen-requestor to leak info
(if the requestor is malicious against its owner, apparently not
you if you are worried about attacks by the owner against you).
I'd also worry whether there is a way for malicious requestor
to choose e such that it assists or enables later side-channel
attacks against encryptors or verifiers using the resulting
publickey, but I don't know enough to analyze for that.
I wouldn't worry right now about validating the caller input, but my
concern is if we must do some additional checking to make sure the
generated key has any weakness if we pin e to 3 or f4 (I remember
reading something about needing to double-check the key if we always use
e=3)
-Klaus
--
Klaus Heinrich Kiwi | kla...@br.ibm.com | http://blog.klauskiwi.com
Open Source Security blog : http://www.ratliff.net/blog
IBM Linux Technology Center : http://www.ibm.com/linux/ltc
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
