Topic: Nonce k and k +1 (ECDSA SIGNATURE) (Read 2272 times)

Nonce is a secret key for pubkey 02+r

a slight tangent question on this topic....

When trying to acquire  data suitable to  calculate all desired components ( R,S, K, Z, etc...) are we better of :

A) searching through all transaction hashes of an address?

B)Searching through UTXOs hashes?

c) searching through spent only outputs hashes ?

D) searching throught unspent only outputs hashes?

Thanks!

Private KEY:  0xB493E748065400A61D7AFCB0BB852B36EC6D39A0BA41D65307DB568792EA3797

k1 = 0xC8334DE96BCD1073839831DD17A24173C3C2E3396CAB5FCD3544A83F5B476B85
r1 = 0x49bf1b1c8364c4179bd82a3be28b1a326c2c1b2d120c3264865ecbc4dbaed4b3
s1 = 0x4ad0d60d72880bf0a51d88d0d5138ffa3593273bd0b3d48a5afe04023db9c2c9
z1 = 0x1362d682d8872a0451e5f0d86f743a62bf0730b57ddddc901668d837cbfa2f48

k2 = 0xC8334DE96BCD1073839831DD17A24173C3C2E3396CAB5FCD3544A83F5B476B86
r2 = 0xad7991e3b3d36f6f17a22fad1faddc53e7c124e5b6626db172c79299fce5cfb6
s2 = 0x10ecd8352675027f74edc18180ac083d75a1488497c6c3078a5966015514ac46
z2 = 0xfec02a5d53eb20a6e470b7c321e0da83ea6d677f600f67033abf4b0e6b8745aa

k2 = k1 + 1

I think this is best solution to break Ecdsa.

interesting formula:

If k2!=k1 then r2!=r1 (the case where k2=k1 + M)
and you

Code for finding difference between k and k1+M
 While (k1+M != k:

         (k1+ M ) = (k1+M) - 1


I think what k1+M is a r , so make pubkey is easy and find  difference between two r is possible because the will be in a range of k . But what to do if difference is funded , what next can be ?

Hi I tried this and this don't worked for me.

Hello friends. Inspired by the table on iceland's rsz, I created code in phyton for the cases where k,k+1...k+m. Since there is no such example whose private key I know, I ask you to check it. If it works, I will publish it on github. As far as I can see, there is no such resource, we can all benefit from it. Can anyone who sees it please check it out and give their opinions?

Hello friends. I have two RSZ values obtained from the transfer of a bitcoin address and I want to find the nonce/private key. I do not write the values for confidentiality reasons, but I give approximate values as an example. k can be k+1. I'm sure there are many people here who can figure this out, but I can't. Any python code formulas etc that can help me? is there? I need your ideas.
R1 = 00a61d1110016763ed34995c319a42ea81b96a593efb29a4a46880bd8fe955077f
S1=009a72c80ae72e6edbe93d96d0202cc73bdf4ed1630c23381b2891e2427393878
Z1=306801f94f8bed2d753a66c60a614f359ff94758937bc7f950a9865d33ce1092

R2 = 00a6f4e7382a1c878a740e113c313779bcaa2dc20af5c1ff6c2bb7011cfb278c0d
S2=009cbddcba33bd30b4caad188ab02552e68b74fd43946e5b5a7f593dd367a26d28
Z2=9c76db1673ded5f0028abe36ad3b47bc47973681530481a32e1e7dd2f66ba0fd

The values are here, R1-R2 and S1-S2 are close to each other. I don't know how to make the connection. And of course how to calculate this correctly. I would be grateful if you help.

you want say that H(m) of transaction? if message is empty/null it just sha256(sha256(020000000155010ca6a15764977be218d19259d3e021b80851a1338530ad40d612f07c4b5801000 0006a47304402202062fb0a71961e18f155a3d54b468f1560425a8bd8a7fc9c6064aac149a24108 02201e5469c0d89bb32faf087eabf1d631c35b829bc45e09a8728e88c320811b01fc01210248d31 3b0398d4923cdca73b8cfa6532b91b96703902fc8b32fd438a3b7cd7f55ffffffff019808000000 0000001600143faaa7380c35d3d307b7caa3d2a1038fd3fe2c0500000000)) - and thats it?

I have never used sagemath before but this is sage code so it should work exactly as-is.

It might also work in Python just like that, considering that it uses GMP under the hood, but you might see exponents to the power of 10  instead of the actual number.

You take the text input, whether it is some signed message text or a raw transaction, and then pass it through SHA256(SHA256(input)), and save the result as e.

For ECDSA done on the secp256k1 curve, such as all kinds of bitcoin signatures, we are done at this point and we can set h = e our message hash.

However for some other different curves, you have to take the leftmost n bits of e after the double SHA256 hash. Where n can be found from the group order of the curve. So for example, secp256k1's group order is about 2^256 so it's n would be 256.

Keep in mind that the leftmost n bits equals the entire length of e if log2(curve's group order) == bit length of hash function used. When we are using both double SHA256 and secp256k1 curve in ECDSA like we are now, we know the double SHA256 always outputs 256 bits so these two values are equal and the entirety of e is used as the message hash.

The above paragraph implies that you are able to use a different hash function other than double SHA256 provided that its number of bits of output is greater than log2(curve's group order), because smaller-length hash functions are not allowed to be used with larger curve orders.

How can one calculate a message hash?

I've been busy for the past few days ...
I would like to show that the topic signature is real and valid (in theory)



x, k, r, h and s are in the order of the curve and are fully accepted by the bitcoin protocol!


Satisfies all the math required of a valid signature

This is not the objective of this thread . I am still trying to find some method to resolve these signatures. And I'm also creating other fun things ... this other thread is very interesting https://bitcointalksearch.org/topic/m.56483595

So.... It is posible finde k with different s_1,b_1,z_1 and s_2,b_2,z_2 from one publick key transactions sign? Use a s_1,b_2, s_2=s_1,b_2  more easy I think...

P.s. please, if you don know exact, do not post a messages about unrial find a k without s_1=s_2

P.s. all optimists are welcome

Equation with only 1 variable and we were unable to solve it. I'm already getting agonized

I know that the concept of the signature is to prove data integrity, to prove that a person has a particular private key, to prove many other things. Now about these two signatures ... In theory, I prove that these two signatures on this topic are real and valid! Now in practice, it would even prove, but it would be totally impracticable and crazy to try brute force with pre image.
If you think it's more correct ... I can change the title and description.
k and k + 1 of signatures (theoretically real and valid)
Is there any method for solving these types of theoretically signatures?
Is it better this way?

@bytcoin

Your question has been answered.  Please very carefully read over these two posts:


@bytcoin, let me try to paraphrase these answers for you:

If my formula to find k (and then find the private key) OR the formula in the other thread that finds the private key directly OR any of the other correct formulas in this thread or any other thread do not work to find the private key then the signature is not a valid signature.

Do you understand now? 

Your question boils down to this:  If I create a totally invalid signature why do these formulas not work?

The answer is right there in your question:  The reason it does not work is that you started with an invalid signature.

I hope this help.

BurtW

@NotATether I just finished the tests ... I tried three more equations, including yours. I modified the equations, tried other methods but no progress for today.
I know that we have only one unknown variant. That's what motivates me and gives me hope, but it's difficult! I may be talking nonsense, but for me this difficulty has to do with the security of ECDSA ... if we can really find some method that calculates these types of forged signatures it will be a great advance.
Today is done! I think these calculations are driving me crazy

Just use the third-to-last one, it's condensed and easy to understand.


You're only interested in k,k+1 so just set N to 0 and M to 1 to get rid of at least one unnecessary term My mistake, you need to set N and M both to 1 to reduce it to k,k+1.


What do you mean? We already know s1 s2 r1 r2 h1 and h2, the constants M and N which I introduced can be removed by setting to the values at the top of this post, and n is the group order of secp256k1. That only leaves us with k as the unknown. The whole right-hand side becomes a constant which makes k solvable.

Fried my brain

k₁ = s₁s₂Mr₂^-1r₁ - s₁h₂r₂^-1r₁ + s₁s₁h₁ - s₂Mr₂^-1r₁N^-1s₂^-1r₂r₁^-1 + h₂r₂^-1r₁N^-1s₂^-1r₂r₁^-1  - s₁h₁N^-1s₂^-1r₂r₁^-1 mod n

I was thinking yesterday before I went to sleep and I think we can hardly resolve this. It must be related to the security and integrity of ECDSA. I think the degree of difficulty is the same as solving a discrete logarithm. Certainly, an obstacle has been placed in a way that cannot be solved. Will not give up! What do you all think?

So let me see if I understand this correctly, and for brevity all sides of each equation are mod n.

(s₁k₁ - h₁)r₁^-1 mod n = (s₂(Nk₁ + M) - h₂)r₂^-1 mod n

(s₁k₁ - h₁) mod n = (s₂(Nk₁ + M) - h₂)r₂^-1r₁ mod n

(s₁k₁ - h₁) mod n = (Ns₂k₁ + s₂M - h₂)r₂^-1r₁ mod n

(s₁k₁ - h₁) mod n = Ns₂k₁r₂^-1r₁ + s₂Mr₂^-1r₁ - h₂r₂^-1r₁ mod n

s₁k₁ - Ns₂k₁r₂^-1r₁ mod n =  s₂Mr₂^-1r₁ - h₂r₂^-1r₁ + s₁h₁ mod n (this is the one you corrected, all I did differently is I injected an N term. You missed an s₁ at the end)

k₁(s₁ - Ns₂r₂^-1r₁) mod n =  s₂Mr₂^-1r₁ - h₂r₂^-1r₁ + s₁h₁ mod n

k₁ = (s₂Mr₂^-1r₁ - h₂r₂^-1r₁ + s₁h₁)(s₁ - Ns₂r₂^-1r₁)^-1 mod n


While this is correct, I could expand the right hand side to remove all those parentheses but it would look like a hairy mess and I will leave it as an exercise for the reader I'm a sucker for finishing what I started so the final result is:

k₁ = s₁s₂Mr₂^-1r₁ - s₁h₂r₂^-1r₁ + s₁s₁h₁ - s₂Mr₂^-1r₁N^-1s₂^-1r₂r₁^-1 + h₂r₂^-1r₁N^-1s₂^-1r₂r₁^-1  - s₁h₁N^-1s₂^-1r₂r₁^-1 mod n

which can naturally be simplified to

k₁ = s₁s₂Mr₂^-1r₁ - s₁h₂r₂^-1r₁ + 2s₁h₁ - MN^-1 + h₂N^-1s₂^-1  - s₁h₁N^-1s₂^-1r₂r₁^-1 mod n

The terms without an M or N can be cached if you code this which'll save a some runtime, assuming signatures and message hashes are constant (which means we're just brute-forcing k by assuming the other k is different from k by a linear term, Nk + M).

@NotATether Sometimes, my comments are confusing. My English is not good. I'm sorry.
I created a spreadsheet here on my computer. If the calculation of the two signatures, result in one of these results:

84116094074080348475330923628085381068004819051024688231235408808498228990658
115421525668746794300572425383651760936474682288376011738901581099735267291166
75779132765082272339365318603976127143129139578655065948953011818747694903968
32721048879590668468057403381344519604794634274281442143310950080100256809376
73945527799545926295868811396190775221755301413228649694146980038976859413881
83071040357725526955513581627343388248042930004793462239294213061417904684961
110900498335176639903790421791145116630753202651925129197353093911482849572115
100915994223500593859265530587355021827054480090260046643398682409155495014021
18772090316994453489815097488437362913349084079003363299774406415210330663724
47226580324836868909364298177641258714214836472397407238813848770680029086521
56529777543389028600359529180589793809150046410530956964827364144104464543696
68565508912479326514206686831046649138622727806677497143791314370838132407816
95614300240862244467441604468469811057219298200932829791855660913288043519424
91853994770595467928679085106674415264953937877422163279062103074479382308082
70340029117077187103609015206390689046236439143934658628690673731161038123272
56288579777741994839950743658321865276315378685235290603150428105356141792460
114077498629986369252568485796816272967465715858922414102041658195335049229411
59503509459574200583620241350366042576522185593839613779454735036162019701877
3157016186039629198989683176712727066004916479529634997551227882338456118091
113972727122455751122606348709450118426555794247055235259681988180640808438349
78050106958269618215705840346149000019834478654902500371716973685533534066650
34169847425881711646023480055546162114713522315602218622530542999194715662193
73621331483084656777597982069714150546901789628714569435738760993298398924203
81622241811434483777547504953141745738124041963472685760074620142323445832144
70340029117077187103609015206390689046236439143934658628690673731161038123272
44718176830454434898540719422248360645570272508025487909509951706716265490856
95614300240862244467441604468469811057219298200932829791855660913288043519424
103424397717883027870089109342747919895699044054631965972702579473119258609686
21101819692638526149317216481479108956505606170114713781324009606425162496681
12367691519433167553481875665939987957138520224442938409902583668398902884651
112635073051276566224581301831975180786832647799545269385053935259179705376246
34169847425881711646023480055546162114713522315602218622530542999194715662193
37741982279046577207865144662538907833003085624172404010888189455984627427687
113972727122455751122606348709450118426555794247055235259681988180640808438349
42170757754231538645973002938973757305935774650360334946866402148219762570134
1819362114860444300964636299237789426281770032019669122923174960877353055988

My spreadsheet will find the private key and it will also be possible to create a formula that solves all the signatures we are trying to calculate.

For example:
p  = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 27086795414784162292297506376302057554366609881154614249233399373002336547922
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 75792077109774170129890375817094910949609540422199126584222852124036872408123

w = (h1*h2 -r1+r2/s1*s2) if the result was: 1819362114860444300964636299237789426281770032019669122923174960877353055988 or any of those others ... my spreadsheet finds the value x and it will also be possible to create a method that solves all types of signatures.

I'll use your equation ... it looks very efficient! If it works, you will enter the history of bitcoin. I think this thread will yield a lot of comments

I would like to remember

The denominator value in mod N with the numbers you gave is 0

It does change everything. You can't just ignore the multiplied value in here
The correct thing is:
(s₁k₁ - s₂k₁r₂^-1r₁) mod n = (s₂Mr₂^-1r₁ - h₂r₂^-1r₁ + h₁) mod n

Good catch. Fortunately this doesn't change the solution much, only r₂^-1r₁ has to be added at the right hand side of all the solutions and to simplify things further they aren't multiplied by k.


The good thing about this is that I only need two signatures, one is for a known k, the other from an unknown k which is related to the first k somehow. By changing the value of the other k (ie trying different formulas to calculate it), I can brute force the unknown k by using Taylor series to expand any complex terms in the equation for unknown k like exp(x) or log(x), and then take the resulting polynomial of k and find it's root.

I'll try to find a method for it today.


What are all those numbers you posted at the bottom,  one of the ECDSA variables?

I think you are mixing two different things here.
If k₂==k₁ then r₂==r₁
but
If k₂!=k₁ then r₂!=r₁ (the case where k₂=k₁ + M)
and you can't remove it.
Keep in mind that k is also a private key (the ephemeral key) with public key R and r is the x coordinate of it mod n. In other words k is used to calculate r.

@NotATether you did a great search! I liked your method.Do you need more signatures like these? Today I didn’t have much free time, but tomorrow I will have more time to try to find new methods.
Today I only had time to analyze the formulas that worked for the other thread ... I modified the formulas to try to calculate here ... I had some advances!

p  = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 27086795414784162292297506376302057554366609881154614249233399373002336547922
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 75792077109774170129890375817094910949609540422199126584222852124036872408123

Any method that results in one of these results ... will be a huge step forward to create some formula that calculates the private key of these types of signatures.

84116094074080348475330923628085381068004819051024688231235408808498228990658
115421525668746794300572425383651760936474682288376011738901581099735267291166
75779132765082272339365318603976127143129139578655065948953011818747694903968
32721048879590668468057403381344519604794634274281442143310950080100256809376
73945527799545926295868811396190775221755301413228649694146980038976859413881
83071040357725526955513581627343388248042930004793462239294213061417904684961
110900498335176639903790421791145116630753202651925129197353093911482849572115
100915994223500593859265530587355021827054480090260046643398682409155495014021
18772090316994453489815097488437362913349084079003363299774406415210330663724
47226580324836868909364298177641258714214836472397407238813848770680029086521
56529777543389028600359529180589793809150046410530956964827364144104464543696
68565508912479326514206686831046649138622727806677497143791314370838132407816
95614300240862244467441604468469811057219298200932829791855660913288043519424
91853994770595467928679085106674415264953937877422163279062103074479382308082
70340029117077187103609015206390689046236439143934658628690673731161038123272
56288579777741994839950743658321865276315378685235290603150428105356141792460
114077498629986369252568485796816272967465715858922414102041658195335049229411
59503509459574200583620241350366042576522185593839613779454735036162019701877
3157016186039629198989683176712727066004916479529634997551227882338456118091
113972727122455751122606348709450118426555794247055235259681988180640808438349
78050106958269618215705840346149000019834478654902500371716973685533534066650
34169847425881711646023480055546162114713522315602218622530542999194715662193
73621331483084656777597982069714150546901789628714569435738760993298398924203
81622241811434483777547504953141745738124041963472685760074620142323445832144
70340029117077187103609015206390689046236439143934658628690673731161038123272
44718176830454434898540719422248360645570272508025487909509951706716265490856
95614300240862244467441604468469811057219298200932829791855660913288043519424
103424397717883027870089109342747919895699044054631965972702579473119258609686
21101819692638526149317216481479108956505606170114713781324009606425162496681
12367691519433167553481875665939987957138520224442938409902583668398902884651
112635073051276566224581301831975180786832647799545269385053935259179705376246
34169847425881711646023480055546162114713522315602218622530542999194715662193
37741982279046577207865144662538907833003085624172404010888189455984627427687
113972727122455751122606348709450118426555794247055235259681988180640808438349
42170757754231538645973002938973757305935774650360334946866402148219762570134
1819362114860444300964636299237789426281770032019669122923174960877353055988

Have you by any chance read this? https://eprint.iacr.org/2019/023.pdf

It describes methods which let us compute private keys if we have multiple signatures but using the same nonce. So maybe we can take the stuff there and apply it to the case we have a bunch of signatures with k and k+1 nonces. And by extension, k + constant M nonces.

First off it says if we know k then we can just get the private key with d_A = (sk - h)r^-1 mod n. But here we have two signature that use k and k+1. I suppose we can do some sort of attack with this by discovering the k of one signature and then "assuming" that for a large list of (r,s) signatures, that some of them have k+1, k+2, ... or k+M nonces.

It also gives the case of two signatures having the same nonce, where you can recover the private key by doing d_A = (h₁ - h₂)(s₁ - s₂)^-1 mod -n.

Now we have s₁ = k₁^-1(h₁ + d_Ar₁) mod n and s₂ = k₂^-1(h₂ + d_Ar₂) mod n.

That means d_A = (s₁k₁ - h₁)r₁^-1 mod n = (s₂k₂ - h₂)r₂^-1 mod n. We have r₁ = r₂ because k is not used to calculate it. This simplifies things further to (s₁k₁ - h₁) mod n = (s₂(k₁ + M) - h₂) mod n

(s₁k₁ - h₁) mod n = (s₂k₁ + s₂M - h₂) mod n.

Let's take this last equation and use algebra to move k₁ to the left.

(s₁k₁ - s₂k₁) mod n = (s₂M - h₂ + h₁) mod n

k₁(s₁ - s₂) mod n = (s₂M - h₂ + h₁) mod n

k₁ = (s₂M + h₁ - h₂)(s₁ - s₂)^-1  mod n (I just reordered h1 in front of h2 which doesn't change the equation)

Where M =1 if you are using k,k+1 and M=2 if you have k,k+2, etc. and it works for M=0 and negative M as well (which you'd use for k,k-1, k,k-2, and so on.

---

EDIT: If we plug Nk + M instead of just k + M, following the proof derivation above (which I can repost for this particular case if you want) gives us k₁ = (s₂M + h₁ - h₂)(s₁ - s₂N)^-1  mod n. I'm sure there's a formula for k₂ being an arbitrary polynomial of k₁, I'm still trying to find one for that.

EDIT2: for k,k²+M we have k₁(s₁ - s₂) + s₂k₁² mod n = (s₂M - h₂ + h₁) mod n. So at this point it seems that you have to calculate terms of a series find the root of this polynomial if you want an solve for arbitrary k2 = a + bk1 + ck1^2 + ...

@BurtW I would like to thank you for trying to help me!I value and try to learn from all the comments from the bitcoin community.
Answering your question ... is k and k + 1.The private key is the same for all signatures.

sig = 1

h = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s = 14810718830809274529170993651437030466460552688297005873719201854608653306524
k = 87244814473377946459021394573120624638544621973526661110335002719552586402926
x = 74071287274168731384314914382498140270634658281328726941106265589917762050271

sig = 2

h = 27086795414784162292297506376302057554366609881154614249233399373002336547922
r = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s = 75792077109774170129890375817094910949609540422199126584222852124036872408123
k = 87244814473377946459021394573120624638544621973526661110335002719552586402927
x = 74071287274168731384314914382498140270634658281328726941106265589917762050271

The purpose of this thread is to find some method that calculates this type of signatures...to find k or x.

The point of my last reply is that I assume there is no 'message' in these cases,  instead of some material hashed the values were just chosen in order to result in the singularity.

This is the data that works:


This is the data that does not work:


p, h1, r1, s1 and r2 are identical in both data sets.  This means you used the same private/public key pair and the same starting value for k in both cases.

However the values of h2 and s2 are different between the two cases.

What exactly did you change between the working and the not working case?  Just the message?  For sure you started with the same k value.

Since both cases use k for the first value and you are claiming that the second k value in both cases is k + 1 then it looks like maybe all you did was change the message?

@NotATether Exactly! You understand me perfectly! I think this has not yet been explored or little known ... It would be a different method. I'm doing a lot of research and calculations ... every week I'm discovering interesting things

I was going to say something similar. Have you thought of making a table of k,k+1 pairs that have no solution so we can see if there is some pattern among them? Maybe they have some property we don't know yet that makes this formula invalid.

In the other thread... many formulas work, but in this one I believe that none work.
Maybe using Bleichenbacher’s or similar I can solve this 2 signatures of this thread
I think you need approximately 500 signatures to discover the private key

This is more difficult
https://bitcointalksearch.org/topic/m.56365768

I think some users didn't understand me ... Maybe it's because my English is not good and they also need to pay more attention.
English is not my language, I will try to be more objective!

1- I know the other thread! I am the author of another thread similar to this one! I managed almost everything "manually" including public keys and signatures!


2- In the other thread I was wondering if 2 signatures with the same private key and with k and k +1 was vulnerable. They said yes! So I asked them to teach me how it was calculated to discover the private key


3- On the other thread ...a second signature is different from this thread here. Although in the 2 thread 2 signatures use the same private key and were also generated with k and k +1. in the thread another... the equations, algebras and formulas worked!

p  = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 711922952377524543467576566144169816136170490747613227449590530659320692002
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 56412229366601912356674994073152925730313351483910294670205660420888695151902

This formulas works:

d_U = (1 - s₂^-1e₂ + s₁^-1e₁) * (s₂^-1r₂ - s₁^-1r₁)^-1 (mod n)

d = 74071287274168731384314914382498140270634658281328726941106265589917762050271

p  = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 711922952377524543467576566144169816136170490747613227449590530659320692002
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 56412229366601912356674994073152925730313351483910294670205660420888695151902

Replaces s1 with its modular multiplicative inverse and s2 with its modular multiplicative inverse

x = (1+s1*h1-s2*h2)/(s2*r2-s1*r1)

x = 74071287274168731384314914382498140270634658281328726941106265589917762050271


Many others work ... but the 2 signatures of this thread although it also uses the same private key and with the nonce k to k + 1...no equation or formula or algebra or magic works!

p  = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 27086795414784162292297506376302057554366609881154614249233399373002336547922
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 75792077109774170129890375817094910949609540422199126584222852124036872408123

d_U = (1 - s₂^-1e₂ + s₁^-1e₁) * (s₂^-1r₂ - s₁^-1r₁)^-1 (mod n)

d = 0

Does not work!

p  = 115792089237316195423570985008687907852837564279074904382605163141518161494337
h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 27086795414784162292297506376302057554366609881154614249233399373002336547922
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 75792077109774170129890375817094910949609540422199126584222852124036872408123

Replaces s1 with its modular multiplicative inverse and s2 with its modular multiplicative inverse

x = (1+s1*h1-s2*h2)/(s2*r2-s1*r1)

x = 0

Does not work!


4- My final conclusion ... Not all signatures are vulnerable when the same private key is used and with the nonces k and k + 1 and also the 2 signatures of the first post are not vulnerable because there is no equation formula or algebra or magic to solve!


5- Thanks to everyone! I'm learning a lot from the bitcoin community!

@gmaxwell In my point of view ... If you have h (m), r and s being a valid signature, it is a real signature yes ... but it depends only on your

@Coding Enthusiast Exactly! I believe that nobody knows any formula or equation or algebra or magic that solves this

@MixMAx123 When I said to calculate the 2 signatures ... I was referring to the calculation to find k or x

By revealing k, you have already made its private key vulnerable to calculate. (And I already showed you how in the thread Coding Enthusiast linked.)

That's the reason why ECDSA specifically requires that a cryptographically secure nonce k has to be chosen and not something trivial such as k+1 or k mod [some prime] or even some pseudorandom generator that derives two successive k without resetting the seed. If you use anything other than a true RNG to get k then it will always be computationally feasible to find some formula that takes two successively generated k values and the algorithm that generates the next k, that runs in polynomial time.

By definition, if you can reverse a cryptographic algorithm in polynomial time then that itself is a vulnerability.

EDIT: and to answer the question in your other thread (you didn't have to make another one), no you cannot, because the only equation in ECDSA that uses the private key, s = k^-1(z + rd_A), has an unknown k, and you can't derive the private key from a signature without it which is exactly why you're supposed to securely generate your nonce.

It's not really an ecdsa signature if you're just handed a hash.  Performing the hashing is integral to the process and without it you can generate all sorts of degenerate examples. ... including 'forged' 'signatures' for pubkeys where no one knows the private key.

The problem is that with these specific values given in OP it is not possible to compute this particular case.
Whether you use my equation in that other topic to directly compute the private key (d_u) or first compute k with your equation here then compute private key from there, you'll get 0 which you can't compute its modular multiplicative inverse (ax ≡ 1 (mod m) where a=0 doesn't have an answer).
To be specific:
s₂^-1r₂ - s₁^-1r₁ = 0
Also
r's - rs' = 0

Did you do all the operations mod n where n is the bit length of the group order?

I really think this should work, unless I made a mistake in my math.  Did you double check all my algebra?

I believe I wasted my time since there is a perfectly good solution/proof that shows how easy it is to get the private key if you know the relationship between the two k values in your other thread here:

https://bitcointalksearch.org/topic/--5316741

Sure it's possible! The result of the calculation of signatures is only: "true" or "false".
The calculation bases for signatures are well known. It is the main task of checking the signature of every Bitcoin node, which is done 100 times per second. Your shown signatures can also be checked in this way.
The formula for this has been shown to you several times by many users and me, as well as it has been calculated here for you.
I cannot follow you and understand which questions are still unanswered for you.

Does not work for this 2 signatures

The private key of these signatures is already known ... but no equation, formula or algebra is known to calculate these 2 signatures

My knowledge is limited, but I think 2 signatures with different h (m) r and s ... are not the same signature

Please check my work but I think that if you know k is being incremented then you can simply calculate the private key.

All of the variables and terminology in this post are from https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

Given two different messages with two different signatures we have:

First message and signature (m, r, s)
Second message and signature (m', r', s')

From each message we can derive the z value (hash of the message) so:

First message and signature (m, r, s, z)
Second message and signature (m', r', s', z')

Therefore:  ks = z + rd_A and k's' = z' + r'd_A

Therefore:  (sk - z)/r = (s'k' - z')/r'

But in this case k' = k + 1 so:

(sk - z)/r = (s'(k + 1) - z')/r'

So all you have to do is solve for k.  All the other values:  s, z, r, s', z', and r' are all known.

(sk - z)/r = (s'(k + 1) - z')/r'

rr'[(sk - z)/r] = rr'[(s'(k + 1) - z')/r']

r'(sk - z) = r(s'(k + 1) - z')

r'sk - r'z = rs'(k + 1) - rz'

r'sk - r'z = rs'k + rs' - rz'

r'sk - rs'k = r'z + rs' - rz'

k(r's - rs') = r'z + rs' - rz'

k = (r'z + rs' - rz') / (r's - rs') all mod operations, of course.

Once you know k you can simply calculate the private key, d_A


Also note that any scheme where k' = k + n is vulnerable, n does not have to be just one.

If k is not random, like here, the private key is exposed. It can be easily calculated here!
And I've already calculated this on a similar thread.
There is no need for a formula to make these transactions vulnerable, because the gate is already open here!

r1/s1 mod order = r2/s2 mod order

it's same signature, no diffrent signature

I was informed that the same private key using k and k + 1 respectively in two different signatures was vulnerable ... I think that not all signatures generated in this way are vulnerable!
These two signatures were generated by the same private key and with nonces k and k + 1 respectively! Is there a formula or equation to make them vulnerable?

sig = 1
3045022100dcf17de661e280dbf62e03ef1655d1baaabc301da9fc6b29a63e52e7780c115d02202 0be91ddd5598e22fa43014172df5312275fbdb462a2e9855c7a7433138a4a9c01

Public key: 02c811f01a6182c8f6641fa692a997eebe4ea4241ead22bb3b98ae43e9d32fd32b

h(m): bb1e00d2027efd3085b83de2a3602a8ea49e0c9d5b821cd6291d5feefd410303

-------------------------------------------------------------------------------------------------------------------------------
sig = 2
3045022100fe53a1f944263756330a54b2c5a1c5e8afb001e0074f067dd3e408349d2a9d6802210 0a790cba1e3b60e8a75de69efd7e7af1bf0e2543137da79aed2d6409616120c3b01

Public key: 02c811f01a6182c8f6641fa692a997eebe4ea4241ead22bb3b98ae43e9d32fd32b

h(m): 3be295398c9e7048e32c7a30d413f82d7f8b3029ab37d110181744fe0acab452

--------------------------------------------------------------------------------------------------------------------------------

h1 = 84635513758865831094131084311208775267495704821994249663954751780286420288259
r1 = 99935505760319748698811422354322418311203851828465328908708024011195996180829
s1 = 14810718830809274529170993651437030466460552688297005873719201854608653306524
h2 = 27086795414784162292297506376302057554366609881154614249233399373002336547922
r2 = 115035229747891778996889965749694763606205313739267493174821202115705061416296
s2 = 75792077109774170129890375817094910949609540422199126584222852124036872408123