RFR 8171277: Elliptic Curves for Security in Crypto

[Adam Petcher]

New webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.01/


On 3/8/2018 1:51 PM, Sean Mullan wrote:
> I haven't reviewed all of it (mainly just the standard classes), but 
> here are some comments so far:
>
> - General comments
>
> For new public classes, you don't need to start the sentence with the 
> name of the class since that is implied and will show up in javadoc 
> pages. For example, "XECKey is an interface ..." should just be "An 
> interface ..."
fixed.
>
> I think somewhere there should be a sentence or two on the difference 
> between XECKeys and ECKeys and when you would want to use each. This 
> is important enough that I think some detail should be in the javadoc 
> to help users distinguish them. Perhaps put it in the XEC class 
> description. Maybe more details can go in the JCA security guide.

I added a sentence to the comments in XECKey, but I'm not sure how much 
we should say here. I don't know if we should get into mathematical 
details. Take a look at the new wording and let me know if I should add 
more information.

>
> - ECGenParameterSpec
>
> 45: s/of provider/of the provider/
fixed
>
> - NamedParameterSpec
>
> 36: the link looks wrong, since it is for SSLContext

Oops. I changed the section to "parameter-spec-names" which will be a 
new section that I'll add to this document.

> 39: I think the @see is unnecessary

removed.

>
> - XECKey
>
> The description should include some basic details so someone doesn't 
> have to know what RFC 7748 is to understand it.

Similar response to a previous comment. I added some more information, 
but I don't know if it is enough. Let me know.

>
> - XECPrivateKey
>
> 47: would "cannot" be a more appropriate word than "may not"? May not 
> sounds a bit vague. Perhaps also an example of why it cannot be 
> extracted would be helpful.
>

I changed it to "cannot" and added the example.

> --Sean
>
> On 2/6/18 1:36 PM, Adam Petcher wrote:
>> Webrev: http://cr.openjdk.java.net/~apetcher/8171277/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171277
>>
>> Please review this change that adds key agreement via the X25519 and 
>> X448 elliptic curve functions to the JCA API and SunEC provider. 
>> These functions and related operations and encodings are described in 
>> RFC 7748[1]. This work does not include JSSE integration, which will 
>> be done later as a separate task (not part of JEP 324). The webrev 
>> does not include the field arithmetic code, which is being reviewed 
>> separately[2]. This change is a part of JEP 324, so it will not be 
>> integrated into the repo until all work for that JEP is complete and 
>> it has been targeted to a release.
>>
>>
>> [1] https://tools.ietf.org/html/rfc7748
>> [2] 
>> http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016756.html 
>>
>>