RE: Size of r and s in ECDSA

Good catch. The length of r and s should be the length of the order of the base point in bytes, not the length of the digest function. For example, l is 32 for the P256 curve and 48 for the P384 curve.

Kelvin

From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org] On Behalf Of Pratik Datta
Sent: Friday, May 22, 2009 3:16 PM
To: XMLSec WG Public List
Subject: Size of r and s in ECDSA

Currently the XML Signature 1.1 spec says:

The output of the ECDSA algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value consists of the base64 encoding of the concatenation of two octet-streams that respectively result from the octet-encoding of the values r and s in that order. Integer to octet-stream conversion must be done according to the I2OSP operation defined in the RFC 2437<http://www.ietf.org/rfc/rfc2437.txt> [ PKCS1 ] specification with the l parameter equal to the size of the output of the digest function in bytes (e.g. 32 for SHA-256).

But shouldn't the length of r and s be dependent on the length of the key, not the length of digest function?

E.g. if you are using "ecdsa-sha256",  with P521 curve, then the length of r and s should not be 32, but should be 66
(521 ; round up to multiple of 8 and get 528 bits = 66 bytes)
Pratik