Bad signatures leading to 55.82152538 BTC theft (so far)

[jl2012]

I know this is an extremely rough estimage, but guesstimating from Number of Transactions excl. popular we can speculate that roughly 20 kBTC have been moved from android wallets (assuming the spike is just that).

55 / 20k = 0.2% of funds stolen due to the bad RNG... could've been worse. I feel with the people who lost money, of course.

As of today only 51% of users of the Blockchain.info app have upgraded to a patched release, if the pattern is similar with other apps a fair number of wallets might still be vulnerable. But you are right it definitely could have been worse.

This is easy to figure out since one could simply screen the blockchain for bad signatures.

[molecular]

I know this is an extremely rough estimage, but guesstimating from Number of Transactions excl. popular we can speculate that roughly 20 kBTC have been moved from android wallets (assuming the spike is just that).

55 / 20k = 0.2% of funds stolen due to the bad RNG... could've been worse. I feel with the people who lost money, of course.

As of today only 51% of users of the Blockchain.info app have upgraded to a patched release, if the pattern is similar with other apps a fair number of wallets might still be vulnerable. But you are right it definitely could have been worse.

This is easy to figure out since one could simply screen the blockchain for bad signatures.

I don't understand what you mean. Obviously not all signatures made by android wallets are bad.

[hyperreal]

I know this is an extremely rough estimage, but guesstimating from Number of Transactions excl. popular we can speculate that roughly 20 kBTC have been moved from android wallets (assuming the spike is just that).

55 / 20k = 0.2% of funds stolen due to the bad RNG... could've been worse. I feel with the people who lost money, of course.

Is there any evidence theft is the cause of the spike, or is this pure speculation? 

Couldn't a spike just as easily been caused by a large number users rotating keys (as would be expected when an updated is pushed out)?

Or, given the volatility of that graph, couldn't it have likely just been noise?

[molecular]

I know this is an extremely rough estimage, but guesstimating from Number of Transactions excl. popular we can speculate that roughly 20 kBTC have been moved from android wallets (assuming the spike is just that).

55 / 20k = 0.2% of funds stolen due to the bad RNG... could've been worse. I feel with the people who lost money, of course.

Is there any evidence theft is the cause of the spike, or is this pure speculation? 

Couldn't a spike just as easily been caused by a large number users rotating keys (as would be expected when an updated is pushed out)?

yeah, that's what I tried to say. Spike caused by key rotations.

Or, given the volatility of that graph, couldn't it have likely just been noise?

Yep. At the time I posted it looked more "spikey". It could still be noise or something else of course. But it's pretty clear that people moved their money. Hard to say how much, of course.

[Jesse James]

Check this out: https://bitcointalk.org/index.php?topic=277595.msg2968228#msg2968228 ... I don't think Android was the cause of most of the bad signatures seen recently (despite it's problems).

[Nubarius]

What is the value range for k?

k must be between 1 and p where:

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

    = 2^256 − 2^32 − 2^9 − 2^8 − 2^7 − 2^6 − 2^4 − 1

This largest value is different from the one mentioned in the wiki (https://en.bitcoin.it/wiki/Private_key), which is  0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141. The exact number is not very important, but just out of curiosity, which is the right one?

[jackjack]

What is the value range for k?

k must be between 1 and p where:

p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

    = 2^256 − 2^32 − 2^9 − 2^8 − 2^7 − 2^6 − 2^4 − 1

This largest value is different from the one mentioned in the wiki (https://en.bitcoin.it/wiki/Private_key), which is  0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141. The exact number is not very important, but just out of curiosity, which is the right one?

The latter
What you wrote is n and is the upper limit
p is just the prims number you use when doing EC operations

By the way its not really an upper limit: n+1 is a pretty valid private key, it's just that it's equal to 1 (as n+1 mod n == 1 mod n)

[Nubarius]

^Ah, I see. Thanks!

[gmaxwell]

By the way its not really an upper limit: n+1 is a pretty valid private key, it's just that it's equal to 1 (as n+1 mod n == 1 mod n)

If you generate that way you will end up with keys which are not equiprobable. The difference from uniform is very small, but its a certificational weakness you should avoid.

[btcdrak]

By the way its not really an upper limit: n+1 is a pretty valid private key, it's just that it's equal to 1 (as n+1 mod n == 1 mod n)

If you generate that way you will end up with keys which are not equiprobable. The difference from uniform is very small, but its a certificational weakness you should avoid.

Is the version of securerandom.js used at bitaddress.org safe? https://github.com/pointbiz/bitaddress.org/blob/master/src/securerandom.js

[Sukrim]

Depends mostly upon where your browser gets it's values for Math.random() from I guess. This is quite off-topic however...

The part about Netscape4 is a bit weird, I wonder how often that triggers.

[molecular]

Depends mostly upon where your browser gets it's values for Math.random() from I guess. This is quite off-topic however...

The part about Netscape4 is a bit weird, I wonder how often that triggers.

netscape4 ?

EDIT: sorry, I see. You're talking about the linked code.

[jl2012]

By the way its not really an upper limit: n+1 is a pretty valid private key, it's just that it's equal to 1 (as n+1 mod n == 1 mod n)

If you generate that way you will end up with keys which are not equiprobable. The difference from uniform is very small, but its a certificational weakness you should avoid.

Is the version of securerandom.js used at bitaddress.org safe? https://github.com/pointbiz/bitaddress.org/blob/master/src/securerandom.js

I personally don't trust any computer generated random number. All my addresses are generated with other methods with 256bit entropy

[bitpop]

Damn I still use Netscape 4

[BurtW]

That paper says that without /dev/random devices (what is a very rare case I believe) SecureRandom use only 31 bits of entropy. It is a horrible situation, but even in this case it is very unlikely that there will be two equal random numbers in signature creation in the whole world.

Given good "enough" secure random number generation the ECDSA used by Bitcoin works.  Bad random numbers, especially repeated numbers, is fatal to the ECDSA used by Bitcoin.

It has been suggested we move to a new ECDSA algorithm that does not use a random nonce.  We should.

[mokahless]

As of August 24th, the funds are on the move. He waited 4 years to try to avoid detection.

https://blockchain.info/address/1HKywxiL4JziqXrzLKhmB6a74ma6kxbSDj

[gmaxwell]

He waited 4 years to try to avoid detection.

Unless I'm missing something the party moving these coins may not be the thief... he could have sold them or deposited them in an exchange 4 years ago and they're just moving now.