OK, I undertand now:
1. Crypto primitives (Signature/KeyFactory/KeyPairGenerator) would support all
"EdDSA" and "Ed25519"/"Ed448", and their getAlgorithm() returns what was used
back in getInstance().
2. Key's getAlgorithm() always returns "EdDSA".
Thanks,
Max
> On Apr 4, 2020, at 6:02 AM, Anthony Scarpino <anthony.scarp...@oracle.com>
> wrote:
>
> 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.scarp...@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
>
