At 09:29 PM 3/21/2002 +0000, S.Henson wrote:
>Is there some particular reason why such applications couldn't use the
>EVP layer? An attempt has been made to keep this consistent and to make
>any enhancements backwards compatible. In fact some of the more recent
>changes would have been substantially easier if EVP compatibility wasn't
>an issue.
EVP is yet another opportunity to abuse OpenSSL by pretending it's
a crypto library. It doesn't do public key operations, and it doesn't
let you access the engines. I had avoided it in the past (long ago,
0.9.4 era) and went straight for the low level routines. I've just
clawed through the POD pages (which is not a process without pain...)
and I still don't see any reasonable public key operations. Seal creates
a key, which I don't want, Sign presumes a hash is involved, which
I don't want, and give the pain it's taking to get an engine to
initialize I don't believe the text in evp.pod about
"Algorithms are loaded with OpenSSL_add_all_algorithms".
If I could do this:
engine = "ubsec";
output_buffer_length = /* e.g. */ sizeof (output_buffer);
EVP_wishlist_private_key_encrypt (context, cleartext, cleartext_length,
wrap_scheme, engine, output_buffer, &output_buffer_length);
then I'd use EVP, sure.
Now, last time I checked, the last three letters in OpenSSL are, um, SSL,
so grumbling
about lack of cool crypto primitives seemed off-topic...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
