Well, this is just my speculation. But I think the reason that
CipherInputStream swallows BadPaddingException is as its javadoc class
description had:
*This class adheres strictly to the semantics, especially the failure
semantics, of its ancestor classes java.io.FilterInputStream and
java.io.InputStream.* This class has exactly those methods specified in
its ancestor classes, and overrides them all. *Moreover, this class
catches all exceptions that are not thrown by its ancestor classes.* In
particular, the |skip| method skips, and the |available| method counts
only data that have been processed by the encapsulated Cipher.
Just my .02,
Valerie
On 03/03/14 15:55, Matthew Hall wrote:
It's fair to say that returning unchecked data is a provider problem, but we
should also try to find the explanation why the JRE swallows important
cryptographic exceptions, as that's not usually recommended practice in Java.
Matthew.
On Mon, Mar 03, 2014 at 03:49:49PM -0800, Valerie (Yu-Ching) Peng wrote:
I view this more as a major vulnerability in BC provider than
javax.crypto.CipherInputStream class and this should be reported to
BouncyCastle so they can fix their provider code.
If you tried the same test with SunJCE provider, you will find that
none of the decrypted data is returned to the caller when the tag
doesn't match. If the providers weren't modified to not returning
any of the decrypted data AFTER the tag is verified, the root cause
is not fixed and you can simply use Cipher to get hold of the
decrypted data instead.
Thus, CipherInputStream class ignores AEADBadTagException isn't
really the problem here, as the some of the decrypted data may have
been returned to the caller before the tag is verified. Whether
AEADBadTagException is ignored or not doesn't matter here.
Regards,
Valerie
