Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

generate csr with secp384r1elliptic curve key and sha384 hash signature

Tags:

openssl

csr

I am using openssl commands to create a CSR with elliptic curve secp384r1 and hash signed with algorithm sha384:

openssl ecparam -out ec_client_key.pem -name secp384r1 -genkey

openssl req -new -key ec_client_key.pem -out ec_clientReq.pem

Then I display the CSR in readable format with this command:

openssl req -in ec_clientReq.pem -noout -text

In the signature part of the CSR I get this:

Signature Algorithm: ecdsa-with-SHA1
    30:64:02:30:06:a1:f2:5e:1b:34:18:b9:f3:7c:e9:52:c8:78:
    99:90:63:d2:1e:d2:f5:7a:25:f3:d6:4d:6d:90:d0:bf:25:45:
    15:ad:aa:17:34:ad:1a:b9:1e:67:2b:cf:d7:a6:9b:e5:02:30:
    31:fe:76:37:4b:11:3a:e7:2d:63:52:bb:18:2f:8e:43:a7:bb:
    65:74:38:a4:92:38:9d:eb:ec:22:8f:77:f3:e4:5f:47:2d:f8:
    2a:9b:e1:2c:ba:a7:b0:e6:c2:54:8d:0e

What should I do in order to get a signature algorithm "ecdsa-with-SHA384" instead of "ecdsa-with-SHA1"? Am I missing something in this process? I tried to use -sha384 in the second command

openssl req -new -key ec_client_key.pem -out ec_clientReq.pem -sha384

but I got the same result regarding the Signature Algorithm

Signature Algorithm: ecdsa-with-SHA1
    30:65:02:30:4e:b4:b6:5f:3a:fc:b7:28:e5:4b:f0:3d:9a:ea:
    4a:ba:ce:a4:f1:a6:e8:cd:15:19:23:a6:81:3f:24:01:d7:81:
    3c:9d:9a:4c:cd:4b:4a:12:6d:69:48:ec:7e:73:7d:73:02:31:
    00:d7:a5:63:9b:21:b2:95:ce:7f:13:3f:c5:1a:ac:99:01:ff:
    ba:9c:59:93:d5:ee:97:03:b5:9e:c1:7d:03:f8:72:90:65:b5:
    08:7c:79:ae:ea:4f:6e:b0:2b:55:1a:11:a5

Another question regards the format of the signature. In the examples above one is 102 bytes long and the second one is 103 bytes long. It seems that the first bytes are an header including type, length and may be some other stuff like padding. But I cannot find an exact definition. Can someboby put some light on this? Thanks

like image 484
Gaston Avatar asked May 29 '13 15:05

Gaston


2 Answers

I tried again with last openssl version 1.0.1e this time (instead of 0.9.8n).

openssl ecparam -out ec_client_key.pem -name secp384r1 -gen

openssl req -config openssl.cnf -new -key ec_client_key.pem -out ec_clientReq.pem -sha384

openssl req -in ec_clientReq.pem -noout -text

Now I get the expected result:

Signature Algorithm: ecdsa-with-SHA384

It looks that version 0.9.8n does not support sha384.

This extract from the CHANGES file seems to confirm this:

Changes between 1.0.0h and 1.0.1 [14 Mar 2012] : ... *) Add HMAC ECC ciphersuites from RFC5289. Include SHA384 PRF support. As required by RFC5289 these ciphersuites cannot be used if for versions of TLS earlier than 1.2. [Steve Henson]

Thanks gtrig for your help.

like image 98
Gaston Avatar answered Sep 28 '22 08:09

Gaston


When I use the same command you did with the -SHA384 option, I get this in the resulting CSR: "Signature Algorithm: ecdsa-with-SHA384".

Type this command to see the list of supported digests:

openssl list-message-digest-algorithms

Hopefully, you'll see SHA384 in that list.

About your 2nd question, the format is ASN.1. "30" indicates that a sequence follows (In this case, it's a sequence of 2 integers). "65" is the number of octets in the sequence. "02" represents an integer and 30 is the number of octets in that integer. If you skip ahead 0x30 (48 in decimal) octets, you'll come to the 2nd integer which is marked with "02" and "31". So the length of the first integer is 30 and the 2nd is 31. Add in the 2 octets for each integer and you get 65, which is the length of the sequence. This page can tell you more about ASN.1.

As far as this value being a sequence of 2 integers, that makes sense. The ECDSA signature is made up of 2 integers. See RFC6605 section 4 for more information. There is also the wiki page that explains how to calculate the 2 integers.

like image 43
gtrig Avatar answered Sep 28 '22 06:09

gtrig