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 transparent operations, perhaps RSA_is_valid()? Cheers, Geoff ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl- [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] Kenneth R. Robinette President InterSoft International, Inc. Voice:888-823-1541 or 281-398-7060 Fax:888-823-1542 or 281-560-9170 http://www.securenetterm.com _____________________________________________ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
