JEP for X25519/X448 key agreement

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

JEP for X25519/X448 key agreement

Adam Petcher
The JEP for X25519/X448 key agreement[1] is now available and ready to
review. Please take a look and reply with any feedback you have.

The JEP contains a description of the proposed JCA API. We have
discussed the API on this mailing list, and I have attempted to
incorporate all the feedback I have received. Here is a description of
the changes since the last discussion:

1) Multiple people requested more specific types for public/private keys
for this algorithm. The latest API design mirrors the "EC" hierarchy and
has both interfaces and spec classes for public and private keys. I also
added the interface "XDHKey", which serves the same purpose as "ECKey".
2) The representation of public keys was changed from byte[] to a
BigInteger which holds the u coordinate of the point. Private keys are
still represented using byte[] due to complications related to pruning,
and also because BigInteger doesn't provide a branch-free way to get the
key into another representation (which is necessary for
side-channel-resilient implementations).

The proposed API still lacks a standard way to specify arbitrary domain
parameters, but I believe the API design could be extended to support
this feature. I would prefer to add this API as a separate enhancement
in the future, preferably in cooperation with someone who is developing
a provider that supports this feature.


[1] https://bugs.openjdk.java.net/browse/JDK-8181595

Reply | Threaded
Open this post in threaded view
|

Re: JEP for X25519/X448 key agreement

Adam Petcher
I would like to leave this open for feedback for another week or so.
Please reply with your comments by Saturday, September 30, end of day,
anywhere on earth. After that time, I plan to move on to the next phase
of the process (group lead and architect review prior to submission).


On 9/14/2017 12:59 PM, Adam Petcher wrote:

> The JEP for X25519/X448 key agreement[1] is now available and ready to
> review. Please take a look and reply with any feedback you have.
>
> The JEP contains a description of the proposed JCA API. We have
> discussed the API on this mailing list, and I have attempted to
> incorporate all the feedback I have received. Here is a description of
> the changes since the last discussion:
>
> 1) Multiple people requested more specific types for public/private
> keys for this algorithm. The latest API design mirrors the "EC"
> hierarchy and has both interfaces and spec classes for public and
> private keys. I also added the interface "XDHKey", which serves the
> same purpose as "ECKey".
> 2) The representation of public keys was changed from byte[] to a
> BigInteger which holds the u coordinate of the point. Private keys are
> still represented using byte[] due to complications related to
> pruning, and also because BigInteger doesn't provide a branch-free way
> to get the key into another representation (which is necessary for
> side-channel-resilient implementations).
>
> The proposed API still lacks a standard way to specify arbitrary
> domain parameters, but I believe the API design could be extended to
> support this feature. I would prefer to add this API as a separate
> enhancement in the future, preferably in cooperation with someone who
> is developing a provider that supports this feature.
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8181595
>

Reply | Threaded
Open this post in threaded view
|

Re: JEP for X25519/X448 key agreement

Anders Rundgren
On 2017-09-21 17:25, Adam Petcher wrote:
> I would like to leave this open for feedback for another week or so.
> Please reply with your comments by Saturday, September 30, end of day,
> anywhere on earth. After that time, I plan to move on to the next phase
> of the process (group lead and architect review prior to submission).

This proposal doesn't appear fundamentally different than the one I drafted on
https://github.com/cyberphone/java-cfrg-spec sometimes ago.

So I'm obviously OK with that but still have a question: How do you envision
the corresponding signature algorithms will be supported?  IMO, it would
be useful knowing that before casting things in concrete.

Just for my curiosity, if somebody wanted to implement other variants of
XDH curves, would the proper way to do that be through using a new
provider name (like "XDH-1") while still using the XDH classes and
interfaces?

Anders


>
>
> On 9/14/2017 12:59 PM, Adam Petcher wrote:
>> The JEP for X25519/X448 key agreement[1] is now available and ready to
>> review. Please take a look and reply with any feedback you have.
>>
>> The JEP contains a description of the proposed JCA API. We have
>> discussed the API on this mailing list, and I have attempted to
>> incorporate all the feedback I have received. Here is a description of
>> the changes since the last discussion:
>>
>> 1) Multiple people requested more specific types for public/private
>> keys for this algorithm. The latest API design mirrors the "EC"
>> hierarchy and has both interfaces and spec classes for public and
>> private keys. I also added the interface "XDHKey", which serves the
>> same purpose as "ECKey".
>> 2) The representation of public keys was changed from byte[] to a
>> BigInteger which holds the u coordinate of the point. Private keys are
>> still represented using byte[] due to complications related to
>> pruning, and also because BigInteger doesn't provide a branch-free way
>> to get the key into another representation (which is necessary for
>> side-channel-resilient implementations).
>>
>> The proposed API still lacks a standard way to specify arbitrary
>> domain parameters, but I believe the API design could be extended to
>> support this feature. I would prefer to add this API as a separate
>> enhancement in the future, preferably in cooperation with someone who
>> is developing a provider that supports this feature.
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8181595
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: JEP for X25519/X448 key agreement

Adam Petcher

On 9/22/2017 1:27 AM, Anders Rundgren wrote:

On 2017-09-21 17:25, Adam Petcher wrote:
I would like to leave this open for feedback for another week or so.
Please reply with your comments by Saturday, September 30, end of day,
anywhere on earth. After that time, I plan to move on to the next phase
of the process (group lead and architect review prior to submission).

This proposal doesn't appear fundamentally different than the one I drafted on
https://github.com/cyberphone/java-cfrg-spec sometimes ago.

So I'm obviously OK with that but still have a question: How do you envision
the corresponding signature algorithms will be supported?  IMO, it would
be useful knowing that before casting things in concrete.

After the last round of API review, I developed an initial API design (and prototype implementation) for EdDSA to help address questions like this. I'll share a summary of the initial EdDSA API design for the purpose of evaluating the X25519/X448 JEP, but please don't pay too much attention to the details. We will review the EdDSA API separately in the future.

The EdDSA API will be similar to the X25519/X448 design. We can use the string "EdDSA" to identify the algorithm across all services. There are some naming issues to sort out for EdDSA, especially related to algorithm variants and selection of hash functions. These issues don't seem to impact X25519/X448, so we can sort them out later.

We will develop interfaces and key specs for EdDSA public/private keys, with a structure that is similar to the one in XDH. Private keys will be represented using byte arrays. Public keys are points, and it would probably be best to add a new class for compressed Edwards curve points (which have a BigInteger y coordinate and a boolean for the x coordinate), but there may be other good options here.

EdDSA has some additional algorithm parameters, such as the variant (pure, pre-hash, or context) and the context value. So we would need an EdDSAParameterSpec class to hold these parameters along with the curve parameters. The curve parameters will be stored in the EdDSAParameterSpec as an AlgorithmParameterSpec, allowing them to be specified using a NamedParameterSpec or any other method of specifying an Edwards curve.



Just for my curiosity, if somebody wanted to implement other variants of
XDH curves, would the proper way to do that be through using a new
provider name (like "XDH-1") while still using the XDH classes and
interfaces?

If a provider wants to support some other curve, then a simple way to do this would be to use the algorithm name "XDH", and specify the name of the curve in the NamedParameterSpec. All of the XDH key interfaces and spec classes can still be used. This is similar to how providers support different named curves using ECGenParameterSpec today. Example client code (using a hypothetical named curve "X480"):

KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH");
NamedParameterSpec paramSpec = new NamedParameterSpec("X480");
kpg.initialize(paramSpec); 
KeyPair kp = kpg.generateKeyPair();

KeyFactory kf = KeyFactory.getInstance("XDH");
BigInteger u = ...
XDHPublicKeySpec pubSpec = new XDHPublicKeySpec(paramSpec, u);
PublicKey pubKey = kf.generatePublic(pubSpec);

KeyAgreement ka = KeyAgreement.getInstance("XDH");
ka.init(kp.getPrivate());
ka.doPhase(pubKey, true);
byte[] secret = ka.generateSecret();

Using a different algorithm name may also be a reasonable option, since you could simply define (for example) "X480" as an algorithm. But this is similar to the example above, and the provider should probably define "X480" as "XDH" initialized with the "X480" NamedParameterSpec.


Anders




On 9/14/2017 12:59 PM, Adam Petcher wrote:
The JEP for X25519/X448 key agreement[1] is now available and ready to
review. Please take a look and reply with any feedback you have.

The JEP contains a description of the proposed JCA API. We have
discussed the API on this mailing list, and I have attempted to
incorporate all the feedback I have received. Here is a description of
the changes since the last discussion:

1) Multiple people requested more specific types for public/private
keys for this algorithm. The latest API design mirrors the "EC"
hierarchy and has both interfaces and spec classes for public and
private keys. I also added the interface "XDHKey", which serves the
same purpose as "ECKey".
2) The representation of public keys was changed from byte[] to a
BigInteger which holds the u coordinate of the point. Private keys are
still represented using byte[] due to complications related to
pruning, and also because BigInteger doesn't provide a branch-free way
to get the key into another representation (which is necessary for
side-channel-resilient implementations).

The proposed API still lacks a standard way to specify arbitrary
domain parameters, but I believe the API design could be extended to
support this feature. I would prefer to add this API as a separate
enhancement in the future, preferably in cooperation with someone who
is developing a provider that supports this feature.


[1] https://bugs.openjdk.java.net/browse/JDK-8181595