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

Matthew Hall mhall at mhcomputing.net
Mon Mar 3 15:55:55 PST 2014


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


More information about the security-dev mailing list