*sigh* I need to read emails a lot more closely.

Ignore this - for some reason I was reading this as the key pair generation 
stuff rather than the parameter generation stuff. 

I'm going to try out this construct on BouncyCastle and see if it works for 
their curve tables.

Mike




At 03:14 PM 10/8/2013, Michael StJohns wrote:
>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
>>> 
>>> 


Reply via email to