Timeline for ECDSA: (v, r, s), what is v?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 19, 2018 at 16:59 | history | suggested | alex.kampa | CC BY-SA 4.0 |
Added note about cofactor
|
| Aug 19, 2018 at 13:22 | review | Suggested edits | |||
| S Aug 19, 2018 at 16:59 | |||||
| Jun 19, 2018 at 6:05 | history | edited | Raghav Sood | CC BY-SA 4.0 |
edited body
|
| Feb 11, 2018 at 15:18 | comment | added | Sentinel | @Souza - agreed. It is a struggle. I am trying to contact Ethereum foundation to put together accessible protocol documentation and get funding to do it. I am putting together a light client using reactive extensions and .NET, where I am treating all protocol messages as streams flowing through stack-layer adapters, and trying to insulate the top level protocol from lower level differences (discv4 vs v5 etc for example). By the time I am done I should be able to write a book on it. | |
| Feb 10, 2018 at 16:04 | comment | added | Souza | @Sentinel my strugle's the same. I am working on top of Ethereum's protocol and they say little to nothing about this. And you're right, they both use libsecp256k1. | |
| Feb 10, 2018 at 11:42 | comment | added | Sentinel | @Souza / Pieter - Thanks. I had already managed to discover the answer to that - it took me forever! I did actually find that ASN.1 in sec1-v2.pdf after an enormous amount of digging. When I found it, I thought I'd struck gold. The problem is that the Ethereum documentation (I am implementing an Ethereum light client) does not include detailed protocol info, and official implementations tend to rely on libraries that go where Bitcoin already trod, so details like the 'v' parameter are lost/buried in very, very obscure code. | |
| Feb 10, 2018 at 0:19 | comment | added | Pieter Wuille | 27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y. Note that 29 and 30 are exceedingly rarely, and will in practice only ever be seen in specifically generated examples. There are only two possible X values if r is between 1 and (p mod n), which has a chance of about 0.000000000000000000000000000000000000373 % to happen randomly. | |
| Feb 10, 2018 at 0:14 | comment | added | Souza | @Sentinel You can get full information on the recovery method here: secg.org/sec1-v2.pdf | |
| Jan 10, 2018 at 15:09 | comment | added | Sentinel | Which, please, of the 4 possible output (27..30) corresponds to which of the possible results. Eg: 0 = positive Y and X1? where is this documented? | |
| Oct 27, 2017 at 21:00 | comment | added | Pieter Wuille | ECDSA always supports public key, regardless of the curve. For curves with cofactor > 1 it is slightly more complicated. That linked answer explains the procedure. | |
| Oct 27, 2017 at 18:28 | comment | added | Karel Bílek | @PieterWuille - Is this specific for secp2561k, or can this be generalized for all elliptic curve signatures? Also, how does it relate to this answer on crypto SE - crypto.stackexchange.com/questions/18105/… ? | |
| Nov 13, 2015 at 10:19 | history | edited | Jannes | CC BY-SA 3.0 |
Missing word
|
| Aug 18, 2015 at 12:26 | comment | added | Pieter Wuille | X and Y coordinates are numbers modulo p, the field size, which is around 2^256 - 2^32 for secp256k1. The value r and s in the signature however are modulo n, the group order, which is around 2^256 - 2^128. When R.x is between n and p, r is reduced to R.x-n. Thus, if you have an r value below 2^128-2^32, there may be 2 valid R.x values corresponding to it. | |
| Aug 18, 2015 at 12:20 | comment | added | Wizard Of Ozzie |
@PeterWuille There can be up to 4 different points with a given "X coordinate modulo n". (2 because each X coordinate has two possible Y coordinates, and 2 because r+n may still be a valid X coordinate). I understand the former (2 y values for each x, because of the symmetry)... But how does the latter work? ie r+n may still be a valid X coordinate??
|
|
| Aug 2, 2015 at 9:00 | comment | added | Wizard Of Ozzie | It's more a way of learning things I understand pretty well already, and am interested in. I've learned Python that way and the ultimate goal is to know the core software too | |
| Aug 1, 2015 at 9:42 | comment | added | Pieter Wuille | The signing code is in libsecp256k1, which also has verification code, but that is not currently used. For verification, there is C code in Bitcoin Core (see pubkey.cpp) which does a series of OpenSSL calls to do the bulk of the work. I am not sure that reading cryptographic C code is the best way to learn C++ :) | |
| Aug 1, 2015 at 6:21 | comment | added | Wizard Of Ozzie | Can you link to the code which implements this? I'm going to start learning C++ using functions like this which I understand | |
| Aug 1, 2015 at 4:05 | vote | accept | Wizard Of Ozzie | ||
| Jul 31, 2015 at 23:04 | history | answered | Pieter Wuille | CC BY-SA 3.0 |