Thank-you for your thorough answer, Dave (and sorry for the top-posting
- I wanted to have your message preserved for Felix and Rajiv).
The ica maintainer (in cc) and I were discussing if there is some value
in aborting RSA_Generate_key() used by libica to generate keys.
Libica is a crypto library used by some IBM cryptographic cards, and
it's currently used by openCryptoki (PKCS#11 layer) to support those cards.
Problem is, I don't see anywhere in the PKCS#11 spec any restriction to
what e values can be used.
So, without any checking, the PKCS#11 caller could easily trigger an
endless loop by passing even e numbers > 2.
The correct solution would be probably to implement the callback
infrastructure present in the PKCS#11 spec - so that the Cryptoki caller
could abort the operation if needed. But that would also require
changing the Libica API to include callback support in their operations.
While we're not at it, options include:
* leaving as it is - using non-standard e is caller's responsibility.
and caller thread can always be killed
* check for supplied e, (artificially?) return error if non-standard e
is being used (that is, "don't even try")
* Implement the suggested callback in Libica. Use a Callback to abort
RSA_Generate_key_ex() after a certain number of steps or cpu time.
-Klaus
On 09/28/2009 09:16 PM, Dave Thompson wrote:
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
--
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