Re: Use EVP_MAC for HMAC with OpenSSL 3.0 and later

On Wed, Aug 05, 2026 at 01:09:11PM -0700, Mark Atwood wrote:
> The legacy HMAC_CTX interface (HMAC_CTX_new, HMAC_Init_ex, HMAC_Update,
> HMAC_Final) has been deprecated since 3.0, and it does not dispatch through the
> provider framework, so a loaded provider's HMAC implementation is bypassed.
> The patch fetches "HMAC" with EVP_MAC_fetch(), creates an EVP_MAC_CTX, and
> selects the digest through an OSSL_PARAM. The HMAC_CTX path is retained for
> older OpenSSL and for LibreSSL, guarded by OPENSSL_VERSION_NUMBER >=
> 0x30000000L.
>
> The fetch uses the default library context and a NULL property query, so no
> dependency is added and no particular provider is required; the provider is
> selected by the usual OpenSSL configuration (openssl.cnf).

This patch was not that bad. The amount of code duplicated in
pg_hmac_create() for the error handling was just there for
EVP_MAC_free(), so I have added an extra #ifdef for it before throwing
an error on OOM.

OSSL_PARAM_construct_utf8_string() has a couple of alternatives, like
using a pointer. Now, looking at the code and some demo code, mainly
hmac-sha512.c in upstream, that's the right alternative.

The change in pg_hmac_final() was shaped weirdly, tweaked it to make
it more consistent.

And after testing that across various OpenSSL versions down to 1.1.1,
the result was OK, so applied on HEAD. Now that's two. Still need to
look at the channel binding piece.
--
Michael