> From: Jaco De Villiers [mailto:jac...@infoslips.com] > > BouncyCastle actually created the extra block in > encryption, and expects it again in decryption, because if I strip the extra > block then it doesn't decrypt.
Correct. If your data is, for example, 0xFF00.FF00, and you zero-pad it to 16 bytes, it will be 0xFF00.FF00.0000.0000.0000.0000.0000.0000 before it gets encrypted to some ciphertext block of 16 bytes. Then, you'll decrypt the ciphertext, to again retrieve the 16 bytes that include zero padding. *After* decryption, you need to eliminate the extra zeroes from the end of your data. In this example, the data ends with 00, so you'll need some external way to determine the number of bytes to strip off the end. I see what's causing your confusion though - I noticed that if the input is a multiple of 16 bytes long, it gets padded with a whole block of all zeroes, which I'm pretty sure shouldn't happen. I'll post a separate email to the list about it, as I'm pretty sure that's a bug, and it will be easier to create a separate thread to discuss it. In the meantime, since you're using ECB mode, you can just recognize that whenever your plaintext is a multiple of 16 bytes long, it will come out with ciphertext that is 16 bytes extra long (you can discard the last 16 bytes). During decryption, you might need to specify no padding. Alternatively, you might be able to use the .NET AesManaged class (instead of bouncycastle AesEngine).
