EVP_MAC default algorithm selection divergence between OpenSSL 3.0 and 3.1

Direct answer

There is no documented, portable default MAC algorithm selected by EVP_MAC_fetch when the algorithm parameter is NULL. The OpenSSL 3.x provider framework does not guarantee a stable “first” implementation across minor versions, builds, or provider configurations. Any behavior observed with NULL is an implementation detail, not a contract, and should not be relied upon in portable code.

Confirmed facts vs. unverified claims

Confirmed: EVP_MAC_fetch resolves implementations through loaded providers. Algorithm names are case-sensitive and must match the provider’s registered string exactly. In FIPS-validated or custom provider builds, the available MAC set differs from the default provider, so the first implementation returned for a NULL fetch can change.

Unverified / requires review: Community observations and model-knowledge research suggest that the default provider’s internal MAC ordering may differ between OpenSSL 3.0 and 3.1—for example, exposing an HMAC implementation first in 3.0 and a GMAC implementation first in 3.1. This ordering is not part of the public API contract, is not guaranteed across patch releases, and should be treated as a hypothesis to verify locally rather than established behavior.

Practical verification

If you need to confirm what your specific build does, inspect the provider’s algorithm ordering and the actual fetch result:

openssl list -mac-algorithms

Then compile a minimal probe:

#include <openssl/evp.h>
#include <stdio.h>

int main(void) {
    EVP_MAC *mac = EVP_MAC_fetch(NULL, NULL, NULL);
    if (mac) {
        printf("name=%s\n", EVP_MAC_get0_name(mac));
        EVP_MAC_free(mac);
    } else {
        printf("fetch failed\n");
    }
    return 0;
}

Build and run against both OpenSSL 3.0 and 3.1 toolchains to observe any difference on your platform.

TLS interoperability impact

Well-behaved TLS implementations and OpenSSL’s own TLS stack request specific MAC algorithms (for example, "HMAC" during record protection or key derivation). They do not depend on a NULL fetch. Interoperability problems arise only when application code passes an ambiguously fetched EVP_MAC into a TLS or KDF path that expects a particular MAC family. The safe boundary is explicit: never hand a NULL-fetched MAC to a subsystem that assumes HMAC or GMAC semantics.

Recommended fix

For portable, interoperable code—especially when a TLS library or FIPS module is in the path—always pass an explicit algorithm name such as "HMAC" or "GMAC" rather than NULL. Explicit requests remove provider-ordering ambiguity and make the security properties of your MAC obvious to reviewers.