2

I wonder if there is a standard way of encoding the ECDSA-signature in the signature field of an X.509 certificate.

As far as I understand, the signature is a tuple of two integers r and s. If the signature uses the prime256v1 curve, each integer will be 32 bytes long. There seems to be a most common way of presenting these integers, which is as an ASN.1 DER encoded sequence.

0x30 0x44 0x02 0x20 [r-value] 0x02 0x20 [s-value]

Is there a standard saying how you may represent the ECDSA-signature in X.509? I have not found anything yet saying how they can or should be represented...

flipje
  • 23
  • 7
  • Remember for P256 each of R and S will about half the time need an extra octet thus changing L for that component to 0x21 and L for the SEQUENCE to 0x45 or 0x46. And similarly for most other standard Fp curves, whose sizes were chosen as multiples of 8. – dave_thompson_085 Apr 14 '17 at 04:59
  • Oh, I did not know that, thanks for pointing it out. Will R and S always have the same size, or can one have 33 bytes while the other have 32? – flipje Apr 14 '17 at 13:12
  • r and s for ECDSA are effectively independent random variables uniform over [1,n-1] where n is the group order; the standard Fp curves have cofactor 1 so the group order is very near p which is chosen to be near 2^bits. Thus for P256 **each of r and s, independently**, has nearly 0.5 chance of being in [2^255,n-1] and needing length 33. A similar effect occurs for integer-DSA except there the subgroup order q is usually itself random in [(2^N)/2,(2^N)-1] for N in 160,224,256 thus biasing the probability of r,s needing the extra octet. – dave_thompson_085 Apr 15 '17 at 01:16
  • 1
    Just because r or s is in [2^255,n-1] shouldn't mean they need 33 bytes, as n-1 should be 2^256-1 which is 32 bytes of ones. After reading a bit more, I understand that this is still somewhat true, but it is because the ASN.1 structure uses signed integers, while r and s are unsigned. So the most significant bit must be 0, which it is not if they are bigger than 2^255. Therefore an extra 0x00 byte is added if msb is 1. Is that correct? – flipje Apr 16 '17 at 06:41
  • n for P256 is NOT 2^256, and for cryptographic (DLP-hard) elliptic curves in general it is NOT 2^bits. As I said it is _near_ 2^bits; for the exact value see SECG 2, FIPS 186, or any handy implementation sourcecode. **Yes it's because ASN.1 integers are signed** values in [2^255,2^256-1], which includes [2^255,n-1] as a proper subset, need an extra octet of 0x00 to be represented correctly. – dave_thompson_085 Apr 17 '17 at 02:09

1 Answers1

3

The format you mentioned is the ASN.1 type ECDSA-Sig-Value as specified in RFC5480: Elliptic Curve Cryptography Subject Public Key Information:

ECDSA-Sig-Value ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER 
}
Community
  • 1
mat
  • 1,243
  • 7
  • 14