The problem appears to be some faulty set-up in hardware, multi-sig, or perhaps a custom hand coded design that generates a not very random number (nounce) when signing with the same private key twice or more. In giving a summary, Joachim Breitner, one of the researchers, says:
“When you create a cryptographic signatures using ECDSA (the elliptic curve digital signature algorithm), you need to come up with the nonce, a 256 bit random number. It is really important to use a different nonce every time, otherwise it is easy for someone else to take your signatures (which might be stored for everyone to read on the Bitcoin blockchain) and calculate your private key using relatively simple math, and with your private key they can spend all your Bitcoins. In fact, there is evidence that people out there continuously monitor the blockchains for signatures with such repeated nonces and immediately extract the money from compromised keys.
Less well known, but still nothing new to the crypto (as in cryptopgraphy) community is the that an attacker can calculate the key from signature that use different, but similar nonces: For example if they are close by each other (only the low bits differ), or if they differ by exactly a large power of two (only the high bits differ). This uses a fancy and powerful technique based on lattices. Our main contribution here is to bridge crypto (as in cryptopgraphy) and crypto (as in cryptocurrency) and see if such vulnerabilities actually exist out there.
And indeed, there are some. Not many (which is good), but they do exist, and clearly due to more than one source. Unfortunately, it is really hard to find out who made these signatures, and with which code, so we can only guess about the causes of these bugs. A large number of affected signatures are related to multisig transactions, so we believe that maybe hardware tokens could be the cause here.”
The very small amount of value affected clearly shows that this vulnerability is of relevance in only very extreme cases. Just $54 worth of bitcoin could be exploited, $14 XRP and 0.00002 eth, according to the paper which further says:
“All of the attacks we discuss in this paper can be prevented by using deterministic ECDSA nonce generation, which is already implemented in the default Bitcoin and Ethereum libraries.”
We’re not very sure this is a 0day. Potential problems with address, thus private key, reuse have been known since forever. However Matthew Green, a cryptography professor at John Hopkins, says: “Dropping the Bitcoin 0day,” in reference to the paper. Asked whether this is really a 0day, Breitner told Trustnodes:
“It wasn’t us that called it a 0day. The repeated nonces thing is indeed old, including the blockchain analysis. What seems to be new is to analyze the blockchain for biased nonces: Nonces that have *not* been repeated, but that are biased in one way or another. Also not new to the cryptography world, but nobody applied it to Bitcoin yet, it seems.”
The paper itself says: “These flaws do not yet appear to be known, or else the funds would have already been stolen.”
They mention the significant amount of computation required, with further consideration being the incredibly small sums involved. Someone with the skill and ability to exploit the addresses, therefore, would probably have a far better use of their time.
In addition, they may have waited for someone to send significant sums to a vulnerable address, instead of revealing it for pennies.
The study does however highlight how hard it can be to get crypto right if you are designing your own or are diverging from best practice.
For everyone else, “since 2016, the Bitcoin client uses deterministic signatures (RFC6979) which completely removes the need for randomness in the process.”
Meaning that if you’re using one of the popular wallets, there isn’t much to worry about as far as this key leakage is concerned.