Does OpenSSL apply ASN1 encoding to the hash before signing using ECDSA?

Question

I read on stack overflow that OpenSSL performs ASN1 encoding to the hash before signing it for, for ECDSA.

In other words, OpenSSL performs the following steps when for an Elliptic curve key -sign is called:

1. Calculate $H = Hash(M)$

2. Encode $H$ into ASN1 standard $H’$

3. Sign $H’$

If the above is true then in order to avoid applying step 1. it's necessary to first calculate the digest, and then sign the digest using raw signing -pkeyutl for elliptic curver keys.

However when I run BOTH -sign and -dgst + -pkeyutl I am able to verify the signature using -verify in both cases. This implies that ASN1 encoding is NOT being applied to the hash.

Can anyone throw some light on this topic? I was not able to find information in the OpenSSL documentation.

Answer 1

No, you do not add the ASN.1 encoding to the hash when generating an ECDSA signature.

There are two reasons for this:

• The first is that there is no room, if we select a curve and a hash with equal security. To be secure against attacks that take $O(2^N)$ time, a curve needs to have a prime that's at least $2N$ bits; to be secure against collision attacks that take $O(2^N)$ time, the hash needs an output that's at least $2N$ bits. That means that, if we don't add any encoding, the hash just fits into the curve. If we were to add an ASN.1 encoding to the hash, that's mean we'd need to make the curve larger than necessary for security purposes. Alternatively, we could modulo the result by the curve order to make it fit, however that is effectively the same as adding a constant (which depends on the curve and the hash function) to the hash, which appears a bit pointless.

• The second is that there is no reason. In RSA, the verifier recovers the padded hash value; he could then try to parse the ASN.1 encoding to determine the hash used (and then use that hash to hash the message being verified). For ECDSA, the verifier doesn't actually recover the padding hash value; instead, he needs to generate the hashed (and padded, if padding is being used) message before he learns anything from the signature. Hence, the potential gain we get from ASN.1 encoding the hash in RSA isn't there for ECDSA.

In addition, the original stack overflow question doesn't mention ECDSA at all; it strictly talks about RSA. In the the question you pointed to, it's the question that assumes that ECDSA uses padding; the answer doesn't address that.