Bitcoin Forum

I've been watching this thread for a bit https://bitcointalk.org/index.php?topic=433522.600 (https://bitcointalk.org/index.php?topic=433522.600) and they may be onto something. Allegedly, with only a bit of searching, collisions have been found of private keys, using public keys. I'm mostly in fiat for now, although I don't think any of us smaller holders need to worry that much :P.

Here's the site displaying live stats: https://bitcointalk.org/index.php?topic=433522.600 (https://bitcointalk.org/index.php?topic=433522.600)

If there is a vulnerability, hopefully developers will look to it real soon, although the ECDSA is an integral part of bitcoin and the blockchain, and I see it as being very difficult to change, without something to revalidate all previous transactions.

Holy shit, thanks for sharing.!

LOL @ FUD :D

Why not quote the parts where a 50BTC reward was offered for proof (breaking any one of 200k addresses)... which they still haven't claimed. ::)

I think someone who can exploit this vulnerability will suddenly take an interest in more than 50BTC.

This problem is quite new, few days/hours old. If somebody couldn´t do it in the last 3 days, it doesn´t mean that it couldn´t happen ever.

Thanks for sharing this; will definitely be looking into this.

If there actually is a vulnerability here, you can be sure someone within the community will find it and will claim that bounty. So far I'm not worried and I think it's very likely to be a bug within the script they're running for that test.

How do you know that this particular person will have the morality to simply claim the 50 bitcoin bounty rather than using it to access 12 million bitcoins and cash out as many as he can without getting caught.

1. The condition for the reward is harder than the condition for the system failure - there are more than 200k addresses used and it is easier to find a collision in the whole bunch than in the chosen sliver.

2. As someone already said - if you have the means to cause collisions you can gain much more han 50BTC - so the 50BTC is not an incentive to stop doing it if someone knows how to do it.

I assume not only morally void people have the brains and means to find possible exploits. If there is a vulnerability it will probably not be found by just one person who can either decide to do the right thing and claim the 50 BTC bounty or hack multiple addresses (or both). Multiple people will find this exploit if there is one and I think it's quite reasonable to assume that at least one of them will be claiming that bounty.

This is all FUD. The parameters in the code EK wants you to use are like saying "pick an integer between 2 and 4 and I'll guess it in one guess"  Vs saying "pick an integer between one and a trillion and I'll guess it in 1 guess."

Just like with the android PRNG bug, if you limit the search space you can easily search it. It is self evident. There is a good thread in the tech and dev section which details why it isn't an issue unless you use bad (or limited) code to generate keys.

That's what I suspected. These code newbies don't know shit about PRNGs. Nevertheless, I've lately started to use http://random.org to influence the seed for my random number generators in security critical infrastructure.

Exactly.
For those who don't quite grasp the technology: This "vulnerability" has been and will always be there. Address collision is just very very very very unlikely unless the random number generation of the code is predictable (or you create your own private key from some phrase/input without using some form of salt to modify it).
If you are really paranoid just split your holdings into many wallets that were created with code that provides good random numbers.
In the unlikely event that you are one of the most unlucky beings in the universe and suffer from a collision at least you only lose a fraction.

A 1 second google search threw up this QA : http://bitcoin.stackexchange.com/questions/22/is-it-possible-to-brute-force-bitcoin-address-creation-in-order-to-steal-money

A rational actor should do exactly as you suggest. The grandparent here is overlooking the fact that by compromising the protocol you compromise the value of any bitcoin obtained by using the exploit.

Whilst this is not a guarantee - criminals iz stoopid after all - it's a fairly 'self healing' process. 50BTC is not to be sniffed at thesedays.

Bottom line, bitcoin was designed to be cracked. Price won't change from a collision here and there.

These collisions are unavoidable due to the nature of multiple access electronic networks?

I looked at the code and i agree.

Python is used, specifically the random.randrange() function. No secure seed is given, so it defaults to time.time(), this basically is the timestamp in full seconds.
Result:
This function alone will yield in 2592000 (4 weeks of seconds) possibilities in stead of 2^256.
1.000.000 of these calculations per second (1Mhs) results in a collision roughly every 2.6 seconds. And this is with just one process running.

No worries here.

-Alex
Security specialist

No, those collisions are unavoidable because of the way you generate your private/public key.
There is no authority issuing you address 1,2,3,....n with the corresponding key. You yourself ( well more likely your software although you could run the algorithm on paper or in your head) are creating the pairings.
Now the address space to choose from is very large, in fact you could give each atom on this planet its own address if you wanted and still have more than enough left [edit] While the private key is 2^256 bit which would fit the approximate 2^166 bits needed to address each atom the corresponding public address derived ( 2^160) does not quite cover it [/edit]

So simply choosing a random number for generating this will be sufficient. This way there does not need to be any authority that creates them and hence knows the private key.

On the other hand if everyone comes and chooses a number between 1 and say 1 million then you are reducing your previous large address space to that of effectively 1 million
In a sense this also happens if your (pseudo) random  number generator becomes predictable. Say you use the current time as an input to generate a random number.
If i know the day you created that random number and the algorithm were to only rely on the current time and nothing else to generate random numbers I can try through the very limited time-space of that day to try and figure out what "random number" you used.

In fact I believe the NSA compromised a standard method on random number generation so that it would produce predictable results and allow them to take advantage of that

[edit]

here is the description of how the address is derived: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
The RIPEMD-160 hashing step reduces the possible address space to 2^160 bits
[/edit]

Thank you!

Put all your btc in dogecoin.

there have been some good posts in this thread, and some of the best have been deleted, but it seems to me the only way for this problem to even exist is to use a program that does not generate the hash from a actually random set of variables. if something as silly as a time stamp is used as a seed thats dumb as fuck. I seem to remember mine being generated by filling a huge box with text at random by bashing my keyboard followed by having a moving my mouse all over the screen. that compared to a timestamp that can be guessed by a hacker within 2 hours doesnt even seem like a flaw in bitcoin, more of a flaw in the wallet design a few people choose to use.... nothing to see here...    correct me if im wrong tho please,

No, that's exactly what it going on. i.e., if you publish your private key on the web, or describe how you generated your private key, there's not much difference. True that there is alot of different software generating PKs nowadays, this could be a good test to find weaklings.

in this  thread (https://bitcointalk.org/index.php?topic=421842.0) gmaxwell set a bounty of 50 BTC (https://bitcointalk.org/index.php?topic=421842.msg4809012#msg4809012) for Evil-Knievel, or anybody else interested, in case
they will be able to provide the discrete log of at least one of a set of 200K randomly generated
secp256k1 public keys.


if you're interested in understanding why this is not a "vulnerability" just read further the
aformentioned thread.

 

they'd have better luck taking a dictionary and trying automatically picking brain wallet combos; took me all of 15 seconds manually to find a funded one. never underestimate the power of math and human stupidity ;) owner of 16QApoZYFdZzhETsNwvJNdfvKpAukTxzs9 PM me with passphrase you used and promise to never ever make brain wallets and I'll send 0.7 mBTC back just because we think alike.

Bruce Schneier has long written that the probability is unacceptably high that the NSA has installed a PRNG backdoor in the widely accepted SHA-3 standard protocol for cryptography (which NIST grudgingly accepted only with a footnoted caveat that one might prefer to use a more efficient alternative).  If such a backdoor exists (which seems nearly certain to me), the NSA can rather easily crack into any level it chooses of such encryption, and that means virtually all the BTC and altcoin protocols - which would be the rather instant death of such cryptocurrencies.  Is Quarkcoin the only alternative cryptocoin that claims it does not use the tainted PNRG? ???

...unless that is, in 2005 the NSA installed a PRNG backdoor in the AES-256 SHA-3 "NIST-approved" protocol for encryption, as Bruce Schneier et al. have shown long ago is highly probable.

pit pat piffy wing wong wang  ;D

Of course you did know that the public/private key algorithm used in bitcoin is ECDSA (https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm)
and this was just a fun fact  ::)

So Schneier explicitly says he DOESN'T think there's a backdoor in SHA-3. WTF you talking about.

What's more, a SHA exploit does not allow anyone to steal coins, it only affects mining. ECDSA is what protects transaction signing and thus the coins. AND even if that were broken you still couldn't steal coins from addresses which had never been spent from, because you don't know the public key.

No, Schneier here was referring to the more recent NIST fumbling with the arguably inappropriate changes of the "winning" Keccak hash variation, not a backdoor.  Schneier's far more serious concern has long been that expressed in "Did NSA Put a Secret Backdoor in New Encryption Standard?" by Bruce Schneier, 
Wired News, 
November 15, 2007:

"But one of those [NSA PNRG] generators -- the one based on elliptic curves -- is not like the others. Called Dual_EC_DRBG, not only is it a mouthful to say, it's also three orders of magnitude slower than its peers. It's in the standard only because it's been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute.

The NSA has always been intimately involved in U.S. cryptography standards -- it is, after all, expert in making and breaking secret codes. So the agency's participation in the NIST (the U.S. Commerce Department's National Institute of Standards and Technology) standard is not sinister in itself. It's only when you look under the hood at the NSA's contribution that questions arise.

Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn't large enough to make the algorithm unusable -- and Appendix E of the NIST standard describes an optional work-around to avoid the issue -- but it's cause for concern. Cryptographers are a conservative bunch: We don't like to use algorithms that have even a whiff of a problem.

But today there's an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor."
 
If Schneier et al. have ever changed their view on the PRNG Backdoor or expressed regret on their somewhat hedged probabilistic/weakness interpretations, I've never seen it in print and would appreciate any citation of such.

As Schneier has said, only a new Church Committee will ever reveal convincing truth and reform, and until such time it seems only fools use AES-256 without an open, proven, fully disclosed PRNG alternative to Dual_EC_DRBG (e.g.Twofish) and that it's possibly risky to use the NIST-Keccak hash variation rather than a similarly reliable hash, e.g. SKEIN.

Sorry but your posts scream FUD all over the place.

A vulnerability in the way random numbers are generated does not mean that ECDSA itself is broken and if you can understand the papers you are referencing then you know this.

As PirateHatForTea states this is virtually a non-issue because any wallet software that generates private keys without additional randomness through mouse movements, dice,garbage keyboard hits or any other external source is, quite frankly, shit and should not be used.

In terms of mining this vulnerability also makes no sense at all. Being able to narrow down the range of the input so you can try to guess and break the hash does not mean you can alter the number range of the output hash.
There would only be a problem in mining if you could break the numeric distribution of hashes in a way that reliably produced hashes in the target difficulty range.

You've responded to NONE of the points made by Schneier et al. and have disingenuously brought up straw dogs that have never been mentioned. FAIL, re-enroll logic class.

Bye.