Greeting fellow OpenSSL coders,
As promised I got my act together (somewhat) and did some writing
on the new EVP interface that I am working on.
Symetric Cipher functions:
all EVP_<cipher-type>() also have a EVP_<cipher-type>_ext() function
that allows setting additional parameters specific to that cipher.
The basic functions call the _ext function with sensible parameters.
All EVP_<cipher-type>_ext() have the following prototype:
typedef struct evp_cipher_param_st {
unsigned long int param_type;
void* param_value;
} EVP_CIPHER_PARAM;
EVP_CIPHER* EVP_<cipher-type>_ext(EVP_CIPHER_PARAM *param_list,
unsigned int param_count);
param_type is an identifier for the class of information passed and
param_value is the pointer to the actual information. There is a
NULL as a value for param_list must be a valid
invocation. param_types that are invalid for a given cipher have to
be ignored.
This solution has the weakness that it obliterates all type
information but has a maximum flexibility.
The function EVP_get_cipherbyname() and EVP_get_digestbyname() are
replicated and extendet in EVP_get_cipherbyname_ext() and
EVP_get_digestbyname_ext() (somebody stop me please when the names
are getting too long) to contain the parameters for the additional
settings, analog to the parameters list of the individiual cipher
functions
In the list of ciphers it is no longer the cipher structure that is
stored, but a pointer to the generator function. The generator is
called every time a CIPHER is requested. For most functions this may
entail passing on a static EVP_CIPHER structure and all structures
must be assumed to be static and shared, thus may not be manipulated
by the calling functions.
At the moment only the rc4 cipher supports additional parameters,
namely
the length of the key and the NID to be used. Ah! Question: Does every
arbitrary length RC4 cipher get its own NID, or should they all be
just
'NID_rc4'? Currently there is a 'NID_rc4_40' as well.
Asymetric Ciphers
The asymetric ciphers use a c++ style method table. I am not quite
sure what the complete list of functions will look like, but all
externaly used function are only wrappers that call the method in
the provided pkey structure.
Legacy functions. These are supported w/o change to avoid breaking other
apps
EVP_EncryptInit(), EVP_EncryptUpdate(), EVP_EncryptFinal()
EVP_DecryptInit(), EVP_DecryptUpdate(), EVP_DecryptFinal()
EVP_CipherInit(), EVP_CipherUpdate(), EVP_CipherFinal()
EVP_EncodeInit(), EVP_EncodeUpdate(), EVP_EncodeFinal()
EVP_DecodeInit(), EVP_DecodeUpdate(), EVP_DecodeFinal()
EVP_OpenInit(), EVP_OpenFinal()
EVP_SealInit(), EVP_SealFinal()
PKCS#11 Support
Only the functions used to create the EVP_CIPHERS that go into
EVP_*Init() functions
might change, e.g. there will be a method that allows to wrap ciphers
into other ciphers.
this is used in the pkcs11 support as the mechanism used in pkcs11 is
decided by providing
a complete and fully configured cipher.
EVP_CIPHER* EVP_pkcs11_ext(EVP_CIPHER_PARAM *param_list,
unsigned int param_count);
that knows to handle the param EVP_CP_BASE_CIPHER, containing the
pointer to the actual
cipher. If the cipher is a valid PKCS#11 mechanism, the parameters will
be copied and a correct
mechanism is created. The mehtod pointers in the resultant EVP_CIPHER
point to pkcs11 methods
that will accept the created mechanism.
Various changes to be done:
- the EVP_MD structure looses its sign and verify members. They do
not belong here and are not used anyway.
- The mechanisms like dss need be split up into a MD part and a
signature part. Use the EVP_PKEY_MD structure to do that and create
needed initialisation functions.
- remove the PKEY sub types, especially those that represent combined
digest and sign types.
- to make handling the cipher methods easier these two types are
introduced:
typedef EVP_CIPHER* (*cipher_ext_method)(EVP_CIPHER_PARAM
*param_list,
unsigned int param_count);
typedef EVP_CIPHER* (*digest_method)
- create a stack of memory pieces that need to be cleaned up. hook
the cleanup to the EVP_cleanup function.
This will add the function EVP_CIPHER_free(EVP_CIPHER*) that
must be called after the cipher has been used. It will decide
whether the cipher is static or not and free it if nessecary.
This mechanism will add somewhat to the memory footprint, but
allows the reuse of ciphers that are dynamically generated while
still being able to cleanup afterwards.
- change the NOPROTO defines into _P() and hack the perl code to
generate the windows def files.
This is just my first take, but there will be more I am sure.
mfg lutz
--
*******************************************************************
Lutz Behnke Tel.: 040 / 766 29 1423
TC TrustCenter for Security Fax.: 040 / 766 29 577
in Data Networks GmbH email: [EMAIL PROTECTED]
Am Werder 1
21073 Hamburg, Germany
S/MIME Cryptographic Signature
