<p>The code you are referring to in libsecp256k1 is not for ECDSA.</p>

<p>It implements the custom compact signatures that Bitcoin Core uses for message signing and verification.</p>

<p>The normal ECDSA code in libsecp256k1 should be identical in acceptance to the one in OpenSSL (apart from the fact that by default, it only accepts and produces low-s signatures, as a way to reduce malleability potential).</p>

CC BY-SA 3.0
2016-11-21T20:25:36.980Z
Where should I be looking? Is `secp256k1_schnorr.h` the header I actually need to use?
Cisplatin
CC BY-SA 3.0
2016-11-21T20:51:41.247Z
No, that's for Schnorr signatures (another experimental signature type). You need to use secp256k1_ecdsa_parse_der to load a signature, and secp256k1_ecdsa_verify to verify. The 'recoverable' things are for message signing.
Pieter Wuille
CC BY-SA 3.0
2016-11-22T14:58:45.273Z
Thanks for the help! One last question - why is it that the signatures coming out of secp256k1 are 64 bytes instead of 65? And how would I generate the 65th byte?
Cisplatin
CC BY-SA 3.0
2016-11-22T17:05:59.923Z
Read the documentation in the .h files.
Pieter Wuille
CC BY-SA 3.0
2016-11-22T17:25:19.403Z
I have checked and can't find anything except for a lower-S format (64 bytes) and a serialized format (70 bytes). There doesn't seem to be anything with 65 bytes.
Cisplatin
CC BY-SA 3.0
2016-11-22T17:31:26.643Z
Recoverable signature, as used by message signing, are 65 bytes. See secp256k1_ecdsa_recoverable_signature_serialize_compact to construct those. For Bitcoin's normal signatures, use secp256k1_ecdsa_signature_der.
Pieter Wuille
CC BY-SA 3.0
2016-11-21T17:31:10.410Z
2016-11-21T17:31:10.410Z
Pieter Wuille
<p>OpenSSL (from <code>ssl</code> in Mac OS X Version 10.11.6) and Secp256k1 (from the <a href="https://github.com/bitcoin-core/secp256k1" rel="nofollow noreferrer">bitcoin-core</a> repository) seem to differ in their implementations of ECDSA. I'm having issues with these differences and want to make sure they actually exist, and if they do, how to reconcile the differences.</p>

<p>For example, using OpenSSL, the recoverable signatures I get can end in any byte. However, from <a href="http://secp256k1_ecdsa_recoverable_signature_load" rel="nofollow noreferrer">this line</a> in Secp256k1, it seems that the <code>65</code>th byte (i.e. the last byte) is required to be between <code>0</code> and <code>4</code> inclusively.</p>

<p>If this is the case, then why does OpenSSL allow the last byte, which seems to be referred to as <code>rec_id</code>, to be of any value?</p>

<ecdsa><secp256k1><openssl>
OpenSSL and Secp256k1 differing in implementation of ECDSA signatures?
Cisplatin
# OpenSSL and Secp256k1 differing in implementation of ECDSA signatures?

(Asked by: username_0 on 2016-11-21)

OpenSSL (from `ssl` in Mac OS X Version 10.11.6) and Secp256k1 (from the [bitcoin-core](https://github.com/bitcoin-core/secp256k1) repository) seem to differ in their implementations of ECDSA. I'm having issues with these differences and want to make sure they actually exist, and if they do, how to reconcile the differences.

For example, using OpenSSL, the recoverable signatures I get can end in any byte. However, from [this line](http://secp256k1_ecdsa_recoverable_signature_load) in Secp256k1, it seems that the `65`th byte (i.e. the last byte) is required to be between `0` and `4` inclusively.

If this is the case, then why does OpenSSL allow the last byte, which seems to be referred to as `rec_id`, to be of any value?

**Tags:** ecdsa, secp256k1, openssl


---

## 1 answers

### Answer by username_1 on 2016-11-21. Score: 4 | Accepted answer

The code you are referring to in libsecp256k1 is not for ECDSA.

It implements the custom compact signatures that Bitcoin Core uses for message signing and verification.

The normal ECDSA code in libsecp256k1 should be identical in acceptance to the one in OpenSSL (apart from the fact that by default, it only accepts and produces low-s signatures, as a way to reduce malleability potential).

> **Comments:**
> **username_0**: Where should I be looking? Is `secp256k1_schnorr.h` the header I actually need to use?  
> **username_1**: No, that's for Schnorr signatures (another experimental signature type). You need to use secp256k1_ecdsa_parse_der to load a signature, and secp256k1_ecdsa_verify to verify. The 'recoverable' things are for message signing.  
> **username_0**: Thanks for the help! One last question - why is it that the signatures coming out of secp256k1 are 64 bytes instead of 65? And how would I generate the 65th byte?  
> **username_1**: Read the documentation in the .h files.  
> **username_0**: I have checked and can't find anything except for a lower-S format (64 bytes) and a serialized format (70 bytes). There doesn't seem to be anything with 65 bytes.  
> **username_1**: Recoverable signature, as used by message signing, are 65 bytes. See secp256k1_ecdsa_recoverable_signature_serialize_compact to construct those. For Bitcoin's normal signatures, use secp256k1_ecdsa_signature_der.  

---

