RFR 8171277: Elliptic Curves for Security in Crypto
Adam Petcher
adam.petcher at oracle.com
Fri Mar 9 16:25:41 UTC 2018
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
>>
>>
More information about the security-dev
mailing list