Bitcoin Forum

It's also encrypted with an XOR one-time pad on linux using /dev/urandom:

http://sprunge.us/FDGR


If someone cracks it, all I ask is you tell me how you did so.

Looks, thinks for a second, fuck it.

Is that a "fuck it, i can't do this?" or a "fuck it, i'll crack it" ?

didn't even look at it, I pass

Its a Fuck I would rather get hit by another hurricane and lose power for 3-4 days then even try.

No thanks.

If I'm going to turn random data into a wallet, I'd rather turn it into the mybitcoin scammer's wallet. Then I'd have sooooo many coins. :)

(If you don't get how that makes logical sense go read up on OTPs...)

If that file you posted is XOR'd with data from /dev/urandom, I think your /dev/urandom is broken.

There is a weakness in it, i'm not going to reveal it - want to see if anyone in this community spots it.

A professional cryptographer would spot it in seconds.

Do tell!
Have you found the weakness?

The file is just a PNG of some kind of masonic symbol.

With the right key of course it is ;)

But that's not the point here

I guess the only thing i can think of is that urandom is not as good as random.
As in it might just use a seed number. Also he appears to have limited his characters to printable stuff?

I see it as well.  Maybe I'll give it a go tonight if nobody else gets around to it.

It's base64 encoded silly.

Clue:
wallet.dat has structure and urandom is not truely random

Nevermind...   found 0.10 BTC.  Your urandom is certainly broken.  It wasn't XOR'd at all...

yea.. i was hoping to correct my post before someone quoted me..
and b64decode seems to have trouble with it on fbsd. no begin line. i will google.
ah.. -r fixed that issue.. but it seems i am too late.

But I am very curious what the solution was.

LOL

Well done, for the record here's the correct one:
http://sprunge.us/PcLi

*That* looks better.  Now let's take a look...  :D

You have the plaintext, don't do the obvious to crack it

Oh, if you crack the correct one i'll send 1BTC to the address in the wallet

Oh.  For some reason I was thinking that he posted a 2nd one (like the first one was just a teaser).

Are they two separate wallets, then?

No, hence my request that you not do the obvious to crack it.
Tell me how to crack it without having the plaintext and i'll send you 1BTC.

I think I am a bit confused now.

The first was simply based64 encoded. The person who won decoded it and earned the btc.

Now you have a second file which when decoded is obviously not a wallet.dat file straight away.

Is this the same wallet.dat file but encrypted with a one time pad using urandom?

Well...  If urandom was used, it's certainly possible to crack (especially since the header of the file is the same between wallets).  That'd give you some possibilities of where the seed started.  However, it seems that different versions of Unix/Linux/BSD have different implementations of pseudo-random number generation.  We could go through them all, I guess...

I was thinking that also. Freebsd does not even have urandom.. it just:

> ls -al /dev/ | grep ran
crw-rw-rw-   1 root     wheel       0,  11 Sep  8  2009 random
lrwxr-xr-x   1 root     wheel            6 Sep  8  2009 urandom -> random

To win the bounty you must present an algorithm.
The kernel version: 2.6.32-5

By the way, after this one is cracked the next bounty will be 10BTC for one encrypted using the REAL entropy source.

And when someone earns the bounty, everyone with the base64-decoded version tries spending the bounty first. :)

No, because the next bounty will be in a new wallet - only the one who cracks it will get it.
For this one, i'll send the 1BTC when the winner agrees - they can then pay it out themselves to ensure it doesn't get stolen - plus it'll be fun to watch that bit anyway ;)

I am sitting here thinking what would he use for the seed value... his bitcoin address? his username?
There must be a clue I am not thinking of in his posts. To sit here and try to brute force it does not
seem like a valid plan of action.

What would I use?
I use whatever the hell last went into the kernel entropy pool - and trust me, it's cycled a lot ;)

I'll help you all out.
It was somewhere between 128 and 190 bits long.

That's about as useful as the United States Congress.

It's all I know based on how much entropy that box drains.