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...

  • 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 4: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 1: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 6: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 2:09
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 
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.