Reused nonce k across different private keys – possible mathematical link?

[peakyclin77]

Hey everyone,

I came across a weird case while digging into some old addresses that reused the same nonce k (same R value in the signature), but across different private keys. Original thread here: https://bitcointalk.org/index.php?topic=5535021.0

The setup:
Three addresses (let’s call them A, B, and C) all sent funds to the same destination at the exact same second.

I have the private keys for A and C — not B.

Here’s what’s interesting:
The private keys of A and C have a GCD of 63, meaning they are both exactly divisible by 63 — i.e.,
dA = a × 63
dC = b × 63

I’ve also found other key pairs with GCDs of 18, 27, etc. This suggests some kind of structure or weakness in how these keys were generated.

My question:
Could this GCD link help reduce entropy or even lead to the missing key (B)?

Thanks in advance!

[ppbened45]

If the same nonce k (same R value) was reused across different private keys, and you already know the private keys for A and C, there’s a real chance you can recover k from their signatures. Once k is known, you can use it to solve for the missing private key B using its signature.

The GCD of 63 between A and C’s keys suggests they may have been generated using a weak or biased RNG, which could make things even more predictable.

So yes - if k is reused and recoverable, this setup could absolutely reduce entropy and potentially reveal dB. Definitely worth deeper analysis.

[BADERO]

You have found a grave flaw when multiple private keys share the same nonce k (hence the same r value in ECDSA) this on its own can already recover private keys under suitable conditions. Add to the fact that these keys have a GCD pattern (i.e. dA = a × 63, dC = b × 63) and you might very well be looking at a buggy key generator or incomplete RNG that constrains entropy  leaving brute force or lattice based attacks wide open

In ECDSA, the signature is:

Code:

 s = (z + d * r) / k mod n

If a repeated k (and thus the same r) is employed between a number of private keys:
1. You can use known keys (dA, dC) and their signatures to calculate k
2. Next plug k into another signature (e.g. for key B) to get back the unknown private key:

Code:

 d = (s * k - z) / r mod n

Since you have dA, dC, and signatures for A, B, and C (same r), you can likely:
• Recover k using any two known keys
• Use it to calculate dB from B's signature

The GCD of 63 between keys is a red flag it means all keys are multiples of 63 so the private key space is reduced by a factor of 63 this is very dangerous especially if there are a lot of such keys and could even make key recovery possible by brute force or lattice attacks

Bottom line: shared nonce (r) + structured keys = trivially exploitable with the data you have  there's a very good chance of recovering the missing key dB

[peakyclin77]

Alright, thank you for your help. I managed to recover the dB key!

It turns out it was using the same K, but actually -K (so the same R, but with a negative K).

Now, I’ve identified other pairs of signatures (P2PKH addresses) that reuse the same R, but with different private keys, and I don’t know the values of the private keys or K in these cases.
These addresses seem to be related to the ones I just recovered, so likely generated in a similar context.

This time, I suspect that K is large.

So my question is: what would be the best approach to try sweeping these addresses and recovering the private keys?

Thanks in advance for your insights!

[BADERO]

Alright, thank you for your help. I managed to recover the dB key!

It turns out it was using the same K, but actually -K (so the same R, but with a negative K).

Now, I’ve identified other pairs of signatures (P2PKH addresses) that reuse the same R, but with different private keys, and I don’t know the values of the private keys or K in these cases.
These addresses seem to be related to the ones I just recovered, so likely generated in a similar context.

This time, I suspect that K is large.

So my question is: what would be the best approach to try sweeping these addresses and recovering the private keys?

Thanks in advance for your insights!

Well done on using -K to recover the key, it's a small but crucial detail the best course of action now depends on your assumptions about the nonce K you have discovered other signature pairs that reuse the same R (same r in the signature), but with different private keys and unknown K to create a relationship between the two private keys, you can set up the ECDSA equations and remove K if the same R appears in multiple messages in particular, you can derive an equation involving s1, s2, z1, z2, d1, and d2 for two signatures using the same r but different messages and private keys because s = k ^-1(z + r·d) mod n under some presumptions, such as small key theory, this can be rearranged into a two-variable equation Lattice attacks—such as LLL or Coppersmith's method can be used to resolve discrepancies or known structures. You can use d = (s·k - z)·r^-1 mod n to compute the corresponding private key if you suspect that K is reused exactly (or as -K, K + c, etc.) then, you can verify that the derived public key corresponds to the target address. You may also think about examining the entropy or structure of the nonces used if K is big but originates from a weak PRNG or predictable pattern, particularly if these signatures are from the same wallet or buggy implementation the best course of action is to look for nonce reuse patterns, create equations between the private keys, and then use algebraic or lattice-based methods to recover them

[peakyclin77]

here’s the latest news on the addresses I’m currently working on. I’m trying to determine the possible links between them. I don’t know any of the private keys (d1 to d7), nor k1, k2, or k3 — which I assume are large.

The most important goal here is to recover the private key d1, based on 9 signatures.

    d1 was signed using k1, k2, k3, or their opposites (-k1, -k2, -k3)

    d2 and d3 were signed with k1 or -k1

    d4 and d5 were signed with k2 or -k2

    d6 and d7 were signed with k3 or -k3

I'm looking to identify any exploitable link between these keys based on the above observations. Any idea, lead, or suggestion would be greatly appreciated.

[amaclin1]

https://mempool.space/tx/44e20cc1e2573db644a9ac0a1444aef599444504fa4bd472b01a4e001515bd6e
https://mempool.space/tx/3e18e343abfe62aa67de8a559d5b2699fe545cc07e4bca74fa780b6b914e1226

R₁=068c0abbe2fae1a554e532aa725f511088a2ec3654f97236d78c5259a4039f40
S₁=6c736212ceb56988d7f791f6d4c928143b8dc312983ca66dfd01748b2486bc37

R₂=068c0abbe2fae1a554e532aa725f511088a2ec3654f97236d78c5259a4039f40
S₂=2bd87a69d2beb2d3a543968cc26155943907d72a48f634e1d34ca9886c1bca06