Quote from: madmadmax on June 11, 2014, 01:11:26 AM

Quote from: jonald_fyookball on June 11, 2014, 01:07:02 AM

Quote from: DannyHamilton on June 11, 2014, 12:44:15 AM

To steal any of my bitcoins through broken cryptography, you'd first have to completely reverse the RIPEMD-160 hash function to determine what SHA-256 result was used as its input. Then you'd have to completely reverse the SHA-256 function to determine what public key was used as its input. Then you'd have to solve the discrete logarithm problem for ECDSA with the Secp256k1 curve to find the private key.

Agree with your post Danny, but as academic discussion, are you sure this (quoted) is a precise way
to describe the cryptography?

My understanding was that the ECDSA is the critical piece here, not the SHA-256 hash.
For instance, if the k value is known (which would be a faulty implementation of ECDSA), then that is
all that's necessary to break the elliptic curve cryptography... (the SHA-256
doesn't matter, and you certainly don't have to reverse it).
Also, the first step in the DSA is: e=Hash(m), and I thought m is publicly known.

I could definitely be wrong though... thoughts?

It depends on whether someone has spent from that address once already or not, if he didn't then SHA-256 and RIPEMD-160 need to be broken as well.

Which is why I said "To steal any of my bitcoins". I use a new address for every transaction. As such, none of my bitcoins are associated with any addresses that have had their public key revealed.

Also, the k value will only be known in a faulty implementation of ECDSA. The discussion at hand is about a proper implementation of ECDSA where someone has found a shortcut to solve the discrete logarithm problem in years (or days, or hours). Certainly if someone (intentionally or accidentally) reveals private information, then bitcoins can be stolen.

The m value is only publicly known when the transaction is sent. At that point, the attacker needs to be able to calculate the private key before a miner (or mining pool) manages to confirm the transaction, and then they need to find a miner (or mining pool) that is willing to accept their replacement transaction in place of mine. This is why I limited the weakness to "hours". The function would need to be replaced before the weaknesses are advanced to the point where the calculation could be done in minutes.