+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
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 encr
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_PA
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_
