RFR: 8209038: Clarify the javadoc of Cipher.getParameters()

[Xue-Lei Andrew Fan]

On Wed, 6 Apr 2022 19:17:38 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/Cipher.java line 1051:
>> 
>>> 1049:      * Returns the parameters used with this cipher.
>>> 1050:      *
>>> 1051:      * <p>If this cipher has been previously initialized with parameters,
>> 
>>> If this cipher has been previously initialized with parameters, this method returns the same parameters.
>> 
>> Previously, "may" is used ("may be the same ...").  This change looks too strict for compatibility.  I had a look at the AES implementation, the parameters initialized with init() could be filtered and modified before saving the parameters related class fields.
>
> Can you be more specific like which block of code that you are referring to as the filtering and modification?
> I'd expect the intention is to use the parameter specified. Otherwise an exception should be thrown if the specified parameter is invalid. Only when no parameter is specified, the provider would try to generate the parameters using whatever values it has or got.

I read the following methods in com.sun.crypto.provider.CipherCore:

    void init(int opmode, Key key, AlgorithmParameterSpec params,
            SecureRandom random)

where the 'params' are converted to IV byte array for further processing. 


    void init(int opmode, Key key, AlgorithmParameters params,
              SecureRandom random)

where the spec is retrieved from the 'params', and then pass the call to the init() method above.


    AlgorithmParameters getParameters(String algName) {

where the returned parameters are re-constructed.

It may be fine to use a strict spec, but there is a chance to have compatibility impact unless we check the implementation carefully.  It may not worthy the risks as a behavioral update may be not necessary for developers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8117