I think the reason for the hard-coded curves is largely historical, and
I don't know of a security-related reason for it (other than the
prevention of insecure parameters). Though it has the additional benefit
that it simplifies the interface a lot, because the implementation for a
curve is not completely determined by the domain parameters. The
implementation may also need to know which optimized finite field
implementation, precomputed tables, etc to use. Looking up all of these
things at once can be a lot simpler than trying to specify them over an
interface.
I'm trying to figure out if your problem motivates support for arbitrary
base points, or if there is another way to get what you want. Is the
base point a secret in your scheme? Either way, can you implement your
scheme using KeyAgreement (e.g. using the "base point" as the public key
and a random integer as the private key)? What if ECDH KeyAgreement
supported three-party Diffie-Hellman, or you extract a point from
generateSecret()? Would that help?
On 7/13/2018 9:30 PM, Michael StJohns wrote:
Hi -
Every so often I run into some rather strange things in the way the
Sun EC classes were built. Most recently, I was trying to use the
SunEC provider to do a PACE like protocol. Basically, the idea was to
be able to generate public key points on the P-256 curve, but with a
different base point G (knowledge of G' or having a public key
generated from G' would allow you to do a valid ECDH operation, keys
with disjoint points would not).
I was able to generate a normal key pair using ECGenParameterSpec with
a name, so I grabbed the ECParameterSpec from the public key, made a
copy of most of the stuff (curve, cofactor), but substituted the
public point W from the key pair I'd just generated, and passed that
in as G to the new parameter spec. I tried to initialize the KPG with
my *almost* P-256 spec, and it failed with "unsupported curve".
Looking into the code and tracing through
sun.crypto.ec.ECKeyPairGenerator to the native code, I'm once again
surprised that all of the curves are hard coded into the C native
code, rather than being passed in as data from the Java code.
Is there a good security reason for hard coding the curves at the C
level that I'm missing?
This comes under the heading of unexpected behavior rather than a bug
per se I think. Although - I'd *really* like to be able to pass a
valid ECParameterSpec in to the generation process and get whatever
keys are appropriate for that curve and base point.
Later, Mike
