1

In experimenting with openssl on the Linux command line with elliptic curve secp256k1 I encountered a strange situation where on converting a DER private key file to PEM format using openssl pkey the Base64 in the PEM file does not match the original DER file.

The DER private key file priv.der is generated with :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl ecparam -name secp256k1 -genkey -noout -outform DER -out priv.der (recreate present example with : ubuntu3@ubuntu3:~/OpenSSL Test$ echo "3074020101042090f4a50b8dd639597c01b56bb97eb0a5063ec56326da72c7acbd303354df393ba00706052b8104000aa14403420004cb452cb3662eb70920eb8532040f807853928a5d13c4331e822334a60aa04ea115e7ce0c8648416e6bc22ef33f55d75057442b2a66c5c95ef652df9e6a306c57" | xxd -r -ps > priv.der )

which looks like the following under asn1parse :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl asn1parse -inform DER -in priv.der 0:d=0 hl=2 l= 116 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:90F4A50B8DD639597C01B56BB97EB0A5063EC56326DA72C7ACBD303354DF393B 39:d=1 hl=2 l= 7 cons: cont [ 0 ] 41:d=2 hl=2 l= 5 prim: OBJECT :secp256k1 48:d=1 hl=2 l= 68 cons: cont [ 1 ] 50:d=2 hl=2 l= 66 prim: BIT STRING

The conversion of the DER file to a PEM file using openssl pkey :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl pkey -inform DER -in priv.der > priv.pem ubuntu3@ubuntu3:~/OpenSSL Test$ cat priv.pem -----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgkPSlC43WOVl8AbVruX6w pQY+xWMm2nLHrL0wM1TfOTuhRANCAATLRSyzZi63CSDrhTIED4B4U5KKXRPEMx6C IzSmCqBOoRXnzgyGSEFua8Iu8z9V11BXRCsqZsXJXvZS355qMGxX -----END PRIVATE KEY-----

Decoding the Base64 text in the PEM file :

ubuntu3@ubuntu3:~/OpenSSL Test$ echo "MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgkPSlC43WOVl8AbVruX6wpQY+xWMm2nLHrL0wM1TfOTuhRANCAATLRSyzZi63CSDrhTIED4B4U5KKXRPEMx6CIzSmCqBOoRXnzgyGSEFua8Iu8z9V11BXRCsqZsXJXvZS355qMGxX" | base64 --decode > priv2.der Comparing priv2.der with priv.der : ubuntu3@ubuntu3:~/OpenSSL Test$ ll priv.der priv2.der -rw-r--r-- 1 ubuntu3 ubuntu3 135 Jan 29 17:00 priv2.der -rw-r--r-- 1 ubuntu3 ubuntu3 118 Jan 29 16:42 priv.der

=> file sizes are different and ASN.1 structure is different :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl asn1parse -inform DER -in priv2.der 0:d=0 hl=3 l= 132 cons: SEQUENCE 3:d=1 hl=2 l= 1 prim: INTEGER :00 6:d=1 hl=2 l= 16 cons: SEQUENCE 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 17:d=2 hl=2 l= 5 prim: OBJECT :secp256k1 24:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B020101042090F4A50B8DD639597C01B56BB97EB0A5063EC56326DA72C7ACBD303354DF393BA14403420004CB452CB3662EB70920EB8532040F807853928A5D13C4331E822334A60AA04EA115E7CE0C8648416E6BC22EF33F55D75057442B2A66C5C95EF652DF9E6A306C57

The ASN.1 data for priv2.der contains 2 OID's, whereas the original priv.der only contains only 1 OID.

So why did the openssl pkey command not just Base64 encode the priv.der file passed in and place that between the

-----BEGIN PRIVATE KEY----- -----END PRIVATE KEY-----

lines in the priv.pem file ?

Why did it encode to Base64 a different DER structure than priv.der?

The byte by byte breakdowns of priv.der and priv2.der are shown below :

Breakdown of bytes of DER file priv.der --------------------------------------- 30 sequence type 74 length = 116 bytes 02 integer type 01 01 04 octet string type 20 length = 32 bytes 90f4a50b8dd639597c01b56bb97eb0a5063ec56326da72c7acbd303354df393b private key a0 07 length = 7 bytes 06 OID type 05 length = 5 bytes 2b8104000a OID for secp256k1 = 1.3.132.0.10 a1 44 length = 68 bytes 03 bit string type 42 length = 66 bytes 00 no of unused bits added to right (to make a multiple of 8 bits) 04 pubkey prefix cb452cb3662eb70920eb8532040f807853928a5d13c4331e822334a60aa04ea1 pubkey x 15e7ce0c8648416e6bc22ef33f55d75057442b2a66c5c95ef652df9e6a306c57 pubkey y Breakdown of bytes of DER file priv2.der ---------------------------------------- 30 sequence type 81 84 length = 132 bytes 02 integer type 01 00 30 sequence type 10 length = 16 bytes (sum of 2 OID lengths below) 06 OID type 07 length = 7 bytes 2a8648ce3d0201 object identifier = 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type) 06 OID type 05 length = 5 bytes 2b8104000a object identifier = 1.3.132.0.10 secp256k1 (SECG (Certicom) named elliptic curve) 04 octet string type 6d length = 109 bytes 30 sequence type 6b length = 107 bytes 02 integer type 01 01 04 octet string type 20 length = 32 bytes 90f4a50b8dd639597c01b56bb97eb0a5063ec56326da72c7acbd303354df393b private key a1 44 length = 68 bytes 03 bit string type 42 length = 66 bytes 00 no of unused bits added to right (to make a multiple of 8 bits) 04 pubkey_prefix cb452cb3662eb70920eb8532040f807853928a5d13c4331e822334a60aa04ea1 pubkey_x 15e7ce0c8648416e6bc22ef33f55d75057442b2a66c5c95ef652df9e6a306c57 pubkey_y
Improve this question

3 Answers 3

Reset to default
4

The openssl pkey command doesn't just convert from DER to PEM format. It wraps the private key in a PKCS#8 structure.

So you're dealing with two completely different data structures:

When you use openssl ecparam, you get a raw private key in the ECPrivateKey format described in section 3 of RFC 5915:

ECPrivateKey ::= SEQUENCE { version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), privateKey OCTET STRING, parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, publicKey [1] BIT STRING OPTIONAL }

This is what you're seeing when you directly parse the output of openssl ecparam.

In contrast, openssl pkey produces a PKCS#8 PrivateKeyInfo structure described in section 5 of RFC 5208:

PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL }

This is what you're seeing when you parse the base64-decoded output of openssl pkey. The privateKeyAlgorithm in your case is id-ecPublicKey, and privateKey is the private ECC key.

Improve this answer
2
  • Thank you. In the two instances of openssl genpkey mentioned in your answer should these read openssl pkey ? I only mentioned the latter command in my question but not the former. Commented Jan 29 at 21:22
  • 2
    @CryptoLPlate: Yes, I mean't pkey, not genpkey. Commented Jan 29 at 22:36
2

Two different modules, two different implementations. They could have been originally built to different standards for different reasons, and since they're now in two different code bases they have evolved along separate lines.

Improve this answer
2
  • 3279 (and more recently 5480) is a generic PUBLIC key format and completely irrelevant here; as Ja correctly says, ecparam (or pkey with -traditional and not -pubout) uses the EC-specific private key format from 5915 and before that SEC1. And strictly speaking 5958 is no longer PKCS8 but an intended successor, and more to the point is not what OpenSSL uses -- not even for the Bernstein curves where the new [1]publicKey field would be useful. Commented Jan 30 at 1:04
  • My primary observation was that "Two different modules, two different implementations." They could have been originally built to different standards for different reasons, and since they're now in two different code bases they have evolved along separate lines. I'll rework the answer. Commented Jan 31 at 16:15
2

Just to developer further on Ja1024's answer, if in the example in the question we use the ec command instead of the pkey command to convert the DER to PEM, then the Base64 does match up with the original DER :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl ec -inform DER -in priv.der > priv.pem read EC key writing EC key ubuntu3@ubuntu3:~/OpenSSL Test$ cat priv.pem -----BEGIN EC PRIVATE KEY----- MHQCAQEEIJD0pQuN1jlZfAG1a7l+sKUGPsVjJtpyx6y9MDNU3zk7oAcGBSuBBAAK oUQDQgAEy0Uss2Yutwkg64UyBA+AeFOSil0TxDMegiM0pgqgTqEV584MhkhBbmvC LvM/VddQV0QrKmbFyV72Ut+eajBsVw== -----END EC PRIVATE KEY----- PEM Base64 decode : echo "MHQCAQEEIJD0pQuN1jlZfAG1a7l+sKUGPsVjJtpyx6y9MDNU3zk7oAcGBSuBBAAKoUQDQgAEy0Uss2Yutwkg64UyBA+AeFOSil0TxDMegiM0pgqgTqEV584MhkhBbmvCLvM/VddQV0QrKmbFyV72Ut+eajBsVw==" | base64 --decode > priv3.der ubuntu3@ubuntu3:~/OpenSSL Test$ cmp -l priv3.der priv.der; echo $? ubuntu3@ubuntu3:~/OpenSSL Test$ 0

So it looks like the following pkey command :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl pkey -inform DER -in priv.der > priv.pem ubuntu3@ubuntu3:~/OpenSSL Test$ cat priv.pem -----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgkPSlC43WOVl8AbVruX6w pQY+xWMm2nLHrL0wM1TfOTuhRANCAATLRSyzZi63CSDrhTIED4B4U5KKXRPEMx6C IzSmCqBOoRXnzgyGSEFua8Iu8z9V11BXRCsqZsXJXvZS355qMGxX -----END PRIVATE KEY-----

is equivalent to :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl ec -inform DER -in priv.der > priv_raw.pem read EC key writing EC key ubuntu3@ubuntu3:~/OpenSSL Test$ openssl pkcs8 -nocrypt -topk8 -inform PEM -in priv_raw.pem -outform PEM -out priv.pem ubuntu3@ubuntu3:~/OpenSSL Test$ cat priv.pem -----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgkPSlC43WOVl8AbVruX6w pQY+xWMm2nLHrL0wM1TfOTuhRANCAATLRSyzZi63CSDrhTIED4B4U5KKXRPEMx6C IzSmCqBOoRXnzgyGSEFua8Iu8z9V11BXRCsqZsXJXvZS355qMGxX -----END PRIVATE KEY-----

where the pkcs8 command with -topk8 option converts the raw ECPrivateKey format to PKCS#8 format.

Without the -topk8 option the pkcs8 command converts in the other direction, from PKCS#8 format to raw ECPrivateKey format :

(continuing the latter example)

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl pkcs8 -nocrypt -traditional -inform PEM -in priv.pem -outform PEM -out priv_raw.pem ubuntu3@ubuntu3:~/OpenSSL Test$ cat priv_raw.pem -----BEGIN EC PRIVATE KEY----- MHQCAQEEIJD0pQuN1jlZfAG1a7l+sKUGPsVjJtpyx6y9MDNU3zk7oAcGBSuBBAAK oUQDQgAEy0Uss2Yutwkg64UyBA+AeFOSil0TxDMegiM0pgqgTqEV584MhkhBbmvC LvM/VddQV0QrKmbFyV72Ut+eajBsVw== -----END EC PRIVATE KEY-----

ie. as produced by openssl ec -inform DER -in priv.der > priv_raw.pem.

Note the -traditional switch must be used here, as documented in man openssl pkcs8.

The latter pkcs8 command has a counterpart for DER files :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl pkcs8 -nocrypt -inform DER -in priv_pkcs8.der -outform DER -out priv_raw.der ubuntu3@ubuntu3:~/OpenSSL Test$ openssl asn1parse -inform DER -in priv_raw.der 0:d=0 hl=2 l= 116 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :01 5:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:90F4A50B8DD639597C01B56BB97EB0A5063EC56326DA72C7ACBD303354DF393B 39:d=1 hl=2 l= 7 cons: cont [ 0 ] 41:d=2 hl=2 l= 5 prim: OBJECT :secp256k1 48:d=1 hl=2 l= 68 cons: cont [ 1 ] 50:d=2 hl=2 l= 66 prim: BIT STRING

where priv_raw.der is the raw ECPrivateKey format DER (priv.der in the original example), and priv_pkcs8.der is the PKCS#8 format of the DER (priv2.der in the original example).

Note the -traditional switch is NOT needed in this conversion.

And there is a DER counterpart with the -topk8 option option, converting in the opposite direction :

ubuntu3@ubuntu3:~/OpenSSL Test$ openssl pkcs8 -nocrypt -topk8 -inform DER -in priv_raw.der -outform DER -out priv_pkcs8.der ubuntu3@ubuntu3:~/OpenSSL Test$ openssl asn1parse -inform DER -in priv_pkcs8.der 0:d=0 hl=3 l= 132 cons: SEQUENCE 3:d=1 hl=2 l= 1 prim: INTEGER :00 6:d=1 hl=2 l= 16 cons: SEQUENCE 8:d=2 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 17:d=2 hl=2 l= 5 prim: OBJECT :secp256k1 24:d=1 hl=2 l= 109 prim: OCTET STRING [HEX DUMP]:306B020101042090F4A50B8DD639597C01B56BB97EB0A5063EC56326DA72C7ACBD303354DF393BA14403420004CB452CB3662EB70920EB8532040F807853928A5D13C4331E822334A60AA04EA115E7CE0C8648416E6BC22EF33F55D75057442B2A66C5C95EF652DF9E6A306C57
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.