JDK-8012900 : CICO ignores AAD in GCM mode
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-04-20
  • Updated: 2023-12-05
  • Resolved: 2013-11-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u191Fixed 8 b113Fixed openjdk7uFixed
Related Reports
Duplicate :  
Relates :  
Description
CipherInputStream (and probably CipherOutputStream) don't take into account additional authenticated data in GCM mode.
Comments
The underlying Cipher object should throw AEADBadTagException when fake AAD is supplied. However, CipherInput/OutputStream classes would swallow all non-IOException as its javadoc has been specified. Thus, you won't observe any exception. The only indication of a decryption failure is that the recovered text is empty. Personally, I find this only-IOException-are-passed-through behavior potentially confusing. But that's what the javadoc has. Note that this also means that when decrypting data with corrupted padding bytes, partial data are returned. Not sure about the reason for the current spec. But that's how it is unless we change the spec.
08-11-2013

Can you please attach the failed SQE test, i.e. jce/Cipher/AEAD/JDK_8012900? When I tried to access the aurora report on the src of the failed test, it gives me a HTTP 500 file not found error http://aurora-ds.us.oracle.com:9502/core-libs-testbase-local/8_int/src/jce/Cipher/AEAD/JDK_8012900
07-11-2013

Bug was re-opened by mistake. This bug is pending verification.
04-11-2013

The affected testcases still failed in aurora nightly: RULE jce/Cipher/AEAD/JDK_8012900 Exception java.lang.Exception: A decryption has been perfomed successfully in spite of the decrypt Cipher has been initialized with fake AAD Batch link: http://aurora.ru.oracle.com/functional/faces/RunDetails.xhtml?names=312446.CORELIBS-JDK8-NIGHTLY-SQE-4 Log: http://aurora-ds.us.oracle.com:9500/runs%2F312446.CORELIBS-JDK8-NIGHTLY-SQE-4/results/ResultDir/JDK_8012900/JDK_8012900.log
04-11-2013

URL: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3da8be8d13bf User: lana Date: 2013-10-22 17:23:08 +0000
22-10-2013

URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3da8be8d13bf User: valeriep Date: 2013-10-09 20:28:01 +0000
09-10-2013

RULE jce/Cipher/AEAD/JDK_8012900 Exception java.lang.Exception: A decryption has been perfomed successfully in spite of the decrypt Cipher has been initialized with fake AAD
30-09-2013

Affected tests: jce/Cipher/AEAD/JDK_8012900
07-06-2013

The tag is only verified during Cipher.doFinal() calls for AEAD ciphers. However, when the tag verification failed, the AEADBadTagException which extends BadPaddingException is swallowed by CipherOutputStream class as only IOException is allowed per its javadoc specification of close() method. Some extensive changes to current GCM mode may be necessary if we were to buffering up all processed plain text in decryption mode until the tag verification passed. Otherwise, the processed plain text would already be written out and accessible to callers even when the tag verification failed.
09-05-2013

Cipher Input /Cipher Output Stream (CICO).
25-04-2013

What is CICO?
25-04-2013

The encryption function should compute an authentication tag on both - the confidential and any additional non-confidential authenticated data (AAD). The attachment contains the test to verify if the CICO works properly in AEAD/GCM mode. The test used different additional authenticated data for encryption and decryption Ciphers (lines 42 and 46). But in spite of that it passes. Original and restored data are the same. It seems CipherInputStream ignores additional authenticated data at all. product tested: jdk8 b85 steps to reproduce: compile and execute attachment. It pass. I guess it should fail.
20-04-2013