ECC curve name from parameters

[Tomas Gustavsson-3]

Hi,

This is probably a stupid question...but is it possible to get the EC
curve name from an EC public key?

I can get the EC parameters etc and create ECParameterSpec from it. But
some generators (pkcs#11 providers) seems to require the curve name and
not support different parameters.


Regards,
Tomas

PS: It's quite tricky to convert between BC keyspecs and jdk keyspecs.

[Maarten Bodewes]

Hi colleague,

On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson <tomasg@...> wrote:

This is probably a stupid question...but is it possible to get the EC
curve name from an EC public key?

Not really. Converting a name to parameters is a one way function, as far as I know.
 

I can get the EC parameters etc and create ECParameterSpec from it. But
some generators (pkcs#11 providers) seems to require the curve name and
not support different parameters.

Yes, that's certainly true. I've asked one of the providers of these PKCS#11 libraries to support the parameters to be set directly exactly for this reason. I have no other method than aggregating all named curves + params and finding the exact values by matching parameters. Note that this sounds as a lot of work but in reality it's quite possible to do this.

Note that many providers don't know the BrainPool curves either - most have been designed with CertiCom & NIST curves in mind.
 

PS: It's quite tricky to convert between BC keyspecs and jdk keyspecs.

Yes, it is, isn't it. Normally I try and keep to the JDK keyspecs; BC is used mainly (by me) as a JCE provider; I do this mostly because I like the way the interface has been specified and to keep myself from tying the software to a specific provider.

Regards,
Maarten

PS it would have been easier if everybody just used the OID's in specifications, oh well

[Tomas Gustavsson-3]

Thanks for the answer, it is what I suspected.

The reason I get BC keyspecs, that I want to convert to JDK is that I
use the BC versions of certificates (BC provider as CertificateFactory),
and that returns a BC class as public key, wich in turn gives me the BC
key specs.

I also have found out about brainpool curves, which is unfortunate.

Btw, is there any advantage with brainpool curves compared to nist and
certicom?

Cheers,
Tomas


Maarten Bodewes wrote:

> Hi colleague,
>
> On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson <tomasg@...
> <mailto:tomasg@...>> wrote:
>
>     This is probably a stupid question...but is it possible to get the EC
>     curve name from an EC public key?
>
> Not really. Converting a name to parameters is a one way function, as
> far as I know.
>  
>
>     I can get the EC parameters etc and create ECParameterSpec from it. But
>     some generators (pkcs#11 providers) seems to require the curve name and
>     not support different parameters.
>
>
> Yes, that's certainly true. I've asked one of the providers of these
> PKCS#11 libraries to support the parameters to be set directly exactly
> for this reason. I have no other method than aggregating all named
> curves + params and finding the exact values by matching parameters.
> Note that this sounds as a lot of work but in reality it's quite
> possible to do this.
>
> Note that many providers don't know the BrainPool curves either - most
> have been designed with CertiCom & NIST curves in mind.
>  
>
>     PS: It's quite tricky to convert between BC keyspecs and jdk keyspecs.
>
> Yes, it is, isn't it. Normally I try and keep to the JDK keyspecs; BC is
> used mainly (by me) as a JCE provider; I do this mostly because I like
> the way the interface has been specified and to keep myself from tying
> the software to a specific provider.
>
> Regards,
> Maarten
>
> PS it would have been easier if everybody just used the OID's in
> specifications, oh well
>

[Tomas Gustavsson-3]

I'm actually looking at the source for the JDK6 pkcs#11 provider and it
looks like they are looping through the known curves and figuring out
the curve name by comparing all the parameters.

Regards,
Tomas


Tomas Gustavsson wrote:

> Thanks for the answer, it is what I suspected.
>
> The reason I get BC keyspecs, that I want to convert to JDK is that I
> use the BC versions of certificates (BC provider as CertificateFactory),
> and that returns a BC class as public key, wich in turn gives me the BC
> key specs.
>
> I also have found out about brainpool curves, which is unfortunate.
>
> Btw, is there any advantage with brainpool curves compared to nist and
> certicom?
>
> Cheers,
> Tomas
>
>
> Maarten Bodewes wrote:
>> Hi colleague,
>>
>> On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson <tomasg@...
>> <mailto:tomasg@...>> wrote:
>>
>>     This is probably a stupid question...but is it possible to get the EC
>>     curve name from an EC public key?
>>
>> Not really. Converting a name to parameters is a one way function, as
>> far as I know.
>>  
>>
>>     I can get the EC parameters etc and create ECParameterSpec from it. But
>>     some generators (pkcs#11 providers) seems to require the curve name and
>>     not support different parameters.
>>
>>
>> Yes, that's certainly true. I've asked one of the providers of these
>> PKCS#11 libraries to support the parameters to be set directly exactly
>> for this reason. I have no other method than aggregating all named
>> curves + params and finding the exact values by matching parameters.
>> Note that this sounds as a lot of work but in reality it's quite
>> possible to do this.
>>
>> Note that many providers don't know the BrainPool curves either - most
>> have been designed with CertiCom & NIST curves in mind.
>>  
>>
>>     PS: It's quite tricky to convert between BC keyspecs and jdk keyspecs.
>>
>> Yes, it is, isn't it. Normally I try and keep to the JDK keyspecs; BC is
>> used mainly (by me) as a JCE provider; I do this mostly because I like
>> the way the interface has been specified and to keep myself from tying
>> the software to a specific provider.
>>
>> Regards,
>> Maarten
>>
>> PS it would have been easier if everybody just used the OID's in
>> specifications, oh well
>>

[Maarten Bodewes]

Hi Tomas,

As I understood it they used a better verifiable method to create secure parameters and calculated the twisted curves. That's the main advantage. The other advantage is that they used 8 bit aligned values, which makes life just slightly easier for us developers (e.g. compare 168 bit BrainPool curve with 163 bit NIST curve over F(p) - look especially at the value of p).

Anyway, you should be able to retrieve the curve name from the X509 certificate (the OID should be in there somewhere) - or is it saved as direct values in there as well?

Regards,
Maarten

On Tue, Oct 6, 2009 at 9:51 AM, Tomas Gustavsson <tomasg@...> wrote:

Btw, is there any advantage with brainpool curves compared to nist and
certicom?

Cheers,
Tomas

Maarten Bodewes wrote:
> Hi colleague,
>
> On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson <tomasg@...

> <mailto:tomasg@...>> wrote:
>
>     This is probably a stupid question...but is it possible to get the EC
>     curve name from an EC public key?
>
> Not really. Converting a name to parameters is a one way function, as
> far as I know.
>
>
>     I can get the EC parameters etc and create ECParameterSpec from it. But
>     some generators (pkcs#11 providers) seems to require the curve name and
>     not support different parameters.
>
>
> Yes, that's certainly true. I've asked one of the providers of these
> PKCS#11 libraries to support the parameters to be set directly exactly
> for this reason. I have no other method than aggregating all named
> curves + params and finding the exact values by matching parameters.
> Note that this sounds as a lot of work but in reality it's quite
> possible to do this.
>
> Note that many providers don't know the BrainPool curves either - most
> have been designed with CertiCom & NIST curves in mind.
>
>
>     PS: It's quite tricky to convert between BC keyspecs and jdk keyspecs.
>
> Yes, it is, isn't it. Normally I try and keep to the JDK keyspecs; BC is
> used mainly (by me) as a JCE provider; I do this mostly because I like
> the way the interface has been specified and to keep myself from tying
> the software to a specific provider.
>
> Regards,
> Maarten
>
> PS it would have been easier if everybody just used the OID's in
> specifications, oh well
>

[Tomas Gustavsson-3]

You're right, there is the OID in the x.509 certificate. Openssl says
clearly OID: prime156v1 for example.

It doesn't help for CV certificates though, they don't have it...

Cheers,
Tomas


Maarten Bodewes wrote:

> Hi Tomas,
>
> As I understood it they used a better verifiable method to create secure
> parameters and calculated the twisted curves. That's the main advantage.
> The other advantage is that they used 8 bit aligned values, which makes
> life just slightly easier for us developers (e.g. compare 168 bit
> BrainPool curve with 163 bit NIST curve over F(p) - look especially at
> the value of p).
>
> Anyway, you should be able to retrieve the curve name from the X509
> certificate (the OID should be in there somewhere) - or is it saved as
> direct values in there as well?
>
> Regards,
> Maarten
>
> On Tue, Oct 6, 2009 at 9:51 AM, Tomas Gustavsson <tomasg@...
> <mailto:tomasg@...>> wrote:
>
>
>     Btw, is there any advantage with brainpool curves compared to nist and
>     certicom?
>
>     Cheers,
>     Tomas
>
>
>     Maarten Bodewes wrote:
>     > Hi colleague,
>     >
>     > On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson
>     <tomasg@... <mailto:tomasg@...>
>     > <mailto:tomasg@... <mailto:tomasg@...>>> wrote:
>     >
>     >     This is probably a stupid question...but is it possible to get
>     the EC
>     >     curve name from an EC public key?
>     >
>     > Not really. Converting a name to parameters is a one way function, as
>     > far as I know.
>     >
>     >
>     >     I can get the EC parameters etc and create ECParameterSpec
>     from it. But
>     >     some generators (pkcs#11 providers) seems to require the curve
>     name and
>     >     not support different parameters.
>     >
>     >
>     > Yes, that's certainly true. I've asked one of the providers of these
>     > PKCS#11 libraries to support the parameters to be set directly exactly
>     > for this reason. I have no other method than aggregating all named
>     > curves + params and finding the exact values by matching parameters.
>     > Note that this sounds as a lot of work but in reality it's quite
>     > possible to do this.
>     >
>     > Note that many providers don't know the BrainPool curves either - most
>     > have been designed with CertiCom & NIST curves in mind.
>     >
>     >
>     >     PS: It's quite tricky to convert between BC keyspecs and jdk
>     keyspecs.
>     >
>     > Yes, it is, isn't it. Normally I try and keep to the JDK keyspecs;
>     BC is
>     > used mainly (by me) as a JCE provider; I do this mostly because I like
>     > the way the interface has been specified and to keep myself from tying
>     > the software to a specific provider.
>     >
>     > Regards,
>     > Maarten
>     >
>     > PS it would have been easier if everybody just used the OID's in
>     > specifications, oh well
>     >
>
>

[David Hook-2]

The org.bouncycastle.jce.ECNamedCurveTable provides a look up for named
curves and a list of them. The only way to identify use of curves in
certificates that are actually the named curves is to iterate through
the table comparing the parameters (other than the seed).

ECNamedCurveTable.getNames() returns names for all the curves other than
the GOST ones.

Regards,

David

On Tue, 2009-10-06 at 15:19 +0200, Tomas Gustavsson wrote:

> You're right, there is the OID in the x.509 certificate. Openssl says
> clearly OID: prime156v1 for example.
>
> It doesn't help for CV certificates though, they don't have it...
>
> Cheers,
> Tomas
>
>
> Maarten Bodewes wrote:
> > Hi Tomas,
> >
> > As I understood it they used a better verifiable method to create secure
> > parameters and calculated the twisted curves. That's the main advantage.
> > The other advantage is that they used 8 bit aligned values, which makes
> > life just slightly easier for us developers (e.g. compare 168 bit
> > BrainPool curve with 163 bit NIST curve over F(p) - look especially at
> > the value of p).
> >
> > Anyway, you should be able to retrieve the curve name from the X509
> > certificate (the OID should be in there somewhere) - or is it saved as
> > direct values in there as well?
> >
> > Regards,
> > Maarten
> >
> > On Tue, Oct 6, 2009 at 9:51 AM, Tomas Gustavsson <tomasg@...
> > <mailto:tomasg@...>> wrote:
> >
> >
> >     Btw, is there any advantage with brainpool curves compared to nist and
> >     certicom?
> >
> >     Cheers,
> >     Tomas
> >
> >
> >     Maarten Bodewes wrote:
> >     > Hi colleague,
> >     >
> >     > On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson
> >     <tomasg@... <mailto:tomasg@...>
> >     > <mailto:tomasg@... <mailto:tomasg@...>>> wrote:
> >     >
> >     >     This is probably a stupid question...but is it possible to get
> >     the EC
> >     >     curve name from an EC public key?
> >     >
> >     > Not really. Converting a name to parameters is a one way function, as
> >     > far as I know.
> >     >
> >     >
> >     >     I can get the EC parameters etc and create ECParameterSpec
> >     from it. But
> >     >     some generators (pkcs#11 providers) seems to require the curve
> >     name and
> >     >     not support different parameters.
> >     >
> >     >
> >     > Yes, that's certainly true. I've asked one of the providers of these
> >     > PKCS#11 libraries to support the parameters to be set directly exactly
> >     > for this reason. I have no other method than aggregating all named
> >     > curves + params and finding the exact values by matching parameters.
> >     > Note that this sounds as a lot of work but in reality it's quite
> >     > possible to do this.
> >     >
> >     > Note that many providers don't know the BrainPool curves either - most
> >     > have been designed with CertiCom & NIST curves in mind.
> >     >
> >     >
> >     >     PS: It's quite tricky to convert between BC keyspecs and jdk
> >     keyspecs.
> >     >
> >     > Yes, it is, isn't it. Normally I try and keep to the JDK keyspecs;
> >     BC is
> >     > used mainly (by me) as a JCE provider; I do this mostly because I like
> >     > the way the interface has been specified and to keep myself from tying
> >     > the software to a specific provider.
> >     >
> >     > Regards,
> >     > Maarten
> >     >
> >     > PS it would have been easier if everybody just used the OID's in
> >     > specifications, oh well
> >     >
> >
> >
>