[RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

[Anthony Scarpino]

On 4/2/20 8:34 PM, Weijun Wang wrote:
> Another question:
> 
> Why does getAlgorithm() of PublicKey and PrivateKey return "EdDSA"
> instead of "Ed25519" and "Ed448"?
> 
> Do we suggest people using "EdDSA" or "Ed25519"/"Ed448" when calling
> KeyFactory.getInstance() andKeyPairGenerator.getInstance()?

I don't think the code is suggesting anything. I believe the 
implementation is trying to be consistent with the API and other 
asymmetric keys factories and generators.  Just using EC as an example 
one uses "EC" for the getInstance() and provides the 
AlgorithmParameterSpec to generate the publicKey

kf = KeyFactory.getInstance("EC");
ECParameterSpec.ep = ..
kf.generatePublicKey(ep)

Being consistent for EDDSA, replace "EC" with "EDDSA" and specify a 
NamedParameterSpec to generate the public key; however, it is allowed to 
replace "EC" with ED25519. Similar to how XDH does it. Unfortunately 
generatePublicKey requires an AlgorithmParameterSpec, which is redundant 
in this case:
---
kf = KeyFactory.getInstance("ED25519")
...
kf.generatePublicKey(NamedParameterSpec.ED5519);
---

Since existing code follows the first example we should be consistent 
for apps adding EDDSA.

For KeyPairGenerator, initialize() isn't required to be called with 
getInstance("ED25519") to generate the key, but it will accept an 
initialize() call.  What's different is "EDDSA" will default to ED25519 
and does not require initialize(), but it will accept initialize() to 
change it to ED448.  I believe this is to be consistent with EC and RSA 
that need initialize().

To complete all the EDDSA entries, Signature is different because, the 
key provides the details about the curve.  It's similar to 
KeyPairGenerator, "EDDSA" doesn't lock you into a particular curve, 
allowing the key to specify the curve, which follows the EC/RSA logic. 
Specifying the curve at getInstance() locks you into that curve so at 
least NoSuchAlgorithm will be thrown at getInstance() unlike other 
asymmetric algorithms.

So to wrap all this up, it makes sense for consistency with prior 
behavior that all 3 classes have an EDDSA entry.  And the specific curve 
usage is also consistent with what has already been integrated with XDH.

Tony


> 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
>