RFR[11] JDK-8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized

Sean Mullan sean.mullan at oracle.com
Mon Aug 6 14:16:26 UTC 2018


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
> 



More information about the security-dev mailing list