27602 2014-12-13 02:12:07 +0000 ECDSA's Sign operation is not explicit about how r and s are concatenated (padding) 2016-05-24 00:07:59 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC Linux RESOLVED MOVED P2 normal --- 1 ericroman sleevi public-webcrypto watsonm oldest_to_newest 116249 0 ericroman 2014-12-13 02:12:07 +0000 The spec says the following: --------------------- 2. Let r and s be the pair of integers resulting from performing the ECDSA signing process. 3. Let result be a new ArrayBuffer. 4. Convert r to a bitstring and append the sequence of bytes to result. 5. Convert s to a bitstring and append the sequence of bytes to result. --------------------- As I understand "r" and "s" are big integers in big-endian order. Prior to concatenation r and s must be padded to a fixed length, otherwise when reversing the process during verify() it is unclear unclear how to extract r and s. I believe they should be zero-padded to the group order size in bytes. 116797 1 watsonm 2015-01-05 18:03:56 +0000 r and s are just integers in the interval [ 1, n-1 ] where n is the order of the base point G of the elliptic curve. The ambiguity is in "Convert r/s to a bitstring" since it is not specified what the output bitstring length should be. I assume it should be the smallest multiple of 8 bits which can represent the value n-1 (I expect this is also what Eric meant in comment #0). 116867 2 ericroman 2015-01-07 02:18:27 +0000 Yes, that is along the lines of what I was thinking. To copy some language from the JWA spec [1] as an example, it says this about ECDSA (P-256): " 2. Turn R and S into octet sequences in big endian order, with each array being be 32 octets long. The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values. 3. Concatenate the two octet sequences in the order R and then S. " Except instead of "32 octets" we would say something more general like (also from JWA): "ceiling(log-base-2(n)/8) octets (where n is the order of the curve)" My primary concern for compatibility is being explicit that the leading zeros are mandatory. Otherwise we could have implementations for which it is sufficient that len(r) == len(s), and not the stronger requirement that len(r) == len(s) == ceiling(log-base-2(n)/8). Cheers. [1] https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-39#section-6.2.1 126525 3 watsonm 2016-05-24 00:07:59 +0000 Moved to https://github.com/w3c/webcrypto/issues/65