Using RSA_PKCS1_OAEP_PADDING with high level EVP_Seal functions

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

 



+1

I agree with Daniel's sentiment and respectfully suggest EPV_Seal* and 
EVP_Open be updated and kept up to date.

We all know how easy it is to get crypto wrong.  Having "one stop shop" 
functions like these are invaluable for when it comes to getting crypto 
right.

Norm Green

On 9/9/2016 3:55 AM, Daniel Knoppel wrote:
> Thanks for the reply! Unfortunately I'm not sure I understand what
> you're saying.
>
> If EVP_Seal* is an old function, is there a new function with which we
> can accomplish the same functionality?
>
> What I mean is that the EVP_PKEY_encrypt() looks functionally the same
> as RSA_public_encrypt() (just encrypting using a public key), so it
> doesn't help with encrypting bulk data like the EVP_Seal*() functions.
>
> For instance, with EVP_PKEY_encrypt users still have to deal with
> symmetric key and iv generation, something that EVP_Seal*() does for you
> (i.e. so you can't get it wrong).
>
> The official documentation[1] even hints that you should be using
> EVP_Seal*():
> "For encryption and decryption see EVP_PKEY_encrypt and EVP_PKEY_decrypt
> respectively. However, note that these functions perform encryption and
> decryption only. As public key encryption is an expensive operation,
> normally you would wrap an encrypted message in a "digital envelope"
> using the EVP_SealInit and EVP_OpenInit functions."
>
> Best regards,
>
> Daniel
> [1] https://www.openssl.org/docs/manmaster/crypto/evp.html
>
> On 8-9-2016 21:18, Dr. Stephen Henson wrote:
>> On Wed, Sep 07, 2016, Daniel Knoppel wrote:
>>
>>> Dear all,
>>>
>>> I was wondering about two things:
>>>
>>> 1. Can the EVP_Seal*() functions be told to use RSA_PKCS1_OAEP_PADDING,
>>> or do I need to stick with the lower level RSA_public_encrypt()?
>>>
>>> >From the source code it seems to me that RSA_PKCS1_PADDING is hardcoded
>>> because EVP_SealInit() [1] calls EVP_PKEY_encrypt_old() [2], which in
>>> turn has the line with hardcoded padding:
>>>
>>> ret = RSA_public_encrypt(key_len, key, ek, EVP_PKEY_get0_RSA(pubk),
>>> RSA_PKCS1_PADDING);
>>>
>> EVP_Seal*() is an old function hard coded to use RSA_PKCS1_PADDING as you've
>> observed.
>>
>> You don't need to use the low level RSA_public_encrypt() function for
>> OAEP. Instead use the EVP_PKEY APIs EVP_PKEY_encrypt() and EVP_PKEY_decrypt()
>> with the padding mode modified and appropriate parameters set.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>>



[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