Couple of things to test/check next: up to now you've fed it sequences of 8 bytes which, as you report, decrypt correctly.
See what your current code does for longer input sequences. The point is this: if your encrypt code encrypts N bytes and you decrypt the data at the receiver side and those /original/ N bytes show up anywhere in the decrypted output, it means AT LEAST that your encrypt/decrypt processes are 'mirrors' like they should be. It also means the decrypt code uses the same IV as the encrypt code -- assuming there's an IV used AT ALL. Say you encrypt a sequence 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ... then the ENcrypted byte stream should NOT contain this sequence anywhere (after all, it's encrypted!) When the receiver fetches this data (which was sent to it) and DEcrypts it should show one of these DEcrypted data sequences: a) 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ... b) abc1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ... c) 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...xyz or b+c): abc1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...xyz When you don't see any of these, your encrypt/decrypt code does not use the proper keys, IVs, algorithms, whatever. From your previous messages I gather this is NOT your problem as you get to see the (b), (c) or (b+c) case instead (which one, I am not sure from reading your messages). Case (a): perfect. This is what you'd expect case (b): this can ONLY happen when encrypt+decrypt produce/process the _exact_ same encrypted data. (When you use CBC style.) This means that EITHER you fed the encrypt code a pointer/length sequence which was wrong as it pointed at the 'abc' instead of '123' start there, OR somewhere between the output of the DEcrypt and your debug/display code, you prepend the 'abc' in there AFTER decrypting; usual suspect in both case: bugs in your own 'pointer arithmetic' code. case (c): can happen when EITHER you feed the ENcrypter an input sequence with an incorrect (too large) length, so random 'xyz' will be included in the encryption operation, OR as above: length value after decryption gets modified so the extra 'xyz' at the tail is 'included' somewhere while passing the decrypted data to the debug/display code. Usual suspect: incorrect treatment of strings which are assumed to be NUL-terminated but aren't. Other incorrect length-manipulating assumptions in your sender/encrypt and/or client/decrypt code. Etc. A special case which can also cause this is when no length is encoded in the data feed to the decrypter, which then has to 'guestimate' the output (decrypted) length, while the encrypter you use 'pads' the data with zero or random content to ensure block alignment and/or other algorithm-specific requirements are met. This applies to some algorithms, not all, IIRC. (Don't ask me for a list off the top of my head; I don't know them by heart.) case b+c): mix of b+c; the mere fact that the input sequence 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ... is visible after decryption means that at least client and server use matching keys, algorithms and IVs. So if any of b/c/b+c applies to your situation, it means you are either adding those extra header and/or tail bytes yourself before encrypting or after decrypting. WARNING: before you say 'yes, this happens here too' TEST with SEVERAL data sequences of DIFFERENT content AND length. Just to satisfy Mr. Murphy. Last but not least, I wonder why you've written this code. I am probably guessing wrong here, but from what I read in your messages, you are using an SSL connection between client and server to pass data. Then it looks to me like you are writing additional symmetric key encrypt/decrypt code here ON TOP OF THAT. I hope that I am very wrong about that last bit in capitals; if I am correct about that bit however, you are applying a dual layer of encryption (as SSL already encrypts your data too), which introduces all sorts of _very_ interesting (in the sense of raised eyebrows and scratching heads) questions. Summarizing: ------------------- - The exercise may be moot (when used as a second crypto layer on top of SSL). Chance: I don't know. Very low, I hope. It just might... - You need to test several different content / length data inputs and check if they appear 'on the other side' after decrypting the data there. Find out which case applies to your situation: (a), (b), (c), (b+c) or (d)=='none of the above'. Probable faults depend on this case identification. - My guess from far off: problems are VERY probably caused by your custom code manipulating pointers and or (unencrypted input) data length values. - My guess from far off: problems (when case (c)) MAY be due to the use of a 'padding' crypto chain, while not storing actual (a.k.a. 'true') input data length in the data stream to be encrypted. If anyone else reads this and sees a minor or major mistake, please correct me. Thank you. Ger 2008/7/28 abc_123_ok <[EMAIL PROTECTED]>: > I can't fix my problem , anybady can help me? > > ________________________________ > abc_123_ok > 2008-07-28 > ________________________________ > 发件人： abc_123_ok > 发送时间： 2008-07-25 09:35:17 > 收件人： openssl-users@openssl.org > 抄送： > 主题： Re: Re: Re: hello everyone > > Dear Victor Duchovni， > > I knew what you speak as below, > I have added the CBC padding and Mac and record head, but besides these len, > it still have 24 bytes is more. the 24 bytes is before the application > data. > > my problem still can n't be fixed. > > > ________________________________ > abc_123_ok > 2008-07-25 > ________________________________ > 发件人： Victor Duchovni > 发送时间： 2008-07-24 22:02:49 > 收件人： openssl-users@openssl.org > 抄送： > 主题： Re: Re: Re: hello everyone > > On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote: > >> I want to know what the 24 byte is. > > The TLS "record layer" uses a 5 byte header. The actual data > is extended with a MAC, and encrypted which often adds CBC padding. > > You should not make any assumptions about the length of the encrypted > data on the wire, there may also be packets for renegotiation if the > client or server chooses to do that. > > -- > Viktor. > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -------------------------------------------------- :��I"袭��r�m���� (ラ觳Z+�K �+│��1ē�x ��hラ觳[�z�(ラ觳Z+� ��f�y意灿�� �f＂�h��)z{,��
