RE: EVP and Elliptic curve
The patch works. I am using the openssl-fips-2.0.2 sources. Here is a Kolbitz-409 curve private key: -BEGIN PRIVATE KEY- MIIBiwIBADCB2QYHKoZIzj0CATCBzQIBATAdBgcqhkjOPQECMBICAgGZBgkqhkjO PQECAwICAVcwBgQBAAQBAQRpBABg8F9lj0nBrTqxiQ9xhCEO/QmH4wfITCesz7j5 9nzCxGAYnrWqqmLuIi6xs1VAz+kCN0YB42kFC3xOQqy6Hay/BCmcNGB4L5GOpCfm MlFl6eoQ49pfbELpxVIVqpyielhj7EjY4ChrAjN/ /l+DstTqIEAOxFV9XtPj58pbS1yDuOAeX88CAQQEgakwgaYCAQEEM11q kNyuCz8isUZ7C5zOWVrFAGNjErW9RKH3vluP5lP5YyP2Y+n7PRP/6xh1bn+/0zKv O6FsA2oABAEK21oLBen5xoJDZBZJtaSAyMBrLpBihUS3OHprmX9voA2bR8UUHjeZ 3B8KZNEjHHUrTqYBWgYRuoZta9TEINsEOaG7lt4We5/iRQcpuq8vXr8qOMssuWYa VYvegaty02SSXB2m1wM/ -END PRIVATE KEY- Thanks again Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: 22 March 2013 01:06 AM To: openssl-dev@openssl.org Subject: Re: EVP and Elliptic curve Hi Leon On 21 March 2013 17:27, Matt Caswell fr...@baggins.org wrote: On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. I have successfully managed to reproduce your problem. This is a BUG! Looks to me like binary curves are broken in FIPS mode - anything which attempts to encode a private key will fail, I think (and potentianly numerous other functions). I have attached a patch for openssl-1.0.1e. Please can you confirm that this resolves your problem? cd openssl-1.0.1e patch -p1 /path/to/patch I have submitted this to RT for one of the devs to pick up and commit (hopefully!) :-) Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
Matt, You are correct, using the standard installed libraries for Ubuntu 12.10 (OpenSSL 1.0.1 14 Mar 2012), my test app successfully creates EC keys and successfully sign and verify some data for all types of curves of all sizes. The private key however seems to be bigger (more chars in PEM format)? Here is the one created from the sect233r1 curve: -BEGIN PRIVATE KEY- MIIBOQIBADCBywYHKoZIzj0CATCBvwIBATAdBgcqhkjOPQECMBICAgDpBgkqhkjO PQECAwICAUowOQQBAQQdZmR+3mwzLH+MCSO7WCE7Mzsg6c5Cgf4RX32PkK0DFQB0 1Z/wf2tBPQ6hSzRLIKLbBJtQwwQ9BAD6yd/LrIMTuyE58bt1X+9lvDkfizb4+Otz cf1ViwEAagikGQM1BnjlhSi+v4oL7/hnp8o2cW9+AfgQUgIeAQAA E+l05y+KaSIDHSYDz+DXAgECBGYwZAIBAQQdkgFHGcub3q4KILP17VudtpDC 4KS7qMLPA/XpkHKhQAM+AAQAVdHQVSgvfEKnoAzxQu3++YjR60UjmimJUTzTB9QB zwNjc/gjDH6ex4ehhC9BsJ4L6nhphsegp57bIDM= -END PRIVATE KEY- NEW: I changed my compile to again use my FIPS compiled OpenSSL libraries and I got some new errors from the Binary and Kolbitz curves. Prime curves are still working just fine. First off the private key created with the sect233r1 curve are: -BEGIN PRIVATE KEY- MHYCAQAwCQYHKoZIzj0CAQRmMGQCAQEEHVnVyx1BHVTaKFSi758nc0v1SnWNQ1aR BYRjL4ZboUADPgAEAVZmnrloR8NnuKI7pzD8n8UYXHannulPUv2JVqeiAXI1bnBR K10brlEGKzKztusdvxC6UVz1Ew9eVvcL -END PRIVATE KEY- It does contain less information - I am not an expert but this seems wrong? Next, after creating these PEM formatted private and public keys I test them doing a sign and verify operation. I do this in a loop which excercises all the supported digests, but they all fail before the function get to do the actual sign/verify. The initial attempt to sign gives the following error when I try to read the PEM formatted private key using PEM_read_bio_PrivateKey(): (error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public key decode error) The loop then tries to verify the generated signature, which will fail since no signature was created, but again the code does not reach the verify function. I get the following error when I try to read the PEM formatted public key using PEM_read_bio_PUBKEY(): (error:100BF078:elliptic curve routines:i2d_ECPKParameters:group2pkparameters failure) The loop tries the next digest, which again reads the _same_ PEM formatted private key as using PEM_read_bio_PrivateKey() and I get a different error: (error:100C1042:elliptic curve routines:EC_GROUP_get_pentanomial_basis:called a function you should not call) For the verify I also get a different error when parsing the public key with PEM_read_bio_PUBKEY(): (error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC lib) The loop continues with the next digest, which again fails to read the same PEM formatted private key as using PEM_read_bio_PrivateKey(): (error:100D7010:elliptic curve routines:ECKEY_PUB_DECODE:EC lib) The last errors repeat for all the following attempt to parse the PEM formatted private and public keys in the digest loop. So, to conclude: It seems that this is a FIPS related problem. The keys simply seems incorrect and will therefore cause all the errors I now see. But, I do not get why a will get different errors when reading the exact same PEM formatted key. Or, why it all works for NIST prime curves? Any comment or help is appreciated Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: 20 March 2013 11:11 PM To: openssl-dev@openssl.org Subject: Re: EVP and Elliptic curve On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Regards, Leon Brits Well, I am unable to reproduce your problem, my code works fine under vanilla OpenSSL 1.0.1e. I don't have a fips build environment so it could be a fips issue. Are you able to test your code under normal non-fips openssl and see if you still get the same problem? Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 21 March 2013 09:06, Leon Brits le...@parsec.co.za wrote: First off the private key created with the sect233r1 curve are: -BEGIN PRIVATE KEY- MHYCAQAwCQYHKoZIzj0CAQRmMGQCAQEEHVnVyx1BHVTaKFSi758nc0v1SnWNQ1aR BYRjL4ZboUADPgAEAVZmnrloR8NnuKI7pzD8n8UYXHannulPUv2JVqeiAXI1bnBR K10brlEGKzKztusdvxC6UVz1Ew9eVvcL -END PRIVATE KEY- It does contain less information - I am not an expert but this seems wrong? Yes, they are corrupt. You can take a look at them with: openssl asn1parse -in in.pem -i Comparing them with a good key, you can see that they are missing a lot of information. So, to conclude: It seems that this is a FIPS related problem. The keys simply seems incorrect and will therefore cause all the errors I now see. But, I do not get why a will get different errors when reading the exact same PEM formatted key. Or, why it all works for NIST prime curves? I'm afraid I'll have to let others on this list assist with this. I am not familiar with the FIPS builds. :-( Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On Thu, Mar 21, 2013, Leon Brits wrote: Stephen, Just to clarify that a bit. EC keys are most comonly represented by named curves instead of explicit parameters. Unfortunately the default is to use explicit parameters and there's nothing (yet!) at an EVP_PKEY level to change that. They way you can change it is to either take the generated key or parameters and do something like this: EC_KEY *ec = EVP_PKEY_get1_EC(key); EC_KEY_set_asn1_flag(ec, OPENSSL_EC_NAMED_CURVE); EC_KEY_free(ec); At this stage the client only require support of the NIST curves, so I do not think I will have to use this. They did however inquire on using the Brainpool curves, so maybe in future in a follow up project I will. It's a good idea to *always* include that call if you generate keys with EVP as it uses a more common key format. It's easier with the unreleased OpenSSL 1.0.2: there's a ctrl now that handles this at the EVP level. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Just a thought on this: which version of the FIPS source did you use, i.e. openssl-fips-2.0.* or openssl-fips-ecp-2.0.*? The ecp version omits support for binary curves. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
Hi Leon On 21 March 2013 17:27, Matt Caswell fr...@baggins.org wrote: On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. I have successfully managed to reproduce your problem. This is a BUG! Looks to me like binary curves are broken in FIPS mode - anything which attempts to encode a private key will fail, I think (and potentianly numerous other functions). I have attached a patch for openssl-1.0.1e. Please can you confirm that this resolves your problem? cd openssl-1.0.1e patch -p1 /path/to/patch I have submitted this to RT for one of the devs to pick up and commit (hopefully!) :-) Matt ec2patch.patch Description: Binary data
RE: EVP and Elliptic curve
Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Regards, Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Matt Caswell Sent: 19 March 2013 11:48 PM To: openssl-dev@openssl.org Subject: Re: EVP and Elliptic curve On 19 March 2013 10:22, Leon Brits le...@parsec.co.za wrote: I've created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves (233-571 bit). I then convert the keys to PEM using the same method which I used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey() and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What is interesting now is that if I test the EC PEM files, using the openssl command line tool, all the keys generated for the NIST Prime curves is successfully parsed while the others fails with the following error: I have just tested this with no problems using NID_sect233k1. What version of openssl are you using? Please see attached PEM file. Are you able to read that with openssl ec? Please send me a sample PEM that you are having difficulty with and I will see if I can read it. Matt ec-b233.pem Description: ec-b233.pem ec-k233.pem Description: ec-k233.pem ec-p224.pem Description: ec-p224.pem
RE: EVP and Elliptic curve
Hi Matt, Can you send me an offending PEM file? I've replied with this information attached to your second message They are different formats. If it has BEGIN PRIVATE KEY it is in PKCS 8 format. See: https://www.openssl.org/docs/apps/pkcs8.html If it says BEGIN EC PRIVATE KEY then its as per RFC 5915 My requirement is too support PKCS8 for private keys, so I will do so for elliptic curve key pairs as well. The sec ones are named the same as per this document: http://www.secg.org/collateral/sec2_final.pdf The k indicates its a Kolbitz curve, whilst an r indicates that the parameters have been generated verifiably at random. The number is just to distinguish different curves with the similar characteristics e.g. sect193r1 and sect193r2. X9_62 refers to the ANSI standard X9.62 Thanks for that explanation - so, just to understand the history, why is there no secp256_r1 as well as the ANSI standard curve. In other words, why does the ANSI curve replace it instead of being an additional curve? Again my gratitude to the you and the list Leon Brits __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
List, I've continued so long to use the NIST prime curves to implement sign/verify using EVP. I am basically using the same code as for RSA and DSA. This mechanism is so transparent (nice!) that I just want to verify that it is using ECDSA at the backend? Do you have any reference to this fact, which I can add to my code for when the client audits the code? Regards, Leon Brits -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Leon Brits Sent: 20 March 2013 09:27 AM To: openssl-dev@openssl.org Subject: RE: EVP and Elliptic curve Hi Matt, Can you send me an offending PEM file? I've replied with this information attached to your second message They are different formats. If it has BEGIN PRIVATE KEY it is in PKCS 8 format. See: https://www.openssl.org/docs/apps/pkcs8.html If it says BEGIN EC PRIVATE KEY then its as per RFC 5915 My requirement is too support PKCS8 for private keys, so I will do so for elliptic curve key pairs as well. The sec ones are named the same as per this document: http://www.secg.org/collateral/sec2_final.pdf The k indicates its a Kolbitz curve, whilst an r indicates that the parameters have been generated verifiably at random. The number is just to distinguish different curves with the similar characteristics e.g. sect193r1 and sect193r2. X9_62 refers to the ANSI standard X9.62 Thanks for that explanation - so, just to understand the history, why is there no secp256_r1 as well as the ANSI standard curve. In other words, why does the ANSI curve replace it instead of being an additional curve? Again my gratitude to the you and the list Leon Brits __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 20 March 2013 10:36, Leon Brits le...@parsec.co.za wrote: List, I've continued so long to use the NIST prime curves to implement sign/verify using EVP. I am basically using the same code as for RSA and DSA. This mechanism is so transparent (nice!) that I just want to verify that it is using ECDSA at the backend? Do you have any reference to this fact, which I can add to my code for when the client audits the code? The EVP api will work out what kind of sign/verify operation to do based on the type of the key. If the EVP_PKEY type is EVP_PKEY_EC then it will use ECDSA, if its EVP_PKEY_RSA it will use RSA, it its EVP_PKEY_DSA it will use DSA. I've written some of this up on the new wiki: http://wiki.opensslfoundation.com/index.php/EVP#Working_with_EVP_PKEYs Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On Wed, Mar 20, 2013, Leon Brits wrote: List, I've continued so long to use the NIST prime curves to implement sign/verify using EVP. I am basically using the same code as for RSA and DSA. This mechanism is so transparent (nice!) that I just want to verify that it is using ECDSA at the backend? Do you have any reference to this fact, which I can add to my code for when the client audits the code? There are all sorts of ways to do this. One of which is to actually use the printing routines which produce human readable output of the key components. See EVP_PKEY_print_public et al manual pages. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On Fri, Mar 15, 2013, Dr. Stephen Henson wrote: The only real quirk is that when you generate a key the named curve ASN1 option isn't set by default for keys and can't be set by a ctrl. You can extract the key and set that manually though. Just to clarify that a bit. EC keys are most comonly represented by named curves instead of explicit parameters. Unfortunately the default is to use explicit parameters and there's nothing (yet!) at an EVP_PKEY level to change that. They way you can change it is to either take the generated key or parameters and do something like this: EC_KEY *ec = EVP_PKEY_get1_EC(key); EC_KEY_set_asn1_flag(ec, OPENSSL_EC_NAMED_CURVE); EC_KEY_free(ec); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Regards, Leon Brits Well, I am unable to reproduce your problem, my code works fine under vanilla OpenSSL 1.0.1e. I don't have a fips build environment so it could be a fips issue. Are you able to test your code under normal non-fips openssl and see if you still get the same problem? Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 20 March 2013 07:27, Leon Brits le...@parsec.co.za wrote: Thanks for that explanation - so, just to understand the history, why is there no secp256_r1 as well as the ANSI standard curve. In other words, why does the ANSI curve replace it instead of being an additional curve? I have no idea :-) It is one of lifes mysteries! Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 3/20/2013 4:24 PM, Matt Caswell wrote: On 20 March 2013 07:27, Leon Brits le...@parsec.co.za wrote: Thanks for that explanation - so, just to understand the history, why is there no secp256_r1 as well as the ANSI standard curve. In other words, why does the ANSI curve replace it instead of being an additional curve? http://tools.ietf.org/html/draft-ietf-pkix-ecc-nist-recommended-curves-00 defined the extra NIST recommended curves. The secp256_r1 (and secp192r1) were already defined in the ANSI X9.63, so the existing OIDs were used. I have no idea :-) It is one of lifes mysteries! Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Douglas E. Engert deeng...@anl.gov Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 20 March 2013 21:11, Matt Caswell fr...@baggins.org wrote: On 20 March 2013 07:14, Leon Brits le...@parsec.co.za wrote: Hi Matt, I use: $ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 I was able to successfully parse your attached private key. I've attached my smallest prime, binary and kolbitz curve key pairs. As I said the prime curve parses correct with the openssl command line tool but not the binary curve keys. Regards, Leon Brits Well, I am unable to reproduce your problem, my code works fine under vanilla OpenSSL 1.0.1e. I don't have a fips build environment so it could be a fips issue. Are you able to test your code under normal non-fips openssl and see if you still get the same problem? Matt Just to clarify that a bit - I meant I am unable to reproduce your problem when writing out private keys. Private keys I write out work fine. I have taken a look at the pem files you sent and I get the same error as you when trying to read them. So something about the way you are writing them out, or the version/build of openssl you are using is causing the issue. As I said if you can try on a non-fips build that would rule that out. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: EVP and Elliptic curve
Matt / List,
Thanks for the example. It sure helped a lot. But I am still stuck at the EC
key generation.
I've created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves
(233-571 bit). I then convert the keys to PEM using the same method which I
used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey()
and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What
is interesting now is that if I test the EC PEM files, using the openssl
command line tool, all the keys generated for the NIST Prime curves is
successfully parsed while the others fails with the following error:
$openssl ec -in ec-b233.pem -text -noout
read EC key
unable to load Key
139742524995232:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode
error:ec_ameth.c:178:
139742524995232:error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC
lib:ec_ameth.c:305:
139742524995232:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private
key decode error:evp_pkey.c:95:
139742524995232:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
lib:pem_pkey.c:132:
I've noticed that writing the PEM files using the above mentioned mechanism
does not add the letters EC to the PEM header and footer of the private key
(e.g. -BEGIN EC PRIVATE KEY-- misses the EC). The spec seems to say
it must have these two characters. If I add the EC manually, I get the
following parsing error:
$ openssl ec -in ec-b233.pem -text -noout
read EC key
unable to load Key
140357067445920:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
tag:tasn_dec.c:1319:
140357067445920:error:0D06C03A:asn1 encoding
routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:831:
140357067445920:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:751:Field=privateKey, Type=EC_PRIVATEKEY
140357067445920:error:10092010:elliptic curve routines:d2i_ECPrivateKey:EC
lib:ec_asn1.c:1130:
140357067445920:error:100DE08E:elliptic curve
routines:OLD_EC_PRIV_DECODE:decode error:ec_ameth.c:565:
140357067445920:error:100DC08E:elliptic curve routines:ECKEY_TYPE2PARAM:decode
error:ec_ameth.c:178:
140357067445920:error:100D5010:elliptic curve routines:ECKEY_PRIV_DECODE:EC
lib:ec_ameth.c:305:
140357067445920:error:0606F091:digital envelope routines:EVP_PKCS82PKEY:private
key decode error:evp_pkey.c:95:
140357067445920:error:0907B00D:PEM routines:PEM_READ_BIO_PRIVATEKEY:ASN1
lib:pem_pkey.c:132:
Any suggestions on why my binary curve keys are not validated?
Also can someone shed some light on the naming of the curves: Take for example
NID_secp224r1. From the bits I can see that it is a NIST prime curve which is
also indicated by the 'p' (right?), which then makes me wonder why all the
binary curves has a 't' (e.g. NID_sect233r1). Next, to distinguish between the
NIST binary curves and the Kolbitz curves the only indication is that the
Kolbitz curve names ends with a 'k1' - is this correct? And if so what is the
'r' for then in the NIST prime and NIST binary numbers? And finally, why is
there not a NID_sect256r1, but rather a NID_X9_62_prime256v1?
Thanks again for a great mailing list
Leon Brits
From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On
Behalf Of Matt Caswell
Sent: 15 March 2013 02:05 AM
To: openssl-dev@openssl.org
Subject: Re: EVP and Elliptic curve
On Thu, Mar 14, 2013, Leon Brits wrote:
Hi List,
I just want to verify: Elliptic curve functions are not encapsulated by the
EVP functions - correct? If so, what is the
EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used for? If NOT so,
then please help with an example since I could only find the normal
EC_{KEY,GROUP}* type of example code?
I am required to perform ECDSA and was hoping I could use EVP which is now
working for DSA and RSA (sans the padding problem).
As Steve has said, yes you can use ECDSA using EVP. The
EVP_PKEY_CTX_set_ec_paramgen_curve_nid is used during parameter generation.
Here is some sample code that uses it. Once you have an EVP_PKEY set up with a
type of EVP_PKEY_EC, then the code to do signatures should be pretty much
identical for DSA and ECDSA. This code generates a new key but you can equally
set it directly using EVP_PKEY_set1_EC_KEY. See the man page for further
details:
http://www.openssl.org/docs/crypto/EVP_PKEY_set1_RSA.html
EVP_PKEY *generate_key(int type)
{
EVP_PKEY_CTX *pctx = NULL, *kctx = NULL;
EVP_PKEY *params = NULL, *key = NULL;
/* Check whether we need to generate parameters first */
if(type == EVP_PKEY_EC || type == EVP_PKEY_DSA || type == EVP_PKEY_DH)
{
/* Create the context for generating the parameters */
if(!(pctx = EVP_PKEY_CTX_new_id(type, NULL))) goto err;
if(!EVP_PKEY_paramgen_init(pctx)) goto err;
/* Set the paramgen parameters according to the type */
switch(type)
{
case EVP_PKEY_EC
Re: EVP and Elliptic curve
On 19 March 2013 10:22, Leon Brits le...@parsec.co.za wrote: Matt / List, Thanks for the example. It sure helped a lot. But I am still stuck at the EC key generation. I’ve created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves (233-571 bit). I then convert the keys to PEM using the same method which I used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey() and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What is interesting now is that if I test the EC PEM files, using the openssl command line tool, all the keys generated for the NIST Prime curves is successfully parsed while the others fails with the following error: Can you send me an offending PEM file? I’ve noticed that writing the PEM files using the above mentioned mechanism does not add the letters “EC” to the PEM header and footer of the private key (e.g. -BEGIN EC PRIVATE KEY-- misses the “EC”). The spec seems to say it must have these two characters. If I add the “EC” manually, I get the following parsing error: They are different formats. If it has BEGIN PRIVATE KEY it is in PKCS 8 format. See: https://www.openssl.org/docs/apps/pkcs8.html If it says BEGIN EC PRIVATE KEY then its as per RFC 5915 Also can someone shed some light on the naming of the curves: Take for example “NID_secp224r1”. From the bits I can see that it is a NIST prime curve which is also indicated by the ‘p’ (right?), which then makes me wonder why all the binary curves has a ‘t’ (e.g. NID_sect233r1). Next, to distinguish between the NIST binary curves and the Kolbitz curves the only indication is that the Kolbitz curve names ends with a ‘k1’ - is this correct? And if so what is the ‘r’ for then in the NIST prime and NIST binary numbers? And finally, why is there not a NID_sect256r1, but rather a NID_X9_62_prime256v1? The sec ones are named the same as per this document: http://www.secg.org/collateral/sec2_final.pdf The k indicates its a Kolbitz curve, whilst an r indicates that the parameters have been generated verifiably at random. The number is just to distinguish different curves with the similar characteristics e.g. sect193r1 and sect193r2. X9_62 refers to the ANSI standard X9.62 Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On 19 March 2013 10:22, Leon Brits le...@parsec.co.za wrote: I’ve created keys for NIST Prime curves (224-571bit), Binary and Kolbits curves (233-571 bit). I then convert the keys to PEM using the same method which I used successfully for RSA and DSA which only calls PEM_write_bio_PrivateKey() and PEM_write_bio_PUBKEY(). The type is never specified in my functions. What is interesting now is that if I test the EC PEM files, using the openssl command line tool, all the keys generated for the NIST Prime curves is successfully parsed while the others fails with the following error: I have just tested this with no problems using NID_sect233k1. What version of openssl are you using? Please see attached PEM file. Are you able to read that with openssl ec? Please send me a sample PEM that you are having difficulty with and I will see if I can read it. Matt out.pem Description: Binary data
Re: EVP and Elliptic curve
On Thu, Mar 14, 2013, Leon Brits wrote:
Hi List,
I just want to verify: Elliptic curve functions are not encapsulated by the
EVP functions - correct? If so, what is the
EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used for? If NOT so,
then please help with an example since I could only find the normal
EC_{KEY,GROUP}* type of example code?
I am required to perform ECDSA and was hoping I could use EVP which is now
working for DSA and RSA (sans the padding problem).
Yes you can use EVP for EC though not all the functionality is available from
the EVP interface at present.
The only real quirk is that when you generate a key the named curve ASN1
option isn't set by default for keys and can't be set by a ctrl. You can
extract the key and set that manually though.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: EVP and Elliptic curve
On Thu, Mar 14, 2013, Leon Brits wrote:
Hi List,
I just want to verify: Elliptic curve functions are not encapsulated by
the
EVP functions - correct? If so, what is the
EVP_PKEY_CTX_set_ec_paramgen_curve_nid function then used for? If NOT
so,
then please help with an example since I could only find the normal
EC_{KEY,GROUP}* type of example code?
I am required to perform ECDSA and was hoping I could use EVP which is
now
working for DSA and RSA (sans the padding problem).
As Steve has said, yes you can use ECDSA using EVP. The
EVP_PKEY_CTX_set_ec_paramgen_curve_nid is used during parameter generation.
Here is some sample code that uses it. Once you have an EVP_PKEY set up
with a type of EVP_PKEY_EC, then the code to do signatures should be pretty
much identical for DSA and ECDSA. This code generates a new key but you can
equally set it directly using EVP_PKEY_set1_EC_KEY. See the man page for
further details:
http://www.openssl.org/docs/crypto/EVP_PKEY_set1_RSA.html
EVP_PKEY *generate_key(int type)
{
EVP_PKEY_CTX *pctx = NULL, *kctx = NULL;
EVP_PKEY *params = NULL, *key = NULL;
/* Check whether we need to generate parameters first */
if(type == EVP_PKEY_EC || type == EVP_PKEY_DSA || type == EVP_PKEY_DH)
{
/* Create the context for generating the parameters */
if(!(pctx = EVP_PKEY_CTX_new_id(type, NULL))) goto err;
if(!EVP_PKEY_paramgen_init(pctx)) goto err;
/* Set the paramgen parameters according to the type */
switch(type)
{
case EVP_PKEY_EC:
if(!EVP_PKEY_CTX_set_ec_paramgen_curve_nid(pctx,
NID_X9_62_prime256v1)) goto err;
break;
case EVP_PKEY_DSA:
if(!EVP_PKEY_CTX_set_dsa_paramgen_bits(pctx, 2048)) goto
err;
break;
case EVP_PKEY_DH:
if(!EVP_PKEY_CTX_set_dh_paramgen_prime_len(pctx, 2048)) goto
err;
}
/* Generate parameters */
if (!EVP_PKEY_paramgen(pctx, params)) goto err;
/* Create context for the key generation */
if(!(kctx = EVP_PKEY_CTX_new(params, NULL))) goto err;
}
else
{
/* Create context for the key generation */
if(!(kctx = EVP_PKEY_CTX_new_id(type, NULL))) goto err;
}
/* Set the keygen parameters according to the type */
if(type == EVP_PKEY_RSA)
{
if(!EVP_PKEY_CTX_set_rsa_keygen_bits(kctx, 2048)) goto err;
}
/* Generate the key */
if(!EVP_PKEY_keygen_init(kctx)) goto err;
if(type == EVP_PKEY_CMAC)
{
if (EVP_PKEY_CTX_ctrl(kctx, -1, EVP_PKEY_OP_KEYGEN,
EVP_PKEY_CTRL_CIPHER,
0, (void *)EVP_aes_256_ecb()) = 0)
goto err;
if (EVP_PKEY_CTX_ctrl(kctx, -1, EVP_PKEY_OP_KEYGEN,
EVP_PKEY_CTRL_SET_MAC_KEY,
/*key length*/32, 01234567890123456789012345678901) = 0)
goto err;
}
if (!EVP_PKEY_keygen(kctx, key)) goto err;
goto end;
err:
ERR_print_errors_fp(stderr);
end:
if(pctx) EVP_PKEY_CTX_free(pctx);
if(params) EVP_PKEY_free(params);
if(kctx) EVP_PKEY_CTX_free(kctx);
return key;
}
Regards
Matt
