If it wouldn't cause massive disruption it would be tempting to rip out
the whole EVP stuff, make the SSL library talk PKCS#11 and then add a
PKCS#11 interface to the lower level crypto routines.
Enough daydreaming: I've had a look at how things are and how I think
things need changing. In rough order of difficulty, 1 and 2 are quite
easy the rest much more involved.
1. Addition of DH_METHOD and DSA_METHOD.
This would largely be based upon the RSA_METHOD model: high level
functions that do the whole thing and low level ones that do the mod_exp
stuff. The lack of these at present makes it impossible to provide
hardware support for these algorithms without major changes to the
OpenSSL core code.
2. RSA_METHOD fixes.
Note: some of this will break any existing code that implements its own
RSA_METHOD.
RSA_METHOD has a few problems. Not all the stuff in there is thread safe
for a start. On a more structural level...
a. bn_mod_exp can't access the RSA structure (because it isn't passed to
it) so I propose to add an RSA argument to it.
b. When doing a hardware interface not all libraries support private key
encryption and public key decryption of arbitrary data (for signatures).
This can be solved by adding to new functions to RSA_METHOD: sign and
verify. These will be passed a digest and algorithm and will then sign
or verify as appropriate, the RSA_sign() and RSA_verify() functions will
now just call these. This will need some minor changes to the SSL
library which uses the RSA functions directly to handle the SSL
signatures.
c. (optional) There is currently no way to change the default RSA key
generation code. Maybe this should be made possible?
3. EVP_PKEY overhaul.
(It may prove possible to use some/all of Lutz patch for this)
Currently the EVP_PKEY stuff is largely hard coded. If you want to add a
new public key algorithm then you have to modify the OpenSSL code
itself. It should be possible to provide an EVP_PKEY_METHOD structure
and then OpenSSL should use it do the following:
a. encryption and decryption (if applicable).
b. sign and verify (if applicable).
c. key agreement (if applicable).
d. ASN1 encoding and decoding of public and private keys for things like
certificates and PKCS#8.
e. Printing out of public and private keys for certificate printing etc.
4. EVP overhaul.
EVP is rather horrible at present. Heres an incomplete list of problems.
a. You have a few separate algorithms you can use but nothing in
between. For example you can do 40, 64 and 128 bit RC2. If you want
anything else then you can't use the EVP interface without some evil
hackery. Similarly you have a restricted range of cipher modes and PKCS
(block) padding is implicit. You should be able to specify the cipher,
keylength and lots of other parameters and then use the EVP interface
not just choose from a few hard coded parameters.
b. The library largely assumes that the keys will be loaded in in plain
text. It doesn't have a concept of a "key" that isn't readable by it but
which can nevertheless be used.
5. Key database.
I've written a lot about this (ad nauseam some would say...) so I wont
say any more about it now.
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]
