10 BTC 4 U 2 STEAL - Protected by a weak 5-letter password - crack & it's yours!

[Meni Rosenfeld]

The dude cracked it by thinking like Mike

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

[niooron]

 

Code:

if (txtPassphrase.Text != "") {     
                    SetText(txtPrivWIF, new Bip38KeyPair(kp, txtPassphrase.Text).EncryptedPrivateKey); //<-loop this?
                } else {
                    SetText(txtPrivWIF, kp.PrivateKeyBase58);
                }
                SetText(txtPrivHex, kp.PrivateKeyHex);
                SetText(txtPubHex, kp.PublicKeyHex);
                SetText(txtPubHash, kp.Hash160Hex);
                SetText(txtBtcAddr, new Address(kp, AddressTypeByte).AddressBase58);       

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?      

[Meni Rosenfeld]

Code:

if (txtPassphrase.Text != "") {     
                    SetText(txtPrivWIF, new Bip38KeyPair(kp, txtPassphrase.Text).EncryptedPrivateKey); //<-loop this?
                } else {
                    SetText(txtPrivWIF, kp.PrivateKeyBase58);
                }
                SetText(txtPrivHex, kp.PrivateKeyHex);
                SetText(txtPubHex, kp.PublicKeyHex);
                SetText(txtPubHash, kp.Hash160Hex);
                SetText(txtBtcAddr, new Address(kp, AddressTypeByte).AddressBase58);       

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?      

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.

[Raoul Duke]

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?

[casascius]

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?

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.

[casascius]

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).

[adamstgBit]

Is this going to require a lot of code to implement in C? I can probably do it, but I really don't want to bother if it's going to be a lot of code.

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.

[Shermo]

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!

[casascius]

Is this going to require a lot of code to implement in C? I can probably do it, but I really don't want to bother if it's going to be a lot of code.

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.

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.

[Meni Rosenfeld]

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!

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.

[casascius]

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!

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.

[Come-from-Beyond]

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

[Vorksholk]

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

[Shermo]

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

[casascius]

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

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.

[Elxiliath]

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

[Shermo]

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

[Vorksholk]

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

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.

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

[andrew12]

It would take 36 years to run on the slow C# crappy implementation of scrypt that I have bundled with my app.  Simply feeding the same input to a more efficient implementation should chop this figure down by orders of magnitude.

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

[picobit]

Found a scrypt implementation for Python written in C, so it should be pretty fast.  100 attempts in 52 sec on my Mac.  Still, that will take 44 days if I had 52 CPUs to run on.  Giving that I still have to implement all the rest of the BIP key decryption in Python (I planned to steal most of it from Armory), I doubt that I will be first to collect the price (and I don't have 52 CPUs to spare).  So I pass.  But it was fun to looking into this.