Re: [openssl.org #86] Bug in RSA_check_key
Indeed it would be a good idea, especially for RSA_generate_key, since people have to generate their key thru an interface that is extern to OpenSSL, then sign their CSR with that key using OpenSSL, when everything could be implemented within OpenSSL. The major benefit would come for, a PKI architecture based on OpenSSL, imagine a CA tree, if I want the key of the ROOT CA, the SUB-CAs to be stocked in a hardware device, you can't make it thru OpenSSL, and it become a pain in the butt if your architecture is managed thru the network, you will have to physically go on the CA computer, to generate each of the SUB-CAs keys. --- Geoff Thorpe via RT [EMAIL PROTECTED] wrote: Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. [snip] Richard just added a couple of notes to the documentation at the same time I was working on it. I may or may not put my changes over the top of his yet, but in the mean time ... I think the ultimate solution to this problem will be similar to the ultimate solution to the problem of generic key generation - ie. key generation that is independant of the ENGINE implementation being used. When you think about the underlying problem, the solution is rather obvious (but perhaps annoying to implement); the basic problem is that RSA_generate_key() and RSA_check_key() both directly deal with structure elements rather than using members of the RSA_METHOD vt. If RSA_public_decrypt() did the same thing, it would have the same problem of not working with replacement RSA implementations. I think the check_key functionality needs to go into a handler callback in the RSA_METHOD itself so that any implementation that alters the way key material is stored and managed can similarly implement a corresponding mechanism for verifying key integrity. In the mean time, the short-term solution (bear in mind this will break binary compatibility to some extent and will require all ENGINEs to be adapted) is to alter the documentation to describe the situation. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ Post your ad for free now! http://personals.yahoo.ca __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
For now, I've added a note in the documentation of RSA_check_key() that explains that it doesn't work properly for hard keys and why. We will ponder a little more on this issue. [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: It wouldn't take much to make this function compatible, or the others that I haven't used and that have the same problem, maybe create a new flag for the RSA keys, I already use RSA_FLAG_EXT_PKEY, what about something like RSA_FLAG_ENGINE_PKEY, I imagine that it would force peoples to modify there code for their engines, to add this flag when they load a key. Actually, there's no reason to add yet another flag, since RSA_FLAG_EXT_PKEY is designed to point out that the key is stored externally (the comment in rsa.h explicitely mentions external hardware). -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. [snip] Richard just added a couple of notes to the documentation at the same time I was working on it. I may or may not put my changes over the top of his yet, but in the mean time ... I think the ultimate solution to this problem will be similar to the ultimate solution to the problem of generic key generation - ie. key generation that is independant of the ENGINE implementation being used. When you think about the underlying problem, the solution is rather obvious (but perhaps annoying to implement); the basic problem is that RSA_generate_key() and RSA_check_key() both directly deal with structure elements rather than using members of the RSA_METHOD vt. If RSA_public_decrypt() did the same thing, it would have the same problem of not working with replacement RSA implementations. I think the check_key functionality needs to go into a handler callback in the RSA_METHOD itself so that any implementation that alters the way key material is stored and managed can similarly implement a corresponding mechanism for verifying key integrity. In the mean time, the short-term solution (bear in mind this will break binary compatibility to some extent and will require all ENGINEs to be adapted) is to alter the documentation to describe the situation. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
OK, I'm going to close this ticket down now as we have at least solved the bug, albeit that it was a bit of a short-cut ... we documented the existing behaviour rather than changing it :-) If anyone feels strongly that this is not resolved until RSA_check_key() is modified to use a new RSA_METHOD handler (ie. to allow verification of special keys), then please consider opening a new ticket without the word bug in it - it's a feature request. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
Indeed it would be a good idea, especially for RSA_generate_key, since people have to generate their key thru an interface that is extern to OpenSSL, then sign their CSR with that key using OpenSSL, when everything could be implemented within OpenSSL. The major benefit would come for, a PKI architecture based on OpenSSL, imagine a CA tree, if I want the key of the ROOT CA, the SUB-CAs to be stocked in a hardware device, you can't make it thru OpenSSL, and it become a pain in the butt if your architecture is managed thru the network, you will have to physically go on the CA computer, to generate each of the SUB-CAs keys. --- Geoff Thorpe via RT [EMAIL PROTECTED] wrote: Just attaching a little more state to this ticket ... [[EMAIL PROTECTED] - Wed Jun 19 09:52:27 2002]: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. [snip] Richard just added a couple of notes to the documentation at the same time I was working on it. I may or may not put my changes over the top of his yet, but in the mean time ... I think the ultimate solution to this problem will be similar to the ultimate solution to the problem of generic key generation - ie. key generation that is independant of the ENGINE implementation being used. When you think about the underlying problem, the solution is rather obvious (but perhaps annoying to implement); the basic problem is that RSA_generate_key() and RSA_check_key() both directly deal with structure elements rather than using members of the RSA_METHOD vt. If RSA_public_decrypt() did the same thing, it would have the same problem of not working with replacement RSA implementations. I think the check_key functionality needs to go into a handler callback in the RSA_METHOD itself so that any implementation that alters the way key material is stored and managed can similarly implement a corresponding mechanism for verifying key integrity. In the mean time, the short-term solution (bear in mind this will break binary compatibility to some extent and will require all ENGINEs to be adapted) is to alter the documentation to describe the situation. Cheers, Geoff -- Geoff Thorpe, RT/openssl.org __ Post your ad for free now! http://personals.yahoo.ca __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
Calling all algebraic coders ... [snip] I would suggest the following for checking RSA public keys: 1) that the public exponent e satisfies 3 = e n and that e is odd (PKCS#1) [this doesn't prevent low exponent attacks however] 2) that the modulus n is not a probable prime (e.g., apply 80 rounds of Miller-Rabin) 3) that n is not divisible by small primes 4) that n is not a perfect power 5) that n provides a suitable setting for the factoring problem (e.g., |n| 512 bits or 768 bits, etc.), and give a warning if it is not. I am working on some code which I hope to donate to OpenSSL that accomplishes (4) and more... Yay, thanks. Adam, have you had any joy with code for this? Until we find an adequate replacement/supplement for RSA_check_key() that *does* behave in transparent manner w.r.t. ENGINEs, I'm thinking that the best interim solution to this problem (and the RT ticket) would be in two parts; (1) the documentation. Ie. to note that RSA_check_key() is *not* a function that works transparently with any RSA key type / ENGINE implementation. This could go into 0.9.7-stable too if it makes it in time for the release, as it would hopefully reduce the number of times this bug-report comes up before 0.9.8 gets released :-) (2) check whether rsa-engine is non-NULL and if so, and *any* of the private key/CRT components are missing, return an error code such as RSA_R_CAN_NOT_CHECK_ENGINE_KEY. This approach would assume that any embedded/opaque key supported by an ENGINE wouldn't populate all the private key elements (ie. HSMs shouldn't need to use d, p, q, dmp1, dmq1, iqmp). BTW: this change could only go into the HEAD (ie. not in time for 0.9.7). Thoughts from anyone? Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
Hi there, On Wed, 19 Jun 2002, Giudicelli Frédéric via RT wrote: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. The problem is RSA_check_key() is not a general transparent RSA function, it's designed (it would seem) to check that all the values in an RSA key structure are valid relative to one-another. This violates encapsulation and completely ignores the use of RSA_METHOD, so together that's where the transparency is broken. In general cases, where the RSA object could represent an HSM-protected key or just a public key, virtually all of those internal structure elements become redundant - and not necessarily NULL (an ENGINE implementation is free to store any values it likes in the structure elements, as long as the handler functions do their job properly). By consequence, there remains very little that you could actually *check* inside the RSA key structure in the general case! OTOH: You could test that the RSA object behaves normally by calling various RSA functions with various inputs and checking that you can't trip it up. These should all work (in theory) because those RSA functions (encrypt, decrypt, etc) would delegate to the implementation function pointers. So in the case of HSM keys, the ENGINE code would be performing the key operations anyway so it wouldn't matter whether or not rsa-dmq1 was NULL or whether rsa-flags included RSA_FLAG_EXT_PKEY, etc. This is I guess your point about being transparent. I simply don't think RSA_check_key() should be called except by programs that manipulate RSA structures already - eg. converters between different key formats (eg. PGP/ssh/... key importers, key file readers, alternative key-generation implementations, etc). If you want to contemplate an external way of testing RSA keys - ie. simply by performing operations with them - then that would certainly be more what you're looking for. Feel free to suggest an implementation :-) I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. Again, you are really looking for a different sort of function to what RSA_check_key() is/does. I'm supposed to be able to call any RSA API with a hardware key, but I can't, so I don't know if it's bug or a conception problem on engines layer. This probably needs a documentation change to avoid similar misunderstandings in future. It wouldn't take much to make this function compatible, or the others that I haven't used and that have the same problem, maybe create a new flag for the RSA keys, I already use RSA_FLAG_EXT_PKEY, what about something like RSA_FLAG_ENGINE_PKEY, I imagine that it would force peoples to modify there code for their engines, to add this flag when they load a key. *Maybe* ... but even then it doesn't solve the case of public keys. Moreover, how do you actually test a public key? What does check actually mean in this case? This problem will probably show up for DSA, DH, DES keys aswell. Perhaps - but again, I think you're assuming RSA_check_key() to mean something far more generic than it actually does, and I perfectly understand why you might misinterpret it that way too. I think a new function is required to test keys via transparent operations, perhaps RSA_is_valid()? Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
Date sent: Thu, 20 Jun 2002 15:02:36 -0400 (EDT) From: Geoff Thorpe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject:Re: [openssl.org #86] Bug in RSA_check_key Send reply to: [EMAIL PROTECTED] Just my two cents on the engine code in general. Months ago I discussed with one of the OpenSSL team members how to use the engine code in OpenSSL to enable Smart Card/USB RSA key processing for TLS and SSH client authentication for those certificates/private keys contained within the Windows based Netscape and Microsoft browser stores/databases, and private keys that could not be removed from the Smart Cards/USB tokens. I implemented the ideas presented to me, and they work great for TLS, SSH-1 and SSH-2 public/private key authentication. Many times since then I have been asked by our clients that knew we used OpenSSL internally for all of our crypto support how we was able to get OpenSSL to utilize the private keys located on the Smart cards, and how we utilized the CA certificates contained within the browsers with OpenSSL. There has been some discussion recently about the direction of the engine code, and of a generic PKCS11 interface. I would think that a large number of Windows based users/developers would benefit by a real simple high level API that provides these services without having to understand anything about the engine details or by using PKCS-11 at all. Let Netscape worry about the PKCS-11 details, and Microsoft OS worry about the CAPI stuff. It would make an already superior crytpo toolkit, even better. Ken Hi there, On Wed, 19 Jun 2002, Giudicelli Frédéric via RT wrote: The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. The problem is RSA_check_key() is not a general transparent RSA function, it's designed (it would seem) to check that all the values in an RSA key structure are valid relative to one-another. This violates encapsulation and completely ignores the use of RSA_METHOD, so together that's where the transparency is broken. In general cases, where the RSA object could represent an HSM-protected key or just a public key, virtually all of those internal structure elements become redundant - and not necessarily NULL (an ENGINE implementation is free to store any values it likes in the structure elements, as long as the handler functions do their job properly). By consequence, there remains very little that you could actually *check* inside the RSA key structure in the general case! OTOH: You could test that the RSA object behaves normally by calling various RSA functions with various inputs and checking that you can't trip it up. These should all work (in theory) because those RSA functions (encrypt, decrypt, etc) would delegate to the implementation function pointers. So in the case of HSM keys, the ENGINE code would be performing the key operations anyway so it wouldn't matter whether or not rsa- dmq1 was NULL or whether rsa-flags included RSA_FLAG_EXT_PKEY, etc. This is I guess your point about being transparent. I simply don't think RSA_check_key() should be called except by programs that manipulate RSA structures already - eg. converters between different key formats (eg. PGP/ssh/... key importers, key file readers, alternative key-generation implementations, etc). If you want to contemplate an external way of testing RSA keys - ie. simply by performing operations with them - then that would certainly be more what you're looking for. Feel free to suggest an implementation :-) I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. Again, you are really looking for a different sort of function to what RSA_check_key() is/does. I'm supposed to be able to call any RSA API with a hardware key, but I can't, so I don't know if it's bug or a conception problem on engines layer. This probably needs a documentation change to avoid similar misunderstandings in future. It wouldn't take much to make this function compatible, or the others that I haven't used and that have the same problem, maybe create a new flag for the RSA keys, I already use RSA_FLAG_EXT_PKEY, what about something like RSA_FLAG_ENGINE_PKEY, I imagine that it would force peoples to modify there code for their engines, to add this flag when they load a key. *Maybe* ... but even then it doesn't solve the case of public keys. Moreover, how do you actually test a public key? What does check actually mean in this case? This problem will probably show up for DSA, DH, DES keys aswell. Perhaps - but again, I think you're assuming RSA_check_key() to mean something far more generic than it actually does, and I perfectly understand why you might misinterpret it that way too. I think a new function is required to test keys via
Re: [openssl.org #86] Bug in RSA_check_key
From: Geoff Thorpe [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [openssl.org #86] Bug in RSA_check_key Date: Thu, 20 Jun 2002 15:02:36 -0400 (EDT) . *Maybe* ... but even then it doesn't solve the case of public keys. Moreover, how do you actually test a public key? What does check actually mean in this case? . Cheers, Geoff I would suggest the following for checking RSA public keys: 1) that the public exponent e satisfies 3 = e n and that e is odd (PKCS#1) [this doesn't prevent low exponent attacks however] 2) that the modulus n is not a probable prime (e.g., apply 80 rounds of Miller-Rabin) 3) that n is not divisible by small primes 4) that n is not a perfect power 5) that n provides a suitable setting for the factoring problem (e.g., |n| 512 bits or 768 bits, etc.), and give a warning if it is not. I am working on some code which I hope to donate to OpenSSL that accomplishes (4) and more... Adam Young _ Send and receive Hotmail on your mobile device: http://mobile.msn.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
Hi, On Thu, 20 Jun 2002, a y wrote: *Maybe* ... but even then it doesn't solve the case of public keys. Moreover, how do you actually test a public key? What does check actually mean in this case? . Cheers, Geoff I would suggest the following for checking RSA public keys: 1) that the public exponent e satisfies 3 = e n and that e is odd (PKCS#1) [this doesn't prevent low exponent attacks however] 2) that the modulus n is not a probable prime (e.g., apply 80 rounds of Miller-Rabin) 3) that n is not divisible by small primes 4) that n is not a perfect power 5) that n provides a suitable setting for the factoring problem (e.g., |n| 512 bits or 768 bits, etc.), and give a warning if it is not. I am working on some code which I hope to donate to OpenSSL that accomplishes (4) and more... Yay, thanks. BTW: If you have any thoughts about how to test a full keypair using higher-level operations, that would help too. :-) We can pretty much always assume 'n' and 'e' are structurally intact, no matter what kind of ENGINE you happen to have lurking around (for one thing, it would probably break lots of ssl/ code if this were not the case). Beyond that however, you can't really guarantee much in the general case except that the RSA_[public|private]_[de|en]crypt() functions should generally work correctly according to wherever the genuine key elements are (HSM, remote, smart-card, stored in alternative format, etc). Obviously, we could test that (n,e) and (n,d) invert one another for any given 0xn, but whether that combined with your public-key tests would suffice ... I'm not sure. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
I'll second that. OpenSSL works excellently in isolation, but when you come to use it in a context in which there are *already* keys and certificate stores (eg. CAPI) it would be excellent to be able to access those directly, so that our software has the same familiar quirks as Microsoft's, and the relevant data are already there and users don't have to do anything extra to use our software as opposed to the existing web browsers. Would your implementations cover this sort of area? If there's anything I can do in terms of testing (or even possibly coding), let me know. At 14:37 20/06/02 -0500, you wrote: Date sent: Thu, 20 Jun 2002 15:02:36 -0400 (EDT) From: Geoff Thorpe [EMAIL PROTECTED] To:[EMAIL PROTECTED] Subject: Re: [openssl.org #86] Bug in RSA_check_key Send reply to: [EMAIL PROTECTED] Just my two cents on the engine code in general. Months ago I discussed with one of the OpenSSL team members how to use the engine code in OpenSSL to enable Smart Card/USB RSA key processing for TLS and SSH client authentication for those certificates/private keys contained within the Windows based Netscape and Microsoft browser stores/databases, and private keys that could not be removed from the Smart Cards/USB tokens. I implemented the ideas presented to me, and they work great for TLS, SSH-1 and SSH-2 public/private key authentication. Many times since then I have been asked by our clients that knew we used OpenSSL internally for all of our crypto support how we was able to get OpenSSL to utilize the private keys located on the Smart cards, and how we utilized the CA certificates contained within the browsers with OpenSSL. There has been some discussion recently about the direction of the engine code, and of a generic PKCS11 interface. I would think that a large number of Windows based users/developers would benefit by a real simple high level API that provides these services without having to understand anything about the engine details or by using PKCS-11 at all. Let Netscape worry about the PKCS-11 details, and Microsoft OS worry about the CAPI stuff. It would make an already superior crytpo toolkit, even better. Ken __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
The problem is that the use oF engines should be totaly transparent to the higher API, but apparently it's not. I don't call RSA_check_key for a hardware key, I call it for my CA private key, and I don't know if it's a hardware or software key since it's transparent. I'm supposed to be able to call any RSA API with a hardware key, but I can't, so I don't know if it's bug or a conception problem on engines layer. It wouldn't take much to make this function compatible, or the others that I haven't used and that have the same problem, maybe create a new flag for the RSA keys, I already use RSA_FLAG_EXT_PKEY, what about something like RSA_FLAG_ENGINE_PKEY, I imagine that it would force peoples to modify there code for their engines, to add this flag when they load a key. This problem will probably show up for DSA, DH, DES keys aswell. Frédéric Giudicelli ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
Hi there, I've taken ownership of this ticket (#86) for now, but I don't think it'll last long. IMHO, this bug is not a bug. If you look at the implementation of RSA_check_key() you'll realise that this function is designed to test an RSA key structure - not just the essential key elements (n,e,d) but all the performance-enhancing extras too; the primes and the CRT bits. This function is not useful on public keys nor is it useful on HSM keys, for obvious reasons. Why are you calling this function when using a hardware key? If you want to provide a convincing argument for why an alternative key check function might be useful, we could perhaps look at supplementing the API insteal. Eg. are you looking for something like; RSA_check_public_key()? Right now I can't see the current behaviour of RSA_check_key() as representing a bug. It may not be intuitive, but I'm reluctant to change the behaviour of the existing API function (breaking compatibility) for that reason alone. I have changed the status of this ticket to 'stalled', but will refrain from closing it for now. OTOH: if you agree with my interpretation, please let me know and I'll close this. Regards, Geoff -- Geoff Thorpe, RT/openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #86] Bug in RSA_check_key
This sounds like the same old problem with passing an RSA public key to this function and getting a segv, which seems to bite new users quite often. Can this function be fixed to do a sanity check on the key before proceeding? I assume it's the same with a hardware key. If a user ends up with an RSA key (public, private, or HSM), how are they to know whether they can safey call this function? Do they need intimate enough knowledge of the RSA structure to check if d is NULL, or check some flag to determine if it's a hardware key? Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
[[EMAIL PROTECTED] - Fri Jun 7 09:14:53 2002]: If the key is loaded via an ENGINE, openssl crashes because of a segfault (function BN_num_bits crypto/bn/bn_lib.c:252). Explanation: When loading a key from an engine the p q and d members of the RSA struct are never set. However RSA_check_key never checked to make sure those members a present before calling the functions to test it. To which version do you refer? Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #86] Bug in RSA_check_key
openssl-0.9.7-beta1 ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #86] Bug in RSA_check_key
If the key is loaded via an ENGINE, openssl crashes because of a segfault (function BN_num_bits crypto/bn/bn_lib.c:252). Explanation: When loading a key from an engine the p q and d members of the RSA struct are never set. However RSA_check_key never checked to make sure those members a present before calling the functions to test it. Call stack: BN_num_bits BN_is_prime_fasttest BN_is_prime RSA_check_key ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
