Adding to what Dave has said.
I've done my fair share of "crypto archaeology" to get old systems to
interoperate with modern ones. (In Java)
What you need to be in a lot of cases is creative with how you assemble
the low-level BC primitives so you can mirror what the legacy system
thinks is the correct thing.
Many times (in fact, most of the time) this is "bad use of crypto" or at
the very least "insecure use of crypto" which will probably break as a
protocol in weird and unintended ways.
However, we've all been there, and sometimes you just have to make it
work - but please consider these things.
1. Get it working for now
2. Document what you did to "get it working now" and why, and the pitfalls
3. Plan a migration strategy (if at all possible) to get the systems
and/or data into a state where they're using "modern" algorithms correctly.
Cheers,
-- jon
On 17/02/2016 10:03 AM, David Hook wrote:
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.
