OK let me put this another way. You don't need to really understand how
all the ASN.1 stuff works and I certainly wouldn't expect you to write
it, however what is important is that the new scheme allows the ASN.1
stuff to work and it isn't just plain impossible as with the current
system.
The ASN.1 stuff doesn't quite match up to the current API. Currently you
have the key and IV (if needed) passed to EVP_CipherInit (and friends)
and everything else is implied by the EVP_CIPHER parameter.
The ASN.1 AlgorithmIdentifier supplies everything except the key and
sometimes (e.g. RC2) the key length. That is you get the cipher, IV, IV
length and various other things implied by the ASN.1.
So the proposed:
EVP_CIPHER EVP_getcipherbyASN1(unsigned char* asn1_string, unsigned
int lenght)
would need to be modified to:
EVP_CIPHER *EVP_getcipherbyASN1(unsigned char* asn1_string, unsigned
int lenght, unsigned char **iv);
In fact since this would always be an AlgortithmIdentifier it could be
better done with:
EVP_CIPHER *EVP_getcipherbyASN1(X509_ALGOR *algorithm, unsigned char
**iv);
This is easy enough to handle. It would decode the ASN.1 stuff based and
lookup the the NID of the algorithm object of the AlgorithmIdentifier.
So you need something to convert a NID into an EVP_<cipher type>_ext
function pointer.
It would then pass the parameters as an ASN1_TYPE parameter to the
cipher specific ASN.1 stuff which would then set up everything else and
pass the IV (if necessary) back along with the EVP_CIPHER pointer if
everything was consistent or NULL if not. The IV would come back as a
Malloc'ed buffer.
A potential problem is that you don't always know the key length at this
point. This means that you need to be able to modify the key length in
the returned EVP_CIPHER structure. The is needed by EVP_Open for
variably key length ciphers (RC2, RC4).
EVP_Open as I said will typically decrypt an RSA block with a private
key. The returned data may be invalid or have an invalid length: as a
result it *MUST* be an error if an attempt is made to set an invalid key
length.
Similarly the ASN.1 stuff may be invalid so equally an attempt to set an
invalid IV length must be flagged as an error.
Now you proposed:
EVP_CIPHER* EVP_<cipher-type>_ext(EVP_CIPHER_PARAM *param_list,
unsigned int param_count);
I'd suggest this might be easier to handle if you pass a STACK instead:
EVP_CIPHER* EVP_<cipher-type>_ext(STACK *param_list);
You could then set up param_list with some helper functions like
EVP_CIPHER_param_set_keylen() etc..
The reverse side of generating the ASN.1 is similar. Given a cipher, key
and IV it should be able to generate an AlgorithmIdentifier. This just
needs a function to get the NID from a cipher and the cipher to include
some ASN.1 code: something returning an ASN1_TYPE structure could be
directly placed in the X509_ALGOR structure.
Or to summarise you need:
Some way to turn a NID into an EVP_<cipher type>_ext function pointer
and some want to get a NID from an EVP_CIPHER structure.
Each EVP_<cipher type>_ext function should have an associated pair of
ASN.1 functions:
EVP_CIPHER *EVP_ASN1_to_CIPHER(ASN1_TYPE *type, unsigned char **iv)
ASN1_TYPE *EVP_CIPHER_to_ASN1(EVP_CIPHER *cipher, unsigned char *iv);
Finally you need some way to change the key length of an EVP_CIPHER
structure and return an error if this is invalid.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
