ECC curve name from parameters

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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.

Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

Maarten Bodewes
Hi colleague,

On Mon, Oct 5, 2009 at 4:24 PM, Tomas Gustavsson <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

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 <[hidden email]
> <mailto:[hidden email]>> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

Maarten Bodewes
In reply to this post by Tomas Gustavsson-3
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 <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

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 <[hidden email]
> > <mailto:[hidden email]>> 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
> >     <[hidden email] <mailto:[hidden email]>
> >     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
> >     >
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: ECC curve name from parameters

CaMiX
I recently found this old post in need of a solution. Below is what I came up
with based on a passed in java.security.spec.ECParameterSpec parameter. I
don't know if there's an easier way of doing this but I hope it helps any
others out there who may be needing this:



public static String getCurveName(ECParameterSpec spec)
            throws InvalidAlgorithmParameterException {
        String curveName = null;

       
        if (!(spec.getCurve().getField() instanceof ECFieldFp)) {
            throw new InvalidAlgorithmParameterException(
                    "Currently only ECFieldFp fields supported");
        }
       
        ECFieldFp field = (ECFieldFp) spec.getCurve().getField();
        Enumeration names = ECNamedCurveTable.getNames();
       
        while (names.hasMoreElements()) {
            ECNamedCurveParameterSpec nextSpec =
ECNamedCurveTable.getParameterSpec(names.nextElement().toString());

            if (nextSpec.getCurve().getFieldSize() == field.getFieldSize()
                    &&
nextSpec.getCurve().getField().getCharacteristic().equals(field.getP())
                    &&
nextSpec.getCurve().getA().toBigInteger().equals(spec.getCurve().getA())
                    &&
nextSpec.getCurve().getB().toBigInteger().equals(spec.getCurve().getB())
                    &&
nextSpec.getCurve().getOrder().equals(spec.getOrder())
                    &&
nextSpec.getG().getAffineXCoord().toBigInteger().equals(spec.getGenerator().getAffineX())
                    &&
nextSpec.getG().getAffineYCoord().toBigInteger().equals(spec.getGenerator().getAffineY())
                    &&
nextSpec.getCurve().getCofactor().equals(BigInteger.valueOf(spec.getCofactor())))
{
                curveName = nextSpec.getName();
                break;
            }

        }

        return curveName;
    }



--
Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html

All your base are belong to us.