Description
Azure Linux 3 exposes ML-KEM through symcryptprovider, but OpenSSL's EVP_PKEY_Q_keygen rejects the algorithm before provider dispatch.
In the same process:
EVP_KEYMGMT_fetch("ML-KEM-768") succeeds.EVP_PKEY_Q_keygen("ML-KEM-768") fails.- Generic name-based key generation succeeds.
Reproducer
docker run --rm -it \
mcr.microsoft.com/oss/go/microsoft/golang:1.27-azurelinux3.0 sh
tdnf install -y gcc openssl-devel
Create /tmp/repro.c:
#include <openssl/err.h>
#include <openssl/evp.h>
#include <stdio.h>
int main(void) {
EVP_KEYMGMT *keymgmt = EVP_KEYMGMT_fetch(NULL, "ML-KEM-768", NULL);
printf("EVP_KEYMGMT_fetch: %s\n", keymgmt != NULL ? "ok" : "failed");
EVP_KEYMGMT_free(keymgmt);
EVP_PKEY *quick = EVP_PKEY_Q_keygen(NULL, NULL, "ML-KEM-768");
int quick_ok = quick != NULL;
printf("EVP_PKEY_Q_keygen: %s\n", quick_ok ? "ok" : "failed");
if (!quick_ok)
ERR_print_errors_fp(stderr);
EVP_PKEY_free(quick);
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, "ML-KEM-768", NULL);
EVP_PKEY *generic = NULL;
int generic_ok =
ctx != NULL &&
EVP_PKEY_keygen_init(ctx) > 0 &&
EVP_PKEY_keygen(ctx, &generic) > 0;
printf("name-based keygen: %s\n", generic_ok ? "ok" : "failed");
EVP_PKEY_free(generic);
EVP_PKEY_CTX_free(ctx);
return quick_ok ? 0 : 1;
}Compile and run:
cc -Wall -Wextra /tmp/repro.c -o /tmp/repro -lcrypto
/tmp/repro
Actual result
EVP_KEYMGMT_fetch: ok
EVP_PKEY_Q_keygen: failed
error:03080106:digital envelope routines:EVP_PKEY_Q_keygen:passed invalid argument:crypto/evp/evp_lib.c:1229:
name-based keygen: ok
The program exits with status 1.
Expected result
EVP_PKEY_Q_keygen should generate a key for an algorithm available through the configured provider, consistent with the generic name-based EVP path.
Environment
- Azure Linux
3.0.20260809
- ARM64
openssl-3.3.7-4.azl3openssl-libs-3.3.7-4.azl3SymCrypt-103.8.0-1.azl3SymCrypt-OpenSSL-1.10.0-1.azl3
Root cause
The OpenSSL 3.3.7 implementation of EVP_PKEY_Q_keygen only recognizes a fixed set of algorithm names. Although ML-KEM-768 is available from symcryptprovider, the helper rejects it with EVP_R_PASSED_INVALID_ARGUMENT before provider key generation is attempted.
The generic provider path through EVP_PKEY_CTX_new_from_name does not have this limitation and succeeds.
Suggested resolution
Backport the relevant OpenSSL support for ML-KEM in EVP_PKEY_Q_keygen.
Related to #17967.
Description
Azure Linux 3 exposes ML-KEM through
symcryptprovider, but OpenSSL'sEVP_PKEY_Q_keygenrejects the algorithm before provider dispatch.In the same process:
EVP_KEYMGMT_fetch("ML-KEM-768")succeeds.EVP_PKEY_Q_keygen("ML-KEM-768")fails.Reproducer
Create
/tmp/repro.c:Compile and run:
Actual result
The program exits with status 1.
Expected result
EVP_PKEY_Q_keygenshould generate a key for an algorithm available through the configured provider, consistent with the generic name-based EVP path.Environment
3.0.20260809openssl-3.3.7-4.azl3openssl-libs-3.3.7-4.azl3SymCrypt-103.8.0-1.azl3SymCrypt-OpenSSL-1.10.0-1.azl3Root cause
The OpenSSL 3.3.7 implementation of
EVP_PKEY_Q_keygenonly recognizes a fixed set of algorithm names. AlthoughML-KEM-768is available fromsymcryptprovider, the helper rejects it withEVP_R_PASSED_INVALID_ARGUMENTbefore provider key generation is attempted.The generic provider path through
EVP_PKEY_CTX_new_from_namedoes not have this limitation and succeeds.Suggested resolution
Backport the relevant OpenSSL support for ML-KEM in
EVP_PKEY_Q_keygen.Related to #17967.