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

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


>       o ||
>
> ||
>
> |Gruss|
>
> |Bernd|
>
> -- 
> http://bernd.eckenfels.net
>
> *Von: *mark.reinhold at oracle.com <mailto:mark.reinhold at oracle.com>
> *Gesendet: *Donnerstag, 21. Dezember 2017 20:50
> *An: *adam.petcher at oracle.com <mailto:adam.petcher at oracle.com>
> *Cc: *security-dev at openjdk.java.net <mailto:security-dev at openjdk.java.net>
> *Betreff: *JEP 324: Key Agreement with Curve25519 and Curve448
>
> New JEP Candidate: http://openjdk.java.net/jeps/324
>
> - Mark
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20171222/6fb31b91/attachment.htm>