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

René Heuven
  • 31
  • 2

1 Answers1

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).
Claris
  • 15,323
  • 2
  • 26
  • 43
  • 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 Feb 27 '19 at 23:21