You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This TIP aims to present clear signature encoding specification to avoid ambiguity in practical applications.
Abstract
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.
Motivation
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.
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.
Rationale
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.
Test Cases
The following is a practical signature encoding example:
Simple Summary
This TIP aims to present clear signature encoding specification to avoid ambiguity in practical applications.
Abstract
The ECDSA signature scheme in RFC6919 with elliptic curve secp256k1 returns the signature
(r, s, v)
, wherer
ands
are the valuesused 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.Motivation
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.
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 iswhere
r
ands
are 32-byte value, v is one byte,v = 27 + (y % 2)
. adding 27 is just the conventional manner to denote thev
, sov
is 27 or 28.Rationale
In practical cases, we find someone may encode signature by
encode(S) = v ‖ r ‖ s
or someone may regardv
asv = y % 2
. So we specify the encoding orderof
(r, s, v)
. As forv = 27 + (y % 2)
, it is consistent with convention used in Bitcoin and Ethereum.Test Cases
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
Implementation
None
The text was updated successfully, but these errors were encountered: