JEP for X25519/X448 key agreement

Anders Rundgren at
Fri Sep 22 05:27:47 UTC 2017

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


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

More information about the security-dev mailing list