EVP_PKEY_CTX_add1_hkdf_info() no longer works with providers that do not expose gettable parameters in ossl_kdf_hkdf_keyexch_functions array

[jmb202]

Upgrading from OpenSSL 3.0.13 to 3.0.14 has uncovered a breakage introduced by 4953ab1 when using a provider derived from OpenSSL 3.0.13 or earlier.

The newly introduced evp_pkey_ctx_add1_octet_string function (called by EVP_PKEY_CTX_add1_hkdf_info) in evp/pmeth_lib.c contains the following logic:

   /* Get the original value length */
    os_params[0] = OSSL_PARAM_construct_octet_string(param, NULL, 0);
    os_params[1] = OSSL_PARAM_construct_end();

    if (!EVP_PKEY_CTX_get_params(ctx, os_params))
        return 0;

    /* Older provider that doesn't support getting this parameter */
    if (os_params[0].return_size == OSSL_PARAM_UNMODIFIED)
        return evp_pkey_ctx_set1_octet_string(ctx, fallback, param, op, ctrl, data, datalen);

However, EVP_PKEY_CTX_get_params() will return 0 if ctx->op.kex.exchange->get_ctx_params is NULL and thus the subsequent check for older providers above does not get reached in the case where the provider does not expose a get_ctx_params function at all.

Any provider derived from older versions of OpenSSL will not expose get_ctx_params/gettable_params in the ossl_kdf_*_keyexch_functions array for key derivation algorithms. The commit referenced above caused these functions to be exposed: 4953ab1#diff-85fe36a1da6d2470d1a9ceb431d681dc458e600b994bb8df362e4564d943c698R246, so 3.0.14 is self-consistent.

We have worked around this locally by adjusting the code in 3.0.14 to check if any parameters are gettable when EVP_PKEY_CTX_get_params returns 0 in the logic above -- if none are, we assume that we're dealing with an old provider that does not expose get_params/gettable_params at all and fall back to evp_pkey_ctx_set1_octet_string in the same way as above.

[nhorman]

Thank you for the detailed report. this strikes me as a regression, @tmshort since you authored the referenced change, would you agree with that assessment.

@mattcaswell @levitte @t8m your input would be appreciated here as well.

for now I am assuming that it is, and marking it as such

[beldmit]

@jmb202 may I ask you to publish your workaround? We also are hit by this issue

[jmb202]

@beldmit sure -- it's trivial:

--- a/crypto/evp/pmeth_lib.c
+++ b/crypto/evp/pmeth_lib.c
@@ -1061,8 +1061,13 @@ static int evp_pkey_ctx_add1_octet_string(EVP_PKEY_CTX *ctx, int fallback,
     os_params[0] = OSSL_PARAM_construct_octet_string(param, NULL, 0);
     os_params[1] = OSSL_PARAM_construct_end();
 
-    if (!EVP_PKEY_CTX_get_params(ctx, os_params))
+    if (!EVP_PKEY_CTX_get_params(ctx, os_params)) {
+        if (EVP_PKEY_CTX_gettable_params(ctx) == NULL) {
+            /* Older provider that doesn't support gettable parameters */
+            return evp_pkey_ctx_set1_octet_string(ctx, fallback, param, op, ctrl, data, datalen);
+        }
         return 0;
+    }
 
     /* Older provider that doesn't support getting this parameter */
     if (os_params[0].return_size == OSSL_PARAM_UNMODIFIED)