I am not sure why the code you have shared is trying to decrypt the signature. If it is done as part of signature verification, don't do this. Use the actual EVP_PKEY_verify API with corresponding public key.
If you certainly need the decrypted signature, you should do public encryption with NONE padding. A Private key is not necessary. Thanks, Thulasi On Fri, 29 Jan 2021 at 17:47, Narayana, Sunil Kumar <sanaray...@rbbn.com> wrote: > Yeah, it sounds correct. But since it’s an old application code & we are > not sure why was it done so, we are little worried to change. > > Can you please take a look the attachment which has the complete flow, and > provide your views which helps us to change it to PEM_read_PrivateKey() > or variants as you suggested > > > > Regards, > > Sunil > > > > *From:* Thulasi Goriparthi <thulasi.goripar...@gmail.com> > *Sent:* 29 January 2021 17:24 > *To:* Narayana, Sunil Kumar <sanaray...@rbbn.com> > *Cc:* openssl-users@openssl.org > *Subject:* Re: <Replacement for RSA_public_decrypt> > > > ------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > ------------------------------ > > > > Isn't it obvious to use PEM_read_PrivateKey() or variants to load the > private key as EVP_PKEY > > and use EVP_PKEY_decrypt* as specified in > https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_decrypt.html > <https://protect-us.mimecast.com/s/pIHaCqx23xSzZMNwiZOok8?domain=openssl.org> > ? > > > > Thanks, > > Thulasi. > > > > On Fri, 29 Jan 2021 at 16:59, Narayana, Sunil Kumar <sanaray...@rbbn.com> > wrote: > > Hi Thulasi, > > > > Currently in (1.0.1) we are following the following sequence, which now > need to replace with EVP. > > > > *Current sequence* > > > > //to create RSA pubkey > > rsa = PEM_read_bio_RSA_PUBKEY(keybio, NULL, NULL, NULL); // !!! > > > > //to decrypt using RSA utility > > RSA_public_decrypt(len, (unsigned char*)buffer,decrypted,rsa, > RSA_PKCS1_PADDING) ; > > > > As you mentioned , if we use PEM_read_bio_PUBKEY to get EVP_PKEY, it will > be a pubkey right ? but in order to decrypt as per the example in > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_decrypt_init.html > <https://protect-us.mimecast.com/s/iJORCrkY3ki1EBZJTzdO87?domain=openssl.org> > > We need to use an RSA private key > > > > Please suggest. > > > > Regards, > > Sunil > > *From:* Thulasi Goriparthi <thulasi.goripar...@gmail.com> > *Sent:* 29 January 2021 13:07 > *To:* Narayana, Sunil Kumar <sanaray...@rbbn.com> > *Cc:* openssl-users@openssl.org > *Subject:* Re: <Replacement for RSA_public_decrypt> > > > ------------------------------ > > NOTICE: This email was received from an EXTERNAL sender > ------------------------------ > > > > Hope, you are referring to > https://www.openssl.org/docs/man1.0.2/man3/EVP_PKEY_encrypt.html > <https://protect-us.mimecast.com/s/v2osCv2j32i2xk8Vtz2d4K?domain=openssl.org> > > > > Use PEM_read_bio_PUBKEY to get EVP_PKEY. > > eng is for engine reference. If you have no engine, it can be NULL. > > > > Thanks, > > Thulasi. > > > > On Fri, 29 Jan 2021 at 10:13, Narayana, Sunil Kumar <sanaray...@rbbn.com> > wrote: > > Dear Openssl team, > > > > While migrating from 1.0.2 to 3.0 we observe that > RSA_public_decrypt() API been deprecated in 3.0. > > We referred the example provided in man page but we are not clear in > generating the initial ‘key’ required to create CTX. > > Please suggest on (key , eng) params to proceed > > > > Also currently we are using PEM_read_bio_RSA_PUBKEY() to generate RSA, I > think this might not require in case of EVP, please suggest. > > > > /* > > * NB: assumes key, eng, in, inlen are already set up > > * and that key is an RSA private key > > */ > > ctx = EVP_PKEY_CTX_new(key, eng); > > > > > > Regards, > > Sunil > > > > > > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. and its Affiliates 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. > > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. and its Affiliates 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. > > > Notice: This e-mail together with any attachments may contain information > of Ribbon Communications Inc. and its Affiliates 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. >
