3
occasionally on Android we are generating an ECDSA signature. This turns out to have a "r" length of 31 bytes. Is that valid?
For reference here is a nice diagram outlining the ASN.1 structure of such a signature:
how do you figure out the r and s out of a signature using python
Best regards, Rene
4
This is valid, and there are even smaller types as well. Be aware that Bitcoin no longer really uses ASN.1 DER, but a even more restrictive subset of it. ASN.1 itself as it turns out is not deterministic or platform independent in many implementations, which is a source of consensus failure. For reference, here is how to encode signatures correctly in Bitcoin, from the text of the withdrawn BIP62.
0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash-type]
total-length: 1-byte length descriptor of everything that follows, excluding the sighash byte.
R-length: 1-byte length descriptor of the R value that follows.
R: arbitrary-length big-endian encoded R value. It cannot start with any 0x00 bytes, unless the first byte that follows is 0x80 or higher, in which case a single 0x00 is required.
S-length: 1-byte length descriptor of the S value that follows.
S: arbitrary-length big-endian encoded S value. The same rules apply as for R.
sighash-type: 1-byte hashtype flag (only 0x01, 0x02, 0x03, 0x81, 0x82 and 0x83 are allowed).
DER is a standard and is deterministic (and ASN.1 is always platform independent); it is some implementations that are or were inaccurately described as or claimed to be DER when they weren't. BIP62 or 146 would add the 'low s' restriction (s < n/2), which you don't mention, but there are other Qs on it. – dave_thompson_085 – 2019-02-27T23:21:00.840