W3C home > Mailing lists > Public > public-xmlsec@w3.org > June 2009

RE: Size of r and s in ECDSA

From: Kelvin Yiu <kelviny@exchange.microsoft.com>
Date: Mon, 1 Jun 2009 15:38:34 -0700
To: Pratik Datta <pratik.datta@oracle.com>, XMLSec WG Public List <public-xmlsec@w3.org>
Message-ID: <EF8BB8116404AE42A67EF8BECBC144879E9BA245@DF-POINTER-MSG.exchange.corp.microsoft.com>
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.


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)
Received on Monday, 1 June 2009 22:39:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:11 UTC