> From: owner-openssl-us...@openssl.org On Behalf Of Klaus Heinrich Kiwi > Sent: Friday, 25 September, 2009 13:02
> On 09/23/2009 07:59 PM, Dave Thompson wrote: > > 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. > UTSL. Apparently it's been enhanced, but not in the man page. The (obviously legacy) RSA_generate_key and BN_generate_prime take a void-returning callback. Their declarations are marked deprecated, and are implemented in rsa_depr.c and bn_depr.c as jackets which just set up a BN_GENCB and call (obviously newer) _ex versions. The _ex versions use the fields in BN_GENCB to call either an old void-returning callback (treated as returning 1 aka true) or a new int-returning callback whose return value if false (0) causes RSA_generate_key_ex or BN_generate_prime_ex as applicable to return immediately with an error. (0,..) and (1,..) are called (per the man page) for candidates that may not even be prime. (2,..) is (per the man pages) called ambiguously: by BN_ for a prime* found, and also by RSA_ for a prime* rejected as having common factors with e. (3,0,) and (3,1,) are called by RSA_ for primes accepted. (* actually 'very-very-highly-probable-prime' IIUC) You might look for (2,?,) followed by (2,0,) but not (3,0,). But even for reasonable e like 65537 there is some chance of one reject; you might look for a second reject (2,?,)(2,1,). You might also look for rejects on q, after (3,0,) until (3,1,); but stupid e will almost certainly lose on p before trying q. Alternatively, or in addition, you might look for *time* (CPU if available, or elapsed if your process will reliably not get starved) exceeding whatever you think is a reasonable absolute outer limit on your machine, like 10sec or 1min. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
