Add support for "fetched" EVP_MD and EVP_CIPHER

[rhenium]

With the introduction of OpenSSL 3 providers, newly added algorithms may no longer have associated NIDs. Such algorithms must be "fetched" using the new functions added in OpenSSL 3.0:

• For EVP_MD: EVP_MD_fetch(NULL, str, NULL) instead of EVP_get_digestbyname(str)
• For EVP_CIPHER: EVP_CIPHER_fetch(NULL, str, NULL) instead of EVP_get_cipherbyname(str)

Although the new "fetch" functions have similar signatures and return the same struct, they are not drop-in replacements due to several differences:

• The fetched objects are reference counted and must be released by the user by EVP_MD_free() or EVP_CIPHER_free() explicitly. Legacy functions return a const pointer to a statically allocated object.

  • The man pages are unclear whether if OpenSSL APIs that take EVP_MD as a parameter will automatically increment the reference counter. OpenSSL's internals seem to expect it for EVP_DigestInit_ex(), which works on EVP_MD_CTX.

  • On the other hand, EVP_PKEY_CTX_set_rsa_mgf1_md() used in OpenSSL::PKey::RSA#sign_pss does not. In this case, we must ensure the EVP_MD remains alive until we release the EVP_PKEY_CTX.

• The algorithm names appear to be managed separately. Not all names accepted by EVP_get_digestbyname(str) are valid with EVP_MD_fetch(NULL, str, NULL).

  • For example, OpenSSL::Digest.new("RSA-SHA256") is currently accepted and equivalent to SHA256. EVP_MD_fetch() does not recognize it.

  • We probably don't want to keep a copy of the mapping, so we'd have to continue to use the legacy functions, too. Handling objects with different lifetime will be cumbersome.

As of now, the only affected algorithms in OpenSSL proper are the pre-NIST Keccak hash functions added in OpenSSL 3.2. (I may have missed something.)