RE: DH_compute_key () - replacement in 3.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
Sent: 16 December 2020 05:00
To: Narayana, Sunil Kumar <sanarayana@xxxxxxxx>; openssl-users@xxxxxxxxxxx
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.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux