Geoff Thorpe wrote:
>
> Hi there,
>
> On Thu, 8 Feb 2001, Dr S N Henson wrote:
>
> > Personally I'd like to see symmetric support at some point. I like the
> > idea of being able to increase security by not keeping secret keys in
> > memory but only references to them. Unfortunately that's a bit tricky
> > with OpenSSLs current EVP interface and some extensions would be needed.
>
> Yep - in fact at that time I think it will probably be appropriate to
> restructure a few things in ENGINE. Specifically it was originally created
> to be as thin a layer of code as possible passing directly onto the
> underlying RSA/DSA/DH/RAND methods that everyone was familiar with.
So we should end up making it thicker but not stupider :-)
>
> (1) We need EVP_PKEY_METHODs first. :-) (This is where key generation,
> loading, saving, etc would go - hopefully it might also handle ASN?)
>
Yes ideally we would have EVP_PKEY_METHOD. However I wouldn't want to
have that in before 0.9.7 is released. Far too much has changed already
and I can see the next OpenSSL official release being pushed further and
further into the distant future.
> (2) We'd need to move code towards using EVP abstractions so that the
> hooking is possible without hacking. Eg. currently there's a lot of code
> calling algorithm-specific functions, such as RSA_*** or DH_***, requiring
> the hooks I put into the RSA/DSA/DH code - they work around that by
> routing operations back through whatever the default ENGINE for *that*
> algorithm is. In fact, in the asymmetric case, there's no choice about
> that anyway (see (1) above). This will *not* be possible with symmetric
> crypto however - the list of possible algorithms and modes is not only
> huge, but it should be extensible.
>
> (3) I think EVP_CIPHER, EVP_MD, and friends will need some work too. :-)
>
Yes looking through EVP the inevitable conclusion is "this will all have
to go" :-)
> > That kind of thing has been done in the past but I've never liked it.
> > What we should really be doing is only storing the public key components
> > in the bignum structure and having separate information which contains a
> > reference to the private key (engine name, key name and application
> > specific information) which is then handled transparently by the
> > appropriate routine.
>
> Want to write an ASN1 definition for that Steve? ;-)
>
That kind of thing is now pretty easy with the new ASN1 code. Some
people have already been writing new ASN1 modules just based on the
examples already present.
It would probably take longer to decide what should go in there than to
write it.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
