At 01:38 PM 10/8/2013, Vincent Ryan wrote:
>On 8 Oct 2013, at 17:56, Michael StJohns wrote:
>
>> I use this construct a lot, but there are a number of cases (e.g. where I'm
>> trying to take an EC key and turn it into a structure to send to a smart
>> card) where what I really need is to be able to produce an EllipticCurve
>> (actually ECParamaterSpec) from a name.
>
>Are you seeking to extend the collection of supported named curve parameters?
>Because most of the well-known named curve parameters are already supported
>via the mechanism below.
>
>Adding more (to the SunEC and SunPKCS11 providers) is quite straight forward.
>Adding new classes to the JDK is more difficult and already too late for JDK 8.
Hi Vincent -
No - this is about doing something like:
int keyType;
ECParameterSpec p256spec = ....
ECParameterSpec p384spec = ...
if (eckey.getParams().equals(p256spec))
keyType = p256Key;
else if (eckey.getParams().equals(p384spec))
keyType = p384Key;
else
keyType = unknownKey;
When creating a key (public or private) on a smart card, I don't want to have
to pass over the whole curve data, just an indicator as to which curve to use
to set the card parameters.
The way I get around this now is to generate a key pair for each of those two
curves (using the ECGenParameters construct), and then extract the params from
one of the generated keys to set "p256spec" or "p384spec". This is a bit round
about, but it works.
The only other way to do this is to .encode() the original key and then parse
the ASN1 to find the OID that identifies the curve. Again, round about but it
works.
>>
>> I started looking at why ECGenParameterSpec isn't currently a subclass of
>> ECParameterSpec. I *think* this is because the curve table is currently
>> part of the individual EC providers rather than part of the JDK side
>> implementation.
>
>True. The database of curve parameters is part of the SunEC provider.
I'm not sure the curve database should or needs to be part of individual
providers. Given that there is one and only one curve definition for any given
OID, it might be useful to create a single common database of curves. It would
mean that providers wouldn't have to repeat the same curve data (and possibly
get it wrong).
E.g. maybe promote most of sun.security.ec.NamedCurve to
java.security.ECNamedCurve?
Mike
>>
>> I'm wondering if perhaps its time to change the above and move the curve
>> database over to the JDK side?
>>
>> Mike
>>
>>
>>
>>
>>
>> At 11:41 AM 10/8/2013, Vincent Ryan wrote:
>>> Currently, there is no public API for named curves.
>>>
>>> However you can generate named curves using the SunEC provider and the
>>> ECParameterSpec class.
>>> For example,
>>>
>>> AlgorithmParameters parameters =
>>> AlgorithmParameters.getInstance("EC", "SunEC");
>>> parameters.init(new ECGenParameterSpec("secp256r1"));
>>> ECParameterSpec ecParameters =
>>> parameters.getParameterSpec(ECParameterSpec.class);
>>>
>>> return KeyFactory.getInstance("EC", "SunEC").generatePublic(new
>>> ECPublicKeySpec(new ECPoint(x, y), ecParameters));
>>>
>>>
>>> It's not elegant but the list of supported named curves can be extracted
>>> from the AlgorithmParameters.EC SupportedCurves
>>> property. For example,
>>>
>>> String[] curves = Security.getProvider("SunEC")
>>> .getProperty("AlgorithmParameters.EC SupportedCurves")
>>> .split("\\|");
>>> for (String curve : curves) {
>>> System.out.println(curve.substring(1, curve.indexOf(",")));
>>> }
>>>
>>>
>>>
>>>
>>> On 8 Oct 2013, at 13:53, Anders Rundgren wrote:
>>>
>>>> If you have the X and Y points and the name of a public key you can create
>>>> a ECPublicKey using BouncyCastle.
>>>> I cannot find any counterpart in JDK 7. What am I missing?
>>>>
>>>> BC:
>>>>
>>>> return KeyFactory.getInstance ("EC").generatePublic (new ECPublicKeySpec
>>>> (new ECPoint (x, y), new ECNamedCurveSpec (name,...)));
>>>>
>>>> Cheers
>>>> Anders
>>
>>
