How can I tell if a name for a cipher/digest is implemented?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How can I tell if a name for a cipher/digest is implemented?

Hal Murray

I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
but that changed for 3.0.0

Is there anything better/cleaner than actually calling EVP_CipherInit() or
such?


I'm curious.  What does it mean to have a non-NULL cipher that doesn't work?  
I'm using default Engines and Providers.  Is that something like we have
allocated a slot in the name space but this engine doesn't support it?  Should
there be something like EVP_get_ciphername that takes the engine parameter?

--
These are my opinions.  I hate spam.



Reply | Threaded
Open this post in threaded view
|

Re: How can I tell if a name for a cipher/digest is implemented?

Richard Levitte - VMS Whacker-2
On Thu, 18 Jun 2020 09:39:11 +0200,
Hal Murray wrote:
> I think that checking for NULL from EVP_get_ciphername() works in 1.1.1
> but that changed for 3.0.0
>
> Is there anything better/cleaner than actually calling EVP_CipherInit() or
> such?

For 3.0 and on, the better way is to find the cipher with EVP_CIPHER_fetch().
That's essentially the new EVP_get_cipherbyname().

> I'm curious.  What does it mean to have a non-NULL cipher that doesn't work?  

It means that we made a compromise, and do support the use of
functions that return a const EVP_CIPHER, but mainly as a template for
implicit fetching in the likes of EVP_CipherInit.
This is, incidently, what happens if you pass an engine pointer to
EVP_CipherInit_ex() as well, the EVP_CIPHER pointer that you pass to
it is only a template for getting the "real" engine implementation,
and will fail if that engine doesn't implement it.  In other words,
you do have this situation in 1.1.1 as well, just less obviously.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/