Right on Peter! The return value from DoFinal actually tells me the meaningful bytes I need to care after looking into BC source code yesterday. For now that's all I need though still not sure why the padding is all 0x00 not actually value. Again thanks a lot for your great help!!
From: Peter Dettman [mailto:peter.dett...@bouncycastle.org] Sent: Thursday, February 19, 2015 8:44 AM To: Li, Roger; dev-crypto-csharp@bouncycastle.org Subject: Re: [dev-crypto-csharp] AES 256 CBC PKCS7Padding gives me null (0x00) padding after decryption Hi Roger, It's hard to know for sure without a code sample, but it seems likely you are ignoring the return value from DoFinal (and/or ProcessBytes), which will tell you how many bytes were actually output by that call. The "extra" zeroes are not part of the output. GetOutputSize can be used to find out the maximum size buffer you'll need to hold the whole output, but it is not (always) exact, so one still needs to pay attention to the ProcessBytes/DoFinal return values to track the current position in the output buffer and the actual total length. Regards, Pete Dettman On 19/02/2015 3:09 am, Li, Roger wrote: Hi Group, I just start learning BC for AES encryption/decryption and am using AES/CBC/PKCS7PADDING for 256 bits. BC can encrypt and decrypt text successfully, however after decryption I notice that there are always a few padding of null (0x00), which therefore fails my hash comparison. For example, suppose original input string is "1234567890", the decrypted byte array is always {0x49,0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x48,0x00,0x00,0x00,0x00,0x00,0x00}. Why the padding is not 0x06,0x06,0x06,0x06,0x06,0x06? And is there any way to deterministically tell the padding length (could be 0) after encryption so that I can get exactly the same string before encryption? Thanks a lot! Roger
