Fix Version/s: tbd
Compatibility Risk Description:There is the possibility that developers may be using fully-qualified PBES2 names (e.g. PBEWith<prf>And<encryption>) but use any DER encoding to initialize it. The same may happen with the AlgorithmParameterSpec form of init() though in this latter case use of the resulting object will almost certainly cause an error if the contents of the PBEParameterSpec are invalid.There is the possibility that developers may be using fully-qualified PBES2 names (e.g. PBEWith<prf>And<encryption>) but use any DER encoding to initialize it. The same may happen with the AlgorithmParameterSpec form of init() though in this latter case use of the resulting object will almost certainly cause an error if the contents of the PBEParameterSpec are invalid.
Support additional pseudo random functions (PRFs) and encryption schemes. Provide better fail-fast error checking during initialization.
JDK-8076999 outlined multiple processing issues with PBES2-based
AlgorithmParameters. Some of these issues were fixed as part of JDK-8202837, but one issue (additional algorithm support) remained unaddressed. During the fix for this remaining issue, other problems were uncovered in the state machine for PBES2-based
AlgorithmParameters initialization which necessitated further behavioral changes.
The solution has multiple components:
Additional PRF and Cipher support:
AlgorithmParameters only supports the following combinations of pseudorandom functions (PRFs) and Ciphers:
These strings are used to create a standard name used with
AlgorithmParameters of the form
PBEWith<prf>And<cipher> (e.g. PBEWithHmacSHA256AndAES_256). When initialized via the
init(byte) method, only those DER encodings that advertise the above PRFs and Ciphers can be successfully processed.
This fix will now allow the SunJCE provider's
AlgorithmParameters PBES2 implementation to accept encodings that advertise the HmacSHA512/224 and HmacSHA512/256 PRFs and the following additional ciphers: AES_192, DES, DESede (Triple-DES), RC2, and RC5. These algorithms all have
AlgorithmParameterSpec classes designed for them and are detailed in RFC 8018.
Accepting these new algorithms in the PBES2 parameter encodings only covers the PBES2 parameters themselves. It does not guarantee PBE
SecretKeyFactory support in the SunJCE provider. The
AlgorithmParameters object may be used with other JCE providers' Cipher and/or SecretKeyFactory implementations.
We are proposing two new AlgorithmParameters standard names in the SunJCE provider:
|PBES2||A generic PBES2
The algorithm string "PBES2" can be used to instantiate a generic PBES2-based
AlgorithmParameters object that can accept DER-encodings with the any of the supported PRFs and Ciphers listed above.
Improved Initialization Fail-Fast Behavior
There are two ways to instantiate PBES2-based
AlgorithmParameters objects. The first is by a generic name "PBES2". The second is via a fully-qualified name indicating the PRF and encryption scheme (e.g. PBEWithHmacSHA256AndAES_128). Initialization can happen either by providing DER encoded parameter data as a byte array or via an
AlgorithmParameterSpec. The current interactions between instantiation and initialization methods allowed certain combinations to cause incompatibilities that were not caught at initialization time, and would only happen when later used by the consumer of the AlgorithmParameters object. The following section details how this will be corrected.
Consistency Between Fully-Qualified Name and Encoding
In the current implementation it is possible to create the object using a string such as "PBEWithHmacSHA256AndAES_128", but initialize it with DER encodings using a different PRF and/or encryption scheme. The proposed changes will cause an
IOException to be thrown on the
init methods that take DER encodings when either the PRF or encryption scheme OIDs do not match the requested types in the
getInstance() call. These init methods already throw IOException on decoding errors, but this behavioral change makes the SunJCE implementation adhere more strictly to the specification by requiring better consistency between the requested and received algorithm types in the encoding.
Consistency Between Fully-Qualified Algorithm Name and Provided AlgorithmParameterSpec
Another method of initialization can happen through the submission of an
AlgorithmParameterSpec (specifically a
javax.crypto.spec.PBEParameterSpec). The PBES2 Cipher may itself have additional configuration options provided to it via
Currently, there is no checking performed to ensure that the
AlgorithmParameterSpec retrieved by
PBEParameterSpec.getParameterSpec() matches the type appropriate for the Cipher. The proposed change will now check the Cipher
AlgorithmParameterSpec to make sure it is the correct type. Failure to use the correct class or derived subclass from that type will cause
InvalidParameterSpecException to be thrown. The table below shows a sample fully qualified name and its corresponding Cipher's 'AlgorithmParameterSpec' type:
Because there are multiple encryption schemes that use the same
AlgorithmParameterSpec concrete class, the generic "PBES2" standard name cannot be used to instantiate the PBES2
AlgorithmParameters object if
init(AlgorithmParameterSpec) is used. If this is attempted,
InvalidParameterSpecException will be thrown.
In addition to type enforcement, when the
init(AlgorithmParameterSpec) method is used the contents of the
AlgorithmParameterSpec will be tested to make sure the values are consistent with the algorithm they are configuring. For instance, if AES is selected, a provided
IvParameterSpec will have the output length from the
getIV() method tested to make sure it is 16 bytes.
RC5: Standard name for the RC5_CBC_Parameters encoding as an
PBES2: Standard name for generic PBES2