-3

Is the same private key using k and k*2 respectively in two different signatures vulnerable? If yes How to calculate the key in this case

4
  • Are you using the RFC6979 standard for deriving k?
    – Chiru
    Nov 27 '21 at 20:31
  • How to do that ? Nov 27 '21 at 21:23
  • Read the RFC: datatracker.ietf.org/doc/html/rfc6979 Nov 28 '21 at 15:59
  • I've rolled back the edit of the question post to return it to the question. Please refrain from disparaging other users in posts.
    – Murch
    Dec 3 '21 at 4:59
-4

c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e is the k1 nonce. a3c2dce777813dc3f0d7a105a5fd56d5894ba30ffa01ba79667cadba37a9d8df is the private key.

4
  • 1
    I don't see how you can compute this based on the information in the question. Can you elaborate on the technique you used? Dec 1 '21 at 16:13
  • 1
    I think someone put together this question or a challenge somewhere else to lead up to this kind of reveal. The "nonce" value c0e2d0a89a348de88fda08211c70d1d7e52ccef2eb9459911bf977d587784c6e appears in multiple blog posts about "hacking bitcoin wallets".
    – Murch
    Dec 1 '21 at 19:31
  • 2
    The private key posted here previously appeared in this stack exchange post before: bitcoin.stackexchange.com/q/37740/5406
    – Murch
    Dec 3 '21 at 5:01
  • I didn't get the key from that post. However, the private key on bitcoin.stackexchange.com/q/37740/5406 multipled by itself gives the private key in question here. c477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96*c477f9f65c22cce20657faa5b2d1d8122336f851a508a1ed04e479c34985bf96=a3c2dce777813dc3f0d7a105a5fd56d5894ba30ffa01ba79667cadba37a9d8df. I didn't get the key from that calculation either. I got the key because the first nonce is exactly half the second nonce on the secp256k1 elliptic curve. the second nonce is 81c5a15134691bd11fb4104238e1a3b10faac0ff27e012e67820911e3eba579b.
    – T M
    Dec 7 '21 at 4:53
3

Assuming you're talking about ECDSA signing. For BIP340/Schnorr signatures, see this answer.

For valid signatures

Let:

  • d: the private key
  • P=d*G: the public key
  • k1: the (first) nonce
  • R1=k1*G: the public first nonce
  • r1=R1.x mod n: the public first nonce as it will be encoded in the signature.
  • k2=2*k1, R2=k2*G=2*R1, r2=R2.x mod n: the same for the second nonce
  • z1 and z2: the respective message hash

The two signatures will then be the pairs (r,s) and (r',s') for which:

  • s1 = (z1 + r1*d) / k1 mod n
  • s2 = (z2 + r2*d) / k2 mod n = (m2 + r2*d) / (2*k1) mod n

Multiplying both sides of the equations by their denominator on the right hand side:

  • s1*k1 = z1 + r1*d mod n
  • 2*s2*k1 = z2 + r2*d mod n

Assuming 2*r1*s2 ≠ r2*s1, this is a set of two linear equations in two unknowns (k1 and d), with solution:

  • d = (z2*s1 - 2*z1*s2) / (2*r1*s2 - r2*s1) mod n
  • k1 = (z2*r1 - z1*r2) / (2*r1*s2 - r2*s1) mod n

Don't ever use related nonces for ECDSA (or Schnorr) signatures. Create a fresh, independent, nonce every time. The industry standard is to generate nonces using RFC6979.

For fake "signatures"

The values you've provided however do not correspond to real signatures, despite satisfying the equation. That's because for a signature to be valid, you have to give the messages which hash to the z values, not just the result. And you can't do that here, because z2 = (r2/r1)*z1. Such matching ratios will not (and cannot) occur for z values that are the result of hashing.

It turns out that given any ECDSA triplet (r,s,z), and integer a, another triplet can be found. Let R be an elliptic curve point whose X coordinate equals r (mod n), and R' = aR, and r' the X coordinate of R'. Then (r',r'*s/(a*r'),r'*z/r) is another ECDSA triplet, corresponding to multiplying k with a. However, again, this is not a valid signature because its z value will not be the hash of a computable message. And the formula above will also fail to retrieve the private key in this case, because the second "signature" wasn't created by using the private key.

5
  • Thanks for your answer, I edited the question and provided the example , Have a look and if you answer according to that it will be easy for me to understand Nov 29 '21 at 7:07
  • I've updated my answer. Your input values don't correspond to actual signatures, and you cannot recover the private key from them. Nov 30 '21 at 17:19
  • pk = ((k1 - modinv(s2, n)*k2 + modinv(s1,n)*k1) * (modinv(modinv(s2,n)*r2 - modinv(s1,n)*r1, n)) % n) ,Is it possible to rewrite it based on the k and k*2 rule Dec 1 '21 at 5:56
  • 1
    Sure, just substitute k2=2*k1. But you'll find that for the specific numbers you've given above, the formula you get doesn't let you compute the private key (you get a division by zero). Dec 1 '21 at 16:24
  • but z can be just 2 or so. like in eth. say id of the method. then this becomes possible Dec 3 '21 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.