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