JDK-8180392 : SunJCE provider should throw exceptions for unsupported mode and padding combinations
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-05-15
  • Updated: 2020-03-09
  • Resolved: 2019-07-25
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 14
14 b08Fixed
Related Reports
CSR :  
JDK-8240776 - SunJCE provider should throw exceptions for unsupported mode and padding combinations
Relates :  
JDK-8180307 - Update JDK 9 Required Cipher Algorithms
Relates :  
JDK-8229214 - Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/
Relates :  
JDK-8228668 - compiler/codegen/aes/TestAESMain.java failed with GCM mode must be used with NoPadding
Sub Tasks
JDK-8229043 :  
Release Note: SunJCE Provider Throws NoSuchAlgorithmException for AES/GCM/PKCS5Padding - Closed
Description
SunJCE provider does not support CTR, CTS, and GCM modes with PKCS5Padding. However, the current implementation will silently ignore the specified PKCS5Padding and return implementations which use no padding. This should be fixed. When Cipher.getInstance(...) is called upon SunJCE provider with these unsupported mode and padding combination, an exception should be thrown.

Proof of concept:

    Cipher.getInstance("AES/GCM/PKCS5Padding");

does not fail.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/445c32471dc6 User: valeriep Date: 2019-07-25 21:51:29 +0000
25-07-2019
Yes, I noticed this above issue when exploring the fix. Currently, SunJCE provider lists all supported mode and padding as attributes. However, if JCA found the desired mode and padding in the attribute value, then it will proceed and won't actually set the mode and padding until a later point. So, unsupported mode and padding combinations aren't detected in the Cipher.getInstance(String transformation) calls. I think we should fix JCA to set the mode and padding even if both are found in the supported values to confirm that the combination is still supported.
16-05-2017
May also be a related issue if you specify ISO10126Padding. The following code: Cipher c = Cipher.getInstance("AES/GCM/ISO10126Padding"); System.out.println(c.getProvider()); throws this Exception: Exception in thread "main" java.security.ProviderException: Could not construct CipherSpi instance at java.base/javax.crypto.Cipher.chooseFirstProvider(Cipher.java:804) at java.base/javax.crypto.Cipher.getProvider(Cipher.java:928) at Test.main(Test.java:14) Caused by: javax.crypto.NoSuchPaddingException: GCM mode must be used with NoPadding at java.base/com.sun.crypto.provider.CipherCore.setPadding(CipherCore.java:298) at java.base/com.sun.crypto.provider.AESCipher.engineSetPadding(AESCipher.java:212) at java.base/javax.crypto.Cipher$Transform.setModePadding(Cipher.java:377) at java.base/javax.crypto.Cipher.chooseFirstProvider(Cipher.java:791) ... 2 more
16-05-2017