DH_compute_key () - replacement in 3.0

[Narayana, Sunil Kumar]

Hi,
                For the equivalent replacement of DH_compute_key in 3.0, we tried to perform the steps suggested in earlier mail below
Our steps are as follows, but we see EVP_PKEY_derive  fails to perform.  please suggest if any steps are wrong or missing here.

//input - BIGNUM - pubkey, privkey, p ,
//output - sharedsecret

Evp_compute_key(unsigned char* sharedSecret, unsigned int len, BIGNUM *pubkey, BIGNUM *privkey, BIGNUM* dh_p)
{
OSSL_PARAM params[5];
unsigned char*  p_str = BN_bn2dec (dh_p);
unsigned char* pub_str = BN_bn2dec (pubkey);
unsigned char* priv_str = BN_bn2dec (privkey);

params[0] = OSSL_PARAM_construct_BN(OSSL_PKEY_PARAM_FFC_P, p_str, strlen(p_str));
params[1] = OSSL_PARAM_construct_uint(OSSL_PKEY_PARAM_FFC_G, &g);
params[2] = OSSL_PARAM_construct_BN(OSSL_PKEY_PARAM_PUB_KEY, pub_str, strlen(pub_str));
params[3] = OSSL_PARAM_construct_BN(OSSL_PKEY_PARAM_PRIV_KEY, priv_str, strlen(priv_str));
params[4] = OSSL_PARAM_construct_end();

gctx = EVP_PKEY_CTX_new_from_name(NULL, "DH", NULL);
EVP_PKEY_derive_init(gctx)
EVP_PKEY_CTX_set_params(gctx, params)

/* Determine buffer length */
EVP_PKEY_derive(gctx, NULL, &skeylen)
EVP_PKEY_derive(gctx, sharedSecret, &skeylen)
}

Note - EVP_PKEY_derive -- call fails what is wrong in the steps can you please g

From: Sands, Daniel <dnsands at sandia.gov>
Sent: 16 December 2020 05:00
To: Narayana, Sunil Kumar <sanarayana at rbbn.com>; openssl-users at openssl.org
Subject: RE: [EXTERNAL] RE: DH_compute_key () - replacement in 3.0

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

We do have generated the key using EVP_PKEY_gen as suggested in earlier emails, but since this was a non-ephemeral and we wanted to store the key in "raw" octet bytes, so we did extracted the whole DH priv/pub key pair out from the key generated via  EVP_PKEY_gen  ( using as suggested… EVP_PKEY_get_raw_public_key (pkey, pub, &len)  )

Now, at a later stage in application we have to compute the Secret key using the stored key’s (in above step).
As of now,  these keys are in uchar format, but are converted to BIGNUM and given to DH_compute_key as below.

   BIGNUM      *bn_publicKey;
    dh->priv_key = BN_bin2bn(privateKey, octet_len, NULL);
    bn_publicKey = BN_bin2bn(publicKey, octet_len, NULL);
    rv = DH_compute_key(sharedSecret, bn_publicKey, dh);

So in order to keep the existing frame work in place and just replace the DH_compute_key, we should be using the  dh->priv_key/ bn_publicKey  to compute shared secret key.
So we require to convert the BIGNUM key types to EVP_KEY types to use in EVP_PKEY_derive_init, EVP_PKEY_derive_set_peer, and EVP_PKEY_derive to get shared secret
Please suggest…


Is it possible to change the format of your raw blob?  If so, you can use i2d_PrivateKey or friends to output the entire private key to your raw data blob, and use d2i_PrivateKey et al to read it back into a working EVP_PKEY in a single call.

Otherwise, one shortcut you can do to avoid all the params work is to create a static array since you should already know how many params you need.  But you need the public key, the private key, the generator (g), and the prime modulus (p).  The following (untested) code ought to work.

OSSL_PARAM params[5];

params[0] = OSSL_PARAM_construct_BN(OSSL_PKEY_PARAM_FFC_P, <prime modulus>, <prime modulus bytes size>);
params[1] = OSSL_PARAM_construct_uint(OSSL_PKEY_PARAM_FFC_G, <generator>);
params[2] = OSSL_PARAM_construct_BN(OSSL_PKEY_PARAM_PUB_KEY, <public key>, <public key bytes size>);
params[3] = OSSL_PARAM_construct_BN(OSSL_PKEY_PARAM_PRIV_KEY, <private key>, <private key bytes size>);
params[4] = OSSL_PARAM_construct_end();

my_key_ctx = EVP_PKEY_CTX_new_from_name(NULL, “DH”, NULL);
EVP_PKEY_derive_init(my_key_ctx);
EVP_PKEY_CTX_set_params(my_key_ctx, params);
…


-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20201217/584d150b/attachment.html>