On 8/3/18 8:19 PM, Valerie Peng wrote:
I can file a follow-on issue. However, I want to clarify what we want to
do before filing it.
Based on current exchanges: We want to update
Cipher.getParameters()/CipherSpi.engineGetParameters() with similar
format/wording as Signature.getParameters(), e.g. expanding the meaning
when null is returned.
Yes.
In addition, we also need to change the part of
"same parameters" due to this special PBE parameter handling behavior.
Right?
I think so, but can you add a bit more details on the "special PBE
parameter handling behavior"?
--Sean
Thanks,
Valerie
On 7/31/2018 12:56 PM, Sean Mullan wrote:
On 7/24/18 9:38 PM, Weijun Wang wrote:
Something related.
Cipher has a similar init(..,params) and getParameters() structure
and the spec is also similar.
* <p>The returned parameters may be the same that were used to
initialize
* this cipher, or may contain a combination of default and random
* parameter values used by the underlying cipher implementation if this
* cipher requires algorithm parameters but was not initialized with any.
However, one can supply an incomplete parameters object in init() and
getParameters() will fill in default/random values to make it complete.
For example, in PBE-based Cipher, one can only include salt and
iteration count in the init params, and init() will add in a random
IV, and the IV can be retrieved with getParameters().
Is this something we need to clarify?
Yes, we should update the Cipher API to be consistent with Signature.
I think this can wait until JDK 12 though.
Valerie, can you file a follow-on issue?
Thanks,
Sean
