Hi all, if anybody is curious about how to fix the issue, here it is... :D
The problem is that functions like PEM_write_bio_PKCS8PrivateKey() or
PEM_write_bio_PrivateKey() do not encode the key correctly - therefore
there might be compatibility issues.
To solve the problem, you have to use the PEM_write_bio_ECPrivateKey()
function directly. For example:
switch( EVP_PKEY_type( x->type ))
{
case EVP_PKEY_DSA:
case EVP_PKEY_RSA:
ret = PEM_write_bio_PrivateKey( bp, x, enc, kstr, klen, cb, u);
break;
case EVP_PKEY_EC:
ret = PEM_write_bio_ECPrivateKey(bp, x->pkey.ec, enc, kstr, klen, cb,
u);
break;
default:
ret = 0;
};
...
This encodes the key correctly.
If there is a more elegant way to solve the issue.. let me know :D
Best,
Max
On 03/27/2011 06:03 PM, Massimiliano Pala wrote:
Hello, it seems that there are two different encoding versions when encoding EC keys. In particular, if using the EVP_PKEY_() the version is set to "0" - and that is incompatible with software other than OpenSSL. Here's an example: -----BEGIN PRIVATE KEY----- MGcCAQAwEwYHKoZIzj0CAQYIKoZIzj0DAQcETTBLAgEBBCDxE4JqRGtcOqVjy8wM gI/eDocdjKO4nVaSRRmeAiNeWaEkAyIAAua6xRQ8yyLt6j0+g8nS6P5LzsQqaPTN /HwjnCW/S0VN -----END PRIVATE KEY----- To reproduce, simply use the openssl pkey command: $ openssl pkey -in key.pem | openssl asn1parse The output is: 0:d=0 hl=2 l= 103 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 19 cons: SEQUENCE 7:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 16:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 26:d=1 hl=2 l= 77 prim: OCTET STRING ... On the other hand, if using the i2d_ECPrivateKey_bio() the version is automatically set to "1". To reproduce, just use the openssl ec command: $ openssl ec -in key.pem | openssl asn1parse The output is: 0:d=0 hl=2 l= 87 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:F113... 39:d=1 hl=2 l= 10 cons: cont [ 0 ] 41:d=2 hl=2 l= 8 prim: OBJECT :prime256v1 51:d=1 hl=2 l= 36 cons: cont [ 1 ] 53:d=2 hl=2 l= 34 prim: BIT STRING So.. is there a way to have the EVP_PKEY_* code path behave as the ECPrivateKey_bio() code path ? Is this a bug ? Any idea how to fast-fix it ? Cheers, Max
--
Best Regards,
Massimiliano Pala
--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] ope...@acm.org
project.mana...@openca.org
Dartmouth Computer Science Dept Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
-- Isaac Asimov
smime.p7s
Description: S/MIME Cryptographic Signature
