Pkey methods PRF and HKDF only use the provider API

[ShuaiYuan21]

In OpenSSL 3.0, the function tls1_PRF() will just fetch the default provider to do KDF, but there is no judgment for the scene using the engine API. Is it possible to add support for engine API? (HKDF also has the same issue)

For example, first judge whether it is a legacy case, if yes, call the engine API, otherwise call the provider API.

OpenSSL 3.0:

openssl/ssl/t1_enc.c

Lines 48 to 72 in 5c56cef

	kdf = EVP_KDF_fetch(s->ctx->libctx, OSSL_KDF_NAME_TLS1_PRF, s->ctx->propq);
	if (kdf == NULL)
	goto err;
	kctx = EVP_KDF_CTX_new(kdf);
	EVP_KDF_free(kdf);
	if (kctx == NULL)
	goto err;
	mdname = EVP_MD_get0_name(md);
	*p++ = OSSL_PARAM_construct_utf8_string(OSSL_KDF_PARAM_DIGEST,
	(char *)mdname, 0);
	*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SECRET,
	(unsigned char *)sec,
	(size_t)slen);
	*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
	(void *)seed1, (size_t)seed1_len);
	*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
	(void *)seed2, (size_t)seed2_len);
	*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
	(void *)seed3, (size_t)seed3_len);
	*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
	(void *)seed4, (size_t)seed4_len);
	*p++ = OSSL_PARAM_construct_octet_string(OSSL_KDF_PARAM_SEED,
	(void *)seed5, (size_t)seed5_len);
	*p = OSSL_PARAM_construct_end();
	if (EVP_KDF_derive(kctx, out, olen, params)) {

OpenSSL 1.1.1:

openssl/ssl/t1_enc.c

Lines 41 to 50 in fe824ce

	pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_TLS1_PRF, NULL);
	if (pctx == NULL || EVP_PKEY_derive_init(pctx) <= 0
	|| EVP_PKEY_CTX_set_tls1_prf_md(pctx, md) <= 0
	|| EVP_PKEY_CTX_set1_tls1_prf_secret(pctx, sec, (int)slen) <= 0
	|| EVP_PKEY_CTX_add1_tls1_prf_seed(pctx, seed1, (int)seed1_len) <= 0
	|| EVP_PKEY_CTX_add1_tls1_prf_seed(pctx, seed2, (int)seed2_len) <= 0
	|| EVP_PKEY_CTX_add1_tls1_prf_seed(pctx, seed3, (int)seed3_len) <= 0
	|| EVP_PKEY_CTX_add1_tls1_prf_seed(pctx, seed4, (int)seed4_len) <= 0
	|| EVP_PKEY_CTX_add1_tls1_prf_seed(pctx, seed5, (int)seed5_len) <= 0
	|| EVP_PKEY_derive(pctx, out, &olen) <= 0) {

[paulidale]

I'm not entire sure what you are asking about here. The second code segment should still work, it's deprecated and won't be removed until at least 4.x but it should still work. HKDF isn't supported via the PKEY interface and never will be.

The project has been pretty clear since 3.0 was released: there will not be any further enhancements to the engine APIs. They are deprecated and providers are the replacement.

[ShuaiYuan21]

Sorry for not being very clear.

Taking tls1.2 as an example, in OpenSSL 3.0, the tls1_PRF() function will be called during the handshake phase, and this function will only get the provider through EVP_KDF_fetch() to complete the KDF operation, instead of calling the EVP_PKEY_CTX_XXX series functions like openssl1.1.1.

Since OpenSSL 3.0 also supports the legacy engine API, this function should make one judgment to see if it is a legacy case. If so, then we call the EVP_PKEY_CTX_XXX series of functions to use the engine API, otherwise it will be completed with the help of provider through EVP_KDF_fetch

[t8m]

The problem is how to find out when the legacy API should be used and when it shouldn't. In theory we could revert to always using the legacy API however it could be seen as functionality change as that will go through different code paths in providers (perhaps even third party ones). And there is no clear way how to infer that an engine providing the legacy EVP_PKEY_CTX style API for HKDF or TLS1 PRF is enabled. I am afraid this ship has sailed and the calls will not be changed apart from some hacks like adding a new SSL_OP to enable the legacy way.