From: Corinne Dive-Reclus <[EMAIL PROTECTED]>
CDive> As soon I have got a reasonnable hook prototype, I will do. I
CDive> can provide to you either a hardware simulator you can run on
CDive> Solaris, HP-UX (even on WinNT) or a real hardware. When I will
CDive> be at this stage I will check with my company what the policy
CDive> is and what they prefer.
Cool. I think I personally would prefer Solaris if the simulator
would become the choice.
CDive> > - if you're in the states and send us any code, make sure you cc:
CDive> > those messages to [EMAIL PROTECTED] See http://www.crypto.com/.
CDive>
CDive> Baltimore is an Irish company and I am based in England.
Good (hence the "if" :-)).
CDive> > CDive> Anyway, any help about key generation (no ENGINE hook
CDive> > CDive> available? cannot dynamically create a key into an ENGINE ?)
CDive> > CDive> and key management will be greatly appreciated.
CDive> >
CDive> > So far, we've extended the collection of engine hooks when there's
CDive> > been more things it could support on the hardware we've been playing
CDive> > with. Since the engines play with hidden data, extending with new
CDive> > hooks isn't too difficult. Perhaps it's time to check what we really
CDive> > should support in an engine and write it a little bit more in stone.
CDive> > Ideas?
CDive> So far, the current ENGINE seems good to me. Your choice to
CDive> hook only asymmetric operations seems reasonnable for a SSL
CDive> implementation.
Actually, it's like that so far, because the hardware we've played
with (or at least, that's how it's been for me) supported only
asymmetric operations. For me, those include the CryptoSwift PCI card
and the nCipher box, going through their CHIL interface.
CDive> Symmetric keys are only session keys and today do not need the
CDive> same level of protection.
For SSL, that's true. However, there might be uses for symmetric
algorithm acceleration or even key management in other situations.
CDive> Even if the hardware is capable of symmetric operations, it is
CDive> probably to slow to go down to it to perform the operation.
Depends. If it takes load away from the central CPU, it might be a
good thing from that point of view, by increasing over-all performance
even if the hardware acceleration isn't performing very well if it's
viewed as an isolated entity.
CDive> I am still too new in OpenSSL to know what key management
CDive> features are implemented so perhaps the following remarks are
CDive> irrelevant and in this case, let me know:
CDive> - A hardware can contain more than 1 key pair (ours
CDive> can contain several hundreds and can be accessed by several
CDive> Crypto Applications simultaneously).
OK.
CDive> - At key pair generation, the engine can be called and
CDive> return a "key name". If flags contains RSA_FLAG_EXT_PKEY,
CDive> bignum will point to a null-terminated string rather than a
CDive> bignum array.
Incorrect. ENGINE_load_private_key() requires a "key name" in form of
a NUL-terminated string, as well as an optional passphrase. It
returns an EVP_PKEY to you, which contains a pointer to the RSA
structure. This RSA structure may contain bignums for both the public
and the private key of the key pair, or (as it is for the nCipher
implementation) bignums for the public key and just a reference
(context pointer) to the private key. In the latter case, at least
with the nCipher implementation, the reference to the private key is
saved in the ex_data structure that's referenced by the RSA structure.
Take a look at hw_ncipher.c, it's kind of a reference to the
functionality for now.
CDive> - When the key is serialised and saved
CDive> (PEM_write_bio_RSAPrivateKey() ?), we can decide not to encrypt
CDive> it and serialise just the key name.
Actually, such functaionlity has not been implemented. Instead, the
choice has been to leave the private key with the hardware and simply
use ENGINE_load_private_key() to access it again and again. If you
look in apps/ca.c, you can see how that is handled.
CDive> - When a private key is to be used, the application
CDive> reads it (PEM_read_bio_RSAPrivateKey() ?) and a rsa_st is
CDive> rebuilt from it. This structure is passed as it is to the
CDive> ENGINE rsa operation, the engine will use the name into rsa_st
CDive> to identify the key to use into the hardware.
No. The application is expected to know some other way that the key
to use is stored in some hardware solution and access it through the
engine instead of reading a PEM file.
CDive> - load_private_key won't be necessary except if we
CDive> want to use a key not generated by OpenSSL and already into the
CDive> hardware. It would be greate too if this file format is the
CDive> same as PEM_write_bio_RSAPrivateKey, like that the key can used
CDive> later as generated from OpenSSL ( i.e. probably very useful for
CDive> read-only devices like smartcards for SSL clients).
I really see no need for that. What would you do with that PEM file?
Transport it to some other computer, where it would instantly become
unusable?
CDive> - we can provide too a RSA/DSA_delete_private_key.
It would be pretty nice if there was some procedure to create keys as
well :-).
CDive> In fact, if my understanding is correct that seems to fit
CDive> quite well your framework and will be happy to contribute to
CDive> it.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Redakteur@Stacken \ SWEDEN \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
