3

I understand that the public key is kept hidden until a bitcoin transaction is made, at which point the public key has to be revealed to prove that you created the transaction with your private key. Until then, only a hash of your public key is ever shared, know as your bitcoin address.

Once my public key is known, would it be possible for someone to lookup my private key in a rainbow table ?

  • Such a rainbow table already exists at directory.io. ;) However, you'll find that the site is a tongue-in-cheek joke explained by Pieter's answer below. – Murch May 13 '17 at 19:38
  • Technically, directory.io is not a rainbow table as it computes the keys on the fly. It's close to impossible to store all keys in a table. – Waqar Lim May 29 '17 at 10:41
6

No.

A rainbow table is simply a memory-cpu tradeoff that allows you to find preimages of a function faster by having a precomputed table with some of the entries.

In order to construct a rainbow table for bitcoin private/public keys, you still have to first iterate through all the keys at least once. It doesn't matter that only part of the keypairs will end up in your rainbow table - you still have to go through all them.

That is an impossible task. There are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys to go through. To put that in perspective: if you would put a computer on every square micrometer of earth (1/1600th of the cross section of a human hair) that can compute as many public keys per second as the entire Bitcoin mining network does hashes per second at the time of writing (4 exahash/s), it would take you 120000 times the age of the universe to go through all keys.

And, even if somehow you had an oracle that could give you the rainbow table, it would need to be impossibly large to make cracking private keys practical. If your table had a trillion entries, it would only make cracking a trillion times faster. That's still utterly impossible.

  • 1
    High up in the north, in the land called Svithjod, there stands a rock. It is a hundred miles high and a hundred miles wide. Once every thousand years a little bird comes to this rock to sharpen its beak. When the rock has thus been worn away, then Pieter's computation will be complete. – Russell O'Connor May 12 '17 at 11:46
  • Yeah, but what if Bitcoin is around in 120000 times the age of the universe? I'm worried because we might have a dip. – Melbourne Developer Feb 19 '18 at 4:04
1

Thanks for the large bitcoin collider (LBC) link. Had a long look at it but it's way over my head. Seems they are finding private keys regularly that fit active accounts with some BTC on them. That's an an alarming sight. Especially since this is still running on a tiny scale.

Then I came across this excellent post: https://www.reddit.com/r/btc/comments/65mjm3/bitcoin_wallets_under_siege_from_collider_attack/dgbudsk/ As to why the LBC seems to have already found private keys to active accounts, he answered:

The wallets they've attacked so far are not generic random-private-key bitcoin wallets as the usual ones, but they've been specifically crafted to be broken. They belong mostly to the puzzle transaction which contains many "easy" private keys.

What does that mean?

I'm not entirely sure these are all talking about the same approach/problem, but I think it's similar in the end: How hard is it to find a private key to a specific active bitcoin address or any of the active bitcoin addresses? I hope dyoniziz from reddit is correct.

  • 2
    LBC will only ever find keys that were generated with insecure random number generators. Anything else requires astronomical amounts of computation power which the technology is designed to withstand, so don't let it scare you. – Pieter Wuille May 6 '17 at 2:11
  • Can you elaborate? I don't understand why keys generated with random number generators would be more likely to be found by the LBC? I thought LBC just goes through the possible keys methodically, from start to finish so to speak? – John May 7 '17 at 10:31
  • Things generated with insecure random number generators are easier to find by trying to mimick the algorithm they used. A good random number generator produces numbers that are indistinguishable from random, so every search pattern is as good as any other. And the key space is so massively large that it is impossible to ever hit one by chance again. – Pieter Wuille May 7 '17 at 16:06
  • @PieterWuille "it will only ever" – when they calculate for long enough, the will find everything. we will see how fast computing can be in our livetime and if bitcoin breaks over it. I also feel quite comfortable right now, but that can change, we have to face that. – vv01f May 12 '17 at 6:57
  • Good luck, then. – Pieter Wuille May 12 '17 at 7:30
-3

indeed that would theoretically be possible. such a table luckily is very large. for more read e.g. on the large bitcoin collider. if an active address means that is spends money, then the pubkey is revealed which makes it easier to attack. as long as an address only received money it is protected better by the 2nd hashing layer.

lbc can be ignored but they walk systematically through the keyspace from small difficulty to large by entropy. easy to find keys are just a bait to have more people involved. @Pieter: of course weak RNG is a problem, but that was not in question; we better get some open hardware standards for TRNG.

interestingly people vote this down. we have to face it: there are problems with the implementation of bitcoin apart from just scalability. the hashing was not well thought through and the ecc algo (Secp256k1: T=(p,a,b,G,n,h); a=0, b=7 … h=1. see slide by ruedi) got the parameter a nulled without any good reason (performace is not a good argument at all in means of crypto). cryptography does not honor weaknesses, small they may be.

  • No change to the hashing algorithm would make keys generated with an insecure RNG secure. I have no clue what ecc parameters you're talking about. – Pieter Wuille May 12 '17 at 6:06
  • @PieterWuille 1st nobody claimed, if so point me there plz, and 2nd you hopefully know. math is not secret: ruedi on 31c3; Secp256k1: T=(p,a,b,G,n,h); a=0, b=7 … h=1. – vv01f May 12 '17 at 6:45
  • Yes, a=0 is a conscious choice that makes certain operations faster. There are no known attacks against that choice. – Pieter Wuille May 12 '17 at 7:29
  • I know, you know, but is no good argument still. Go ask the cryptographers around, they will tell you like that one did if they are sane. Altering crypto-implementation for performance is simply one of the things you should not do if you have the choice. – vv01f May 12 '17 at 8:22
  • 1
    Nothing was altered. Secp256k1 was an elliptic curve standardized by the SECG before Bitcoin existed. Satoshi just picked one curve before EC was cool, and ended up picking a different standard than what the rest of world went with. It was an unusual choice at worst, but not a bad one – Pieter Wuille May 12 '17 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.