Solve a riddle, guess a 4 char password and add 10 BTC to your xmas... SOLVED!!

[K1773R]

I used "vanitygen" to create the address so am pretty certain that the encrypted content would start with:

Privkey:5

so password is in the following format?

Code:

Privkey:${privkey}

if so u should have told us earlier, we'r all searching for a real privkey.

I was answering a question about what the *decrypted content* of the GPG message looks like (not about the "salt" formatting - only the "hints" that I give out are directly about that).

sry didnt read the full post (in a hurry).

[CIYAM]

sry didnt read the full post (in a hurry).

No worries at all - now > 60 confirmations and funds are still seemingly safe.

[kyotoku]

check the reward status here
http://blockchain.info/address/1CpueVNsEWgEhGD44ymVNoksyFp9Eekec7

[Red Emerald]

Interesting puzzle. "(at least)" isn't giving me any great ideas tho.

[CIYAM]

Interesting puzzle. "(at least)" isn't giving me any great ideas tho.

Well the next hint (if it's still unclaimed after 100 confirmations) should make it dramatically easier (as I am not going to let this drag out for too long).

[BkkCoins]

Interesting puzzle. "(at least)" isn't giving me any great ideas tho.

Well the next hint (if it's still unclaimed after 100 confirmations) should make it dramatically easier (as I am not going to let this drag out for too long).

Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.

I'm only able to check about 264 pwds/sec on my laptop but I'm still seeing if there is a better method than I've found. I've modified a "found" program to brute force gpg. If I can improve this sufficiently then I may start an EC2 instance to go at it faster. I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge. Seems unsportsman-like.

[CIYAM]

Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.

...I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge....

Okay - assuming others feel the same then I won't make the next clue as revealing as I was going to (and any clue after that will not be released until the new year).

[K1773R]

Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.

...I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge....

Okay - if others feel the same then I won't make the next clue as revealing as I was going to (and any clue after that will not be released until the new year).

perfect

[K1773R]

Interesting puzzle. "(at least)" isn't giving me any great ideas tho.

Well the next hint (if it's still unclaimed after 100 confirmations) should make it dramatically easier (as I am not going to let this drag out for too long).

Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.

I'm only able to check about 264 pwds/sec on my laptop but I'm still seeing if there is a better method than I've found. I've modified a "found" program to brute force gpg. If I can improve this sufficiently then I may start an EC2 instance to go at it faster. I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge. Seems unsportsman-like.

C code?

[kyotoku]

264 pwds/sec!

At 12 pwds/sec, I see that I still have a lot of work to do... good night

[BkkCoins]

Interesting puzzle. "(at least)" isn't giving me any great ideas tho.

Well the next hint (if it's still unclaimed after 100 confirmations) should make it dramatically easier (as I am not going to let this drag out for too long).

Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.

I'm only able to check about 264 pwds/sec on my laptop but I'm still seeing if there is a better method than I've found. I've modified a "found" program to brute force gpg. If I can improve this sufficiently then I may start an EC2 instance to go at it faster. I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge. Seems unsportsman-like.

C code?

I thought I was the one coming from behind as right now I'm on a measly Core2Duo laptop, and only using one thread. I wanted to adapt the code for sha256 and then add multi-threading, and then finally get it running on a faster computer. The salting algorithm can be "trial by hand" as a 4-char cycle is still about 15 hours for me. If I can get it to < 1 hour then I'd add reading a salt template from a file.

I'll not give my own code mods but for starts: I'm nasty and google is your friend.

You'll want to install the gpgme library, (sudo apt-get install libgpgme11-dev)
and even after that do some reading before you can compile due to large file support.

This way works but I'm by no means certain that there isn't some much faster method.

BTW: A word of warning, don't pump gpg with pwds without disabling the gpg-agent first. I got into a real pickle when the agent popped up with a "safe pwd window" for each password attempt. Ouch. But fast fingers with exiting the terminal actually worked. You can set the env variable to prevent that... eg.

GPG_AGENT_INFO='' myhackingprog

<sigh>This is what happens when you're an amateur.

[K1773R]

Interesting puzzle. "(at least)" isn't giving me any great ideas tho.

Well the next hint (if it's still unclaimed after 100 confirmations) should make it dramatically easier (as I am not going to let this drag out for too long).

Why not? You stated before you wouldn't empty the address until Jan 3rd. It takes time to figure out best ways to approach this and then implement. If you are attempting to evaluate the security model it seems counter-productive to cop out by reducing the difficulty too soon.

I'm only able to check about 264 pwds/sec on my laptop but I'm still seeing if there is a better method than I've found. I've modified a "found" program to brute force gpg. If I can improve this sufficiently then I may start an EC2 instance to go at it faster. I'd hate to spend too much effort and then just have you void it all by giving it away or closing the challenge. Seems unsportsman-like.

C code?

I thought I was the one coming from behind as right now I'm on a measly Core2Duo laptop, and only using one thread. I wanted to adapt the code for sha256 and then add multi-threading, and then finally get it running on a faster computer. The salting algorithm can be "trial by hand" as a 4-char cycle is still about 15 hours for me. If I can get it to < 1 hour then I'd add reading a salt template from a file.

I'll not give my own code mods but for starts: I'm nasty and google is your friend.

You'll want to install the gpgme library, (sudo apt-get install libgpgme11-dev)
and even after that do some reading before you can compile due to large file support.

This way works but I'm by no means certain that there isn't some much faster method.

BTW: A word of warning, don't pump gpg with pwds without disabling the gpg-agent first. I got into a real pickle when the agent popped up with a "safe pwd window" for each password attempt. Ouch. But fast fingers with exiting the terminal actually worked. You can set the env variable to prevent that... eg.

GPG_AGENT_INFO='' myhackingprog

<sigh>This is what happens when you're an amateur.

i used "--no-use-agent --homedir" with homedir pointing to a special folder only for this.
till date i dont have it implemented in C, gonna do that later.

[CIYAM]

Am very appreciative of the effort being put into this and am guessing that unless there is a hacker with a lot of free computing power it will be very much a case of luck with the "riddle" at this stage (and as promised the next hint won't really make much difference).

[K1773R]

Am very appreciative of the effort being put into this and am guessing that unless there is a hacker with a lot of free computing power it will be very much a case of luck with the "riddle" at this stage (and as promised then next hint won't really make much difference).

computing power isnt the problem atm, its the salt.

[BkkCoins]

Just wanted to double check the script you listed above is "as used". I noticed that by default the echo command will add a newline (\n) to the salted pwd. So the hash would include the "hidden" newline. I was testing my C code and found that the libcrypto (openssl) does not add a newline when doing sha256 (of course). So then I thought what if, even through good intentions, you maybe generated the has differently not realizing that a newline was/wasn't added.

tldr; just checking the salted pwd would indeed have that newline on the end...

[CIYAM]

As the password was put onto the clipboard (at the end of the script) and then later "pasted" into the password prompt from GPG the LF is not actually *in* the actual hash that was used.

[K1773R]

As the password was put onto the clipboard (at the end of the script) and then later "pasted" into the password prompt from GPG the LF is not actually *in* the actual hash that was used.

you misunderstood him.

Code:

password=`echo $password | sha256sum`

this pipes the password to sha256sum and adds \n at the end, so yes u have to put \n at the end when brute forcing.

[CIYAM]

you misunderstood him.

Code:

password=`echo $password | sha256sum`

this pipes the password to sha256sum and adds \n at the end, so yes u have to put \n at the end when brute forcing.

Oh I see - sorry about that - that was an unintended extra complication.

[K1773R]

you misunderstood him.

Code:

password=`echo $password | sha256sum`

this pipes the password to sha256sum and adds \n at the end, so yes u have to put \n at the end when brute forcing.

Oh I see - sorry about that - that was an unintended extra complication.

no problem, would be boring if its easy

[BkkCoins]

you misunderstood him.

Code:

password=`echo $password | sha256sum`

this pipes the password to sha256sum and adds \n at the end, so yes u have to put \n at the end when brute forcing.

Oh I see - sorry about that - that was an unintended extra complication.

no problem, would be boring if its easy

Ya, would be a real bummer if I worked everything out and actually had guessed the salt pattern right but still was getting wrong hashes to test in gpg. Now I've got my C code to work, using openssl for hashing, and for some reason it actually runs faster with hashed pwds than when I tested with 4 char plain pwds. 300 pwd/s vs. 260 pwds/s. Weird. Anyway, I'm fairly sure now it's doing the right work and now it's just a matter of trying different salt patterns (and waiting for each full cycle). It currently cycles thru every 4 char pwd combination.

I'd love to find a way to push the gpg key decode test onto a GPU. If it could get even close to vanitygen speed then it would takes a few seconds to test each salt pattern. Hence, the security of this method depends on the gpg key decode algorithm not being ported to GPU.