EC weirdness
Michael StJohns
mstjohns at comcast.net
Sat Jul 14 01:30:14 UTC 2018
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
More information about the security-dev
mailing list