How do I get an encrypted wallets' password hash?

[strictlyfocused]

Like an idiot I forgot my encryption password for my wallet. I was hopping to use Rainbowcrack with some popular rainbow tables to try and recover the password but Im not sure how to go about finding the password hash for my wallet. Anyone know how I can get it?

[1715136133]

1715136133

[1715136133]

1715136133

[1715136133]

1715136133

[etotheipi]

This is exactly why I keep an unencrypted backup on a CD/DVD or spare USB key I'm not using anymore.  Unless you're worried about someone physically breaking into your house and stealing the key, this will guarantee you can't permanently lose you wallet like this.

Btw, from looking at the source code, it looks like the key is actually created from applying someHashFunction^25000.  I'm not sure you'll find any rainbow tables for that.  

If I were you, I'd write down everything you think you can remember about your encryption password, and save it so that if you need to seek help figuring out the password, we can narrow down the search space.  Especially if it was a lot of coins and a long password.

[strictlyfocused]

This is exactly why I keep an unencrypted backup on a CD/DVD or spare USB key I'm not using anymore.  Unless you're worried about someone physically breaking into your house and stealing the key, this will guarantee you can't permanently lose you wallet like this.

Btw, from looking at the source code, it looks like the key is actually created from applying someHashFunction^25000.  I'm not sure you'll find any rainbow tables for that.  

If I were you, I'd write down everything you think you can remember about your encryption password, and save it so that if you need to seek help figuring out the password, we can narrow down the search space.  Especially if it was a lot of coins and a long password.

Thanks for the info! A bummer to hear that the hashing functions will probably prevent me from trying to run a rainbow table against it though :/

[DeathAndTaxes]

Look at it this way.  Encryption has no idea if it is being used for good or bad.

If you could easily find your missing password via brute force an attacker could just as easily find password of a wallet that isn't theirs.

Passwords which can be recovered via brute force aren't security.

[etotheipi]

If it's a significant amount of BTC, someone on the forums might be willing to help you find the passphrase, for probably half of it.    If the alternative is abandoning the coins forever, I bet there's some folks who might consider helping. 

BUT this is only feasible if you have a significant recollection of what the passphrase might be.  If you know how many characters it is, but simply forgot a few letters, capitalization, punctuation, etc, it might be doable.  But having to do a "blind" search just isn't feasible.  The reason it's hashed 25,000 times, is so that an attacker trying to do the same thing will be 25,000 times slower than if they used single-hashing (that's an oversimplification, but you get the point).

So, if you tell us how much BTC is behind this wallet, and how far off you think you are from the password, you might get someone's attention and negotiate an agreement.  Similarly, you could post all the details here, and leave it as an open challenge.   Even if it's not "worth it" now, a future price spike in the BTC market might cause some folks (like myself) to revisit this thread later

EDIT: actually, that's a gamble... there's no guarantee they even give you back your half.  But again, if the alternative is losing them forever, anyway...

[Pieter Wuille]

The encryption format in the wallet was specifically designed not to be crackable through rainbow attacks, so I'm afraid you're out of luck.

[gmaxwell]

It should be possible to bruteforce the password however.  You can use john the ripper and tune it to the likely password you used (to cut down the amount of time on wrong guesses) you will just need some massive wordlists and experiment with what the exact command to execute is.

JTR does not support the algorithm we're using, though you could use it as a wordlist generating front end on your own implementation of it.

But you still won't get very far— Bitcoin's key strengthening takes 100ms per attempt on whatever computer you last changed the wallet pass-phrase on, with a minimum of 25,000 iterations (which was 100ms on 1.86 GHz pentium M).

Ten passwords per second per core is only attackable if you already basically know the password.

[DeathAndTaxes]

It should be possible to bruteforce the password however.  You can use john the ripper and tune it to the likely password you used (to cut down the amount of time on wrong guesses) you will just need some massive wordlists and experiment with what the exact command to execute is.

JTR does not support the algorithm we're using, though you could use it as a wordlist generating front end on your own implementation of it.

But you still won't get very far— Bitcoin's key strengthening takes 100ms per attempt on whatever computer you last changed the wallet pass-phrase on, with a minimum of 25,000 iterations (which was 100ms on 1.86 GHz pentium M).

Ten passwords per second per core is only attackable if you already basically know the password.

Well you likely could GPU accelerate that and use multiple GPU but you are right even 1000 pwd/s is going to be next to impossible unless you are trying a very small word list (like you know the exact phrase but forgot the caps & punctuation changes).

[gmaxwell]

Well you likely could GPU accelerate that and use multiple GPU but you are right even 1000 pwd/s is going to be next to impossible unless you are trying a very small word list (like you know the exact phrase but forgot the caps & punctuation changes).

Space was set aside so that it could be switched to scrypt, it only didn't start out that way because of some reasonable conservatism in selecting the functions in use and scrypt is unproven though conceptually better for the reason you gave.

(The wallet encryption currently uses SHA-512 inside the iterated strengthening function now,  one reason this was done instead of SHA-256 is because even if we weren't going to switch to something costly to accelerate using the exact same algorithm that the bitcoin community has spent so much effort GPU optimizing seemed unwise)