Topic: 10 BTC 4 U 2 STEAL - Protected by a weak 5-letter password - crack & it's yours! - page 6. (Read 20210 times)

This pretty much sums up why I'm not motivated to try to find the password.

Ahh, your right, tried it again. Must have hit the up key instead of the down xD

Unrolled a few loops, down to 18 days...

That's funny given those odds compared to the odds of guessing the correct phrase.

I don't think so.  I tried it and it didn't work.  But if it did, it would be an INCREDIBLE coincidence, given that the "passphrase incorrect" message comes from a mismatch of a 32-bit hash.  Odds of a collision on any given string are 4 billion to 1.

Down to about 21 days now with the hints given and a few tweaks....

Yeah, it also decrypts with CaSaS, but to the wrong Address.

I bet the password is "Coinz" but too lazy to check it. 

I am guessing that'll be divided by 32 in a matter of hours, or is this already factored in to your calculation?

The difficulty keeps going down the more I divulge about the password, so the person who has built the most effective cracking solution (and/or gets the luckiest) when I give just enough information to put it within reach will claim it.

Well Mike has already given 1.142 bits of information and will give 4.858 more soon, this already cuts your runtime to 2 days. Go for it.

Keep in mind that "36 years" became "12 years" just by taking the same code and running it in "release" mode instead of "debug" mode, without making a single change.  (3 seconds per try became 1 second per try)

Unrolling the loop as suggested by Enquirer should make a pretty decent dent

And when I give away the capitalization, 12 years gets chopped by a factor of 32 to under 4.5 months, assuming no code changes (not even the loop unroll).

At some point I'll have given enough bits away that some enterprising person discovers they can throw the problem at some Amazon compute time for five bucks and solve it.

In the end, I think we'll all draw the conclusion that if you print yourself a bunch of 1 BTC notes while keeping a backup copy at home, and put even a simple password on them ("foofoo"), usability is hardly impacted (assuming redeeming them is ubiquitous), but you are pretty much totally protected if the things get lost or stolen.

Meanwhile, I "owe" BTC to a few people (really, what this means is I told them about bitcoins and they asked me to buy some and hold them for them...mostly friends and family).  Passworded paper wallets mean that I can give or mail them their own bitcoins without asking their permission or putting them at a risk of theft, then tell them the password, which I will have chosen as something I know is memorable to them but hard to guess.  I keep a copy of the notes somewhere safe, and the end result: they have the option of spending their money like money at some point in the future without needing to ask me for it, and they can stop thinking of it like a stock.  Meanwhile, I still retain the ability to act on their bitcoins if they need me to, but can also forget that I "owe" them anything.

My implementation would ONLY take 125 days to attempt all combinations, much faster than the 36 years... but still not doable for the amount of BTC!

ya its not trivial, a days work to rewrite it in C, only to find out it would take 18years

I think Mike will need to give hints

but lets just wait and see.

I will give away the capitalization of the letters of the password sometime between 0:00 UTC and 2:00 UTC December 3, 2012 (that's tonight my local time between 5-7pm Mountain US).  More likely toward the beginning of the time window (I am just giving myself room to be late just in case I'm like driving or something).

I will also give this right now: the capitalization is NOT "aaaaa", nor "Aaaaa", nor "AAAAA".

I will give away one more "bonus bit" of information right now: the first letter falls within the second half of the alphabet (N-Z or n-z).

To me, most likely scenario is you clicked the button to generate a brand new key, and imported it.

Of course it will import, and it will have no money on it.

Successful decryption of the private key means coming up with a private key that evaluates to the same address on the original note.

Then Mike has a bug on his software, because Steal did decrypt the private key to a valid one, allebeit a different address.
Let me go to laptop and I'll tell you to which address lol

EDIT: This is strange, but now it says The Passphrase is Incorrect.
But it did give me a valid Private Key and Address, because I've even imported it to my MtGox account.
No, I didn't save it, so I can't say which address or privatekey it was and there's no way on MtGox to see it.
Maybe a glitch from running Mike's tool on Ubuntu. Or a glicth on my fingers and I clicked the wrong button?

No, this code generates new keypairs unrelated to the one in the note. You want to loop the code in btnPrivWIFToHex_Click (in Form1.cs), with the encrypted key for txtPrivWIF.Text and different password values for txtPassphrase.Text.

 
I don't understand very much, but we have to search for all combinations looping this piece of code?
How can we arrive at the public key if random keys get encrypted with the password?      

Presumably it was a joke, the password is neither Steal, STEAL nor steal. And as you can see, the coins are still unclaimed.

Yes, that's it.
If you wanted to try that 380204032 times.
The dude cracked it by thinking like Mike