CipherInputStream for AEAD modes is insecure (GCM, etc.): ciphertext tampering without detection possible

[Valerie (Yu-Ching) Peng]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140303/9d7953df/attachment.htm>