Hi Thulasi,
You are right! It's a bug on my part.
I have a follow-up question regarding what EVP_DecryptFinal is doing.
In my case, the original string is 27 bytes long, the ciphertext length
is 48 ( I am using AES-CBC-128). The decrypted plaintext before
finalization is 32 but the finalization added 11 more bytes. So the total
decrypted len is 43.
Can you explain where the 11 more bytes are coming from after finalization?
Also It seems OK even if I don't use finalization,
David
On Thu, Jul 31, 2014 at 8:22 PM, Thulasi Goriparthi <
thulasi.goripar...@gmail.com> wrote:
>
>
>
> On Fri, Aug 1, 2014 at 5:46 AM, David Li <dlipub...@gmail.com> wrote:
>
>> Hi,
>>
>> I am using openssl 1.0.1h and AES128 CBC mode to encrypt some arbitrary
>> long ASCII string.
>> I encountered an issue at decryption. If I use EVP_DecryptFinal_ex then
>> the output is unrecognizable. If I remove the following then the output is
>> OK.
>>
>> if ((rc = EVP_DecryptFinal_ex(&ctx, debuf, &tmplen)) == 0) {
>> printf (" Finalization error: %d\n", rc);
>> return -1;
>> }
>>
>
> You are most probably over-writing the decrypted data you have got with
> EVP_DecryptUpdate. Skip the the length that you have already decrypted in
> debuf. i.e If you have got outlen bytes from DecryptUpdate, you should
> supply "debuf+outlen" as second argument to EVP_DecryptFinal
>
>
>> Can anyone explain why?
>>
>> David
>>
>>
>
