On 8/8/2017 12:50 PM, Michael StJohns wrote:
We'll leave this for later. But generally, the JCA is a general interface to a set of crypto primitives modeled on just a few key types. To go in the direction you want to go it you need to explain why its impossible to model an elliptic curve as an elliptic curve. As I noted, I think that the inclusion of extension of ECField is probably all that's necessary for representing both public and private key pairs here.
The problem with the existing EC classes (EllipticCurve, ECPoint, etc.) is that they are intended to represent curves in Weierstrass form: y^2 = x^3 + ax + b. EllipticCurve has two parameters "a" and "b" corresponding to the coefficients in the equation above. RFC 7748 uses elliptic curves in Montgomery form: y^2 = x^3 + ax^2 + x. So the parameters are different. Further complicating things: every curve in Montgomery form has an isomorphic curve in Weierstrass form (but not vice-versa).
So if we reuse EllipticCurve (and related classes), we could map the parameters onto Montgomery curve coefficients. For example interpret "a" as the second-degree coefficient instead of the first-degree coefficient, and ignore "b". But we have the problem that the programmer may not know when the parameters will be interpreted as Weierstrass coefficients instead of Montgomery coefficients. I am particularly concerned about this because these parameters were always interpreted as Weierstrass coefficients in the past.
So we would want a way to tag the objects and check the tags to ensure that they are not misused. You suggested making new ECField subclasses for Montgomery/Edwards curves. The field used in RFC 7748/8032 is GF(p), which corresponds to the existing class ECFieldFp. So it seems strange and surprising to use this member to identify how coefficients should be interpreted, because this has nothing to do with the field. Though I can see why this approach is appealing, because the field is the only part of EllipticCurve that was designed to be extensible. If the coefficients (and their interpretation) were similarly extensible, then we wouldn't have these problems.
In short: I'm not sure that reusing the existing EC classes is a good idea, because they were intended for something else, they are not general enough, and the potential for misuse/confusion is high.
