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.