[RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)
Anthony Scarpino
anthony.scarpino at oracle.com
Tue Mar 31 04:25:18 UTC 2020
On 3/30/20 8:52 PM, Anthony Scarpino wrote:
> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>
>>
>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino
>>> <anthony.scarpino at oracle.com> wrote:
>>>
>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>> I was playing with keytool with your patch and noticed
>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>> describe the parameters, the size is still useful in determining the
>>>>> strength.
>>>> I think I should be able to access the parameter with the key's
>>>> NamedParameterSpec to return the size.
>>>
>>> I was wrong about this. The parameters are part of jdk.crypto.ec
>>> while KeyUtil is part of java.base, so I cannot access the internal
>>> EdDSAParameters class.
>>>
>>> The easiest way would be to look at the NamedParameterSpec and return
>>> a hardcoded length based on the curve used. It's not ideal, but all
>>> these curves don't change lengths unlike for RSA, AES, etc.
>>
>> Yes.
>>
>>>
>>> Tony
>>>
>>>>>
>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>> Because the public API for engineGetParameter(String param) is
>>>> deprecated would be my suspicion.
>>
>> engineGetParameter() is deprecated, engineGetParameters() is not.
>
> Oh sorry. I'm not sure why, but I have to ask the question what is the
> point of this method? If the user needs to set the parameters to do the
> a signature of verify, what is the need for a method that gets the
> parameter from Signature that should have just set? Are the parameters
> returned changed from the initial setting? In the EdDSA case they are not.
>
> I don't have an immediate problem in having EdDSA return the same
> parameters back, I'm just not sure why it's necessary and I haven't see
> anything in the JEP as to why Adam decided against this.
>
> Tony
Ok.. That's frustrating that engineSetParameters takes
AlgorithmParameterSpec, but engineGetParameters returns
AlgorithmParameter. That confused me.
So I would say the reason EdDSASignature.engineGetParameters() is UOE is
because the parameters are not exposed publicly. The NamedParameterSpec
tells the internals of EdDSA what parameters to use. I know this to be
a choice by Adam as he found it unnecessary to expose APIs that were
unnecessary at this time with predefined EdDSA curves and with a
implementation that did not allow arbitrary curves.
Tony
>
>>
>>>>> Another small problem:
>>>>>
>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>> module-info.java, keytool/Main.java.
>>>> The copyright has not been reverted, the jdk repo was updated to
>>>> 2020 from another changeset.
>>
>> Ah yes, I applied your patch to my old repo.
>>
>> --Max
>>
>>>>>
>>>>> Thanks, Max
>>>>>
>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>
>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>> Hi I need a code review for the EdDSA support in JEP 339. The
>>>>>>> code builds on the existing java implemented constant time
>>>>>>> classes used for XDH and the NIST curves. The change also adds
>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>
>>>>>>
>>>>>> I updated the webrev with some minor updates that were commented
>>>>>> previously.
>>>>>>
>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>
>>>>>> Tony
>>>>>
>>>
>>
>
More information about the security-dev
mailing list