tip: 120
title: ECDSA Signature Encoding Specification
author: federico<[email protected]>
discussions-to: https://github.com/tronprotocol/tips/issues/120
status: Final
type: Standards Track
category: TRC
created: 2020-01-07
This TIP aims to present clear signature encoding specification to avoid ambiguity in practical applications.
The ECDSA signature scheme in RFC6919 with elliptic curve secp256k1 returns the signature (r, s, v), where r and s are the values
used in standard ECDSA signatures. v is needed to recover the public key. In programming, The signature (r, s, v) needs to be encoded in standard manner for storage and transmission.
In practice, if two applications interact with signature, e.g. one application generate the signature and another verify. If they use different signature encoding and decoding method, an valid signature may fail the verification. In order to avoid the ambiguity, the it needs to unify the the signature encoding specification.
The TIP concentrates on how to encode the ECDSA signature (r, s, v), regardless of the procedure on how to generate ECDSA signature.
Let S = (r, s, v), we specify its encoding method is
encode(S) = r ‖ s ‖ v
where r and s are 32-byte value, v is one byte, v = 27 + (y % 2). adding 27 is just the conventional manner to denote the v, so
v is 27 or 28.
In practical cases, we find someone may encode signature by encode(S) = v ‖ r ‖ s or someone may regard v as v = y % 2. So we specify the encoding order
of (r, s, v). As for v = 27 + (y % 2), it is consistent with convention used in Bitcoin and Ethereum.
The following is a practical signature encoding example:
private key: 0xc85ef7d79691fe79573b1a7064c19c1a9819ebdbd1faaab1a8ec92344438aaf4
public key: 0x040947751e3022ecf3016be03ec77ab0ce3c2662b4843898cb068d74f698ccc8ad75aa17564ae80a20bb044ee7a6d903e8e8df624b089c95d66a0570f051e5a05b
plain message: message digest
message hash: 0xf7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650
signature: 0xdfe0122b92e0eff35e67d479e7ed774400231c723aef4bb6616f392f2505f63c726c57b96469e0c71eb58e46cd4efd16295e9bba99fb6da3758c026ceb4ace061c
r: 0xdfe0122b92e0eff35e67d479e7ed774400231c723aef4bb6616f392f2505f63c
s: 0x726c57b96469e0c71eb58e46cd4efd16295e9bba99fb6da3758c026ceb4ace06
v: 0x1c
None