Hi, I resolved this issue although I am still a little confused about the error that I was getting previously. I am outlining the steps that I did before when I had the error and what I did to overcome it, so that some kind soul here can enlighten me as to why I got the error in the first place.
I have with me the packets obtained from a SSL conversation. I am using AES256_CBC for the encryption. Also, I have the connection keys(master key and 2 oiv's) that are being used. I had earlier sent across a few messages from my SSL server to client and have been able to decrypt the captured packets. Now I sent across a larger sized message(about 20 bytes or so.) *Before -> Error* The packet dump that I have is 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82 e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86 d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8 3c 15 3d e9 c7 This is actually two packets but they both were sent for a single application message (They are fragmented packets). After the usual intialisation steps, I called EVP_DecryptUpdate() and EVP_DecryptFinal_ex(). EVP_DecryptFinal_ex() returns 0 (error). Also, only the first half of my application has been decrypted properly, the second half has not been decrypted properly. I initally thought that the decryption failed and to test this, I sent across a few messages from the same server to the same client in the same SSL session. Hence, the original iv's and master key being used is the same, but the current iv is different because decryption has failed earlier. But I am still able to send across (short) messages and decrypt them to obtain the cleartext. *After Debugging -> No Error now.* I did the same as before, but before passing the packet dump to EVP_DecryptUpdate(), I defragmented the packet dump, so now my packet dump looks like this. 17 03 01 00 40 85 99 2a 94 4d 0e 56 2c 81 bc fc 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82 e9 ab cf 77 e7 76 68 51 17 9e 86 d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8 3c 15 3d e9 c7 This packet dump is smaller by 5 bytes (The second packet header has been removed.) and the size field at byte 4 has been updated to the sum of bytes in both packets. Now, I am able to send across messages of any size and receive them and so, my program works great. But I still puzzled as to why I got the error as before? Because I am using CBC, if my decryption fails at any one stage, I should not be able to decrypt any further packets right? Thanks and Regards, Vijay K. * *On Wed, Jun 25, 2008 at 12:07 PM, Vijay Kotari <[EMAIL PROTECTED]> wrote: > I am using the traffic obtained from s_server and s_client sample programs > and the keys that have been negotiated by both the programs to decrypt the > encrypted traffic between the two. That would mean that I am using TCP. > Also, I am running them under the CBC mode. > > Vijay K. > > > On Wed, Jun 25, 2008 at 11:35 AM, Julian <[EMAIL PROTECTED]> wrote: > >> It's hard to approach this without knowing the mode of operation you are >> running CBC, OFB, CTR? Also are you using UDP with varying packet sizes? >> >> Julian >> >> >> On Jun 24, 2008, at 10:25 PM, Vijay Kotari wrote: >> >> Hi, >>> I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a >>> SSL packet that I have captured. The cipher that I am using AES256 and >>> I can read the application data in cleartext as a result. The problem >>> comes if the application data size > 8, which I think has something to >>> do with me using a block cipher. I can't seem to decrypt the data >>> then. Anyways, after inspecting the packet dumps, I realized that >>> sometimes I get fragmented packets. >>> For Example, >>> 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc >>> 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82 >>> e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86 >>> d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11 >>> 2b 18 b1 8d d8 3c 15 3d e9 c7 >>> This is actually two packets that are using the SSL application >>> protocol, each of size 0x20 (The second packet starts on line 3, 6th >>> byte onwards). While decrypting, should both these packets be merged >>> together and hence treated as a single packet of size 0x40 or should >>> packet be processed separately. Since, we are using a block cipher of >>> size 256 bits(32 bytes), will it even make a difference? >>> >>> >>> Thanks and Regards, >>> Vijay Kotari >>> >> >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List [email protected] >> Automated List Manager [EMAIL PROTECTED] >> > >
