Okay, I think I see where the confusion is. The problem is we're not really talking about padding - what's really going on is Jaco is just want to process the data block aligned and is setting the spare bytes to zero. I realize that sounds a bit weird, but it does mean that in Jaco's case there isn't any "padding" in some cases, what's really happening is the message is just being rounded up.
I think the trick in this case would be to use the cipher without padding, and just add the zeroes by hand to round up to the next block, then the legacy end should behave properly, or use zero padding and just drop the last block if the data is block aligned. I wouldn't do this for anything new (actually I wouldn't use zero padding period, it was originally added to deal with a legacy issue, although in this case the parties concerned needed the extra block, but I think that's already been covered...) as it makes it impossible to tell if a message has been truncated. One of the advantages of padded modes adding the extra block on block aligned data is that it also gives you some confidence the message is actually complete and well formed - there's always block, or less, of padding to be removed. Decrypting you'll need to use no padding, and then ignore the zeros, so if you're looking for "symmetry" in the way the ciphers are defined, I'd add the zeros by hand on encryption. Regards, David On 17/02/16 04:59, Edward Ned Harvey (bouncycastle) wrote: >> From: Jaco De Villiers [mailto:jac...@infoslips.com] >> >> I have marked the BouncyCastle tests as ignored for now. This project is a >> Portable Class library so I do not have access to the AesManaged class in the >> project. I will continue with the PCLCrypto library for now. What is the >> best >> mechanism to stay informed about the possible fix to the current issue? > Just watch the list, for follow-up to the "Zero padding bug" thread.
