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. 
Topic: Bad signatures leading to 55.82152538 BTC theft (so far) (Read 65144 times)
As of August 24th, the funds are on the move. He waited 4 years to try to avoid detection.
https://blockchain.info/address/1HKywxiL4JziqXrzLKhmB6a74ma6kxbSDj
https://blockchain.info/address/1HKywxiL4JziqXrzLKhmB6a74ma6kxbSDj
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.
Damn I still use Netscape 4
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
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.
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.
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.
The part about Netscape4 is a bit weird, I wonder how often that triggers.
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
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.
^Ah, I see. Thanks!
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?
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)
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?
Check this out: https://bitcointalksearch.org/topic/m.2968228 ... I don't think Android was the cause of most of the bad signatures seen recently (despite it's problems).
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.
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.
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.
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?
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.
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.
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.
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 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.
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.
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.
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.
So I guess the answer lies somewhere in the changelogs for the affected projects.
Hire incompetent manager, let him hire incompetent programmers, wait for suitable defect, withhold testcase from QA lab half globe away from your headquarter, enjoy plausible deniability. Jump to: