JEP 324: Key Agreement with Curve25519 and Curve448

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

JEP 324: Key Agreement with Curve25519 and Curve448

mark.reinhold
New JEP Candidate: http://openjdk.java.net/jeps/324

- Mark
Reply | Threaded
Open this post in threaded view
|

Re: JEP 324: Key Agreement with Curve25519 and Curve448

Bernd Eckenfels-4

Hello and Yeah!

 

Some minor questions (maybe not relevant for the JEP but the Api):

 

  • would  XDHPublicKeySpec then also be used for EdDSA and if so, is it really the proper Name?
  • For the XDHPublicKeySpec(paramSpec, u)
    • do you plan also a `byte[32] u`Version and
    • do you require to clamp the secret key in this construct beforehand. (If not is there an accessor to get the clamped key?)

 

Gruss

Bernd

--
http://bernd.eckenfels.net

 

Von: [hidden email]
Gesendet: Donnerstag, 21. Dezember 2017 20:50
An: [hidden email]
Cc: [hidden email]
Betreff: JEP 324: Key Agreement with Curve25519 and Curve448

 

New JEP Candidate: http://openjdk.java.net/jeps/324

 

- Mark

 

Reply | Threaded
Open this post in threaded view
|

Re: JEP 324: Key Agreement with Curve25519 and Curve448

Adam Petcher

On 12/21/2017 3:10 PM, Bernd Eckenfels wrote:

Hello and Yeah!

 

Some minor questions (maybe not relevant for the JEP but the Api):


Good timing. We will be finalizing the API next.

 

  • would  XDHPublicKeySpec then also be used for EdDSA and if so, is it really the proper Name?

No. EdDSA keys use a different representation, so they will have different classes and interfaces in order to minimize the risk of misinterpretation.

But the more general form of your question is still valid. We should consider the possibility that these keys may used for things other than Diffie-Hellman in the future (e.g. XEdDSA [1]). In that case, a more general name may be appropriate (e.g. XPublicKeySpec, XECPublicKeySpec). I like the idea of having different types for different uses---this reduces the risk of accidentally using signature keys in Diffie-Hellman, for instance. But I understand that this may be limiting, and adding new types to the API may not be practical. I'm not sure what the right balance is here, and I'm definitely open to suggestions. If anyone has an opinion on what these types should be named, and how general they should be, please share.

[1] https://signal.org/docs/specifications/xeddsa/


  • For the XDHPublicKeySpec(paramSpec, u)
    • do you plan also a `byte[32] u`Version and


We had a discussion earlier on how to represent keys (using either byte[] or BigInteger). If you haven't done so already, you may want to review that discussion[2]. If you have a preference on which representation we should use, now is the time to share it.

I wasn't planning on adding a constructor that takes a byte[]. I think we could do it, but it would be somewhat complicated because the parameter spec doesn't have all the information required to convert the byte[] to a BigInteger. It is missing the number of bits used in the key. We could also pass that information to the constructor, but then you have the problem that it may not agree with the parameter spec. Still, this may be a reasonable thing to add if people think it is worthwhile. Another option is to add utility methods that convert u-coordinates between byte[] and BigInteger.

[2] http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016227.html

    • do you require to clamp the secret key in this construct beforehand. (If not is there an accessor to get the clamped key?)

For public keys, the client (starting from a byte[]) must clear the unused bits and then convert to a BigInteger that is passed to the constructor. For private keys, the spec holds unclamped values. So the client does not need to clamp before passing the array to the constructor. The implementation must clamp the private key value returned by XDHPrivateKeySpec.getScalar() before using it for key agreement.

Adding a method that returns the clamped key is difficult because the spec doesn't have all the information necessary to do the clamping. I could add a clamping method that takes the required parameters (the number of bits in the key and the log of the cofactor), but I don't know if the spec is the best place for this. It seems like it would be more appropriate to add it to some utility class that can be used by XDH implementations, but I don't know if a suitable place exists. As usual, I'm open to suggestions.


 

Gruss

Bernd

--
http://bernd.eckenfels.net

 

Von: [hidden email]
Gesendet: Donnerstag, 21. Dezember 2017 20:50
An: [hidden email]
Cc: [hidden email]
Betreff: JEP 324: Key Agreement with Curve25519 and Curve448

 

New JEP Candidate: http://openjdk.java.net/jeps/324

 

- Mark