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

[phr33]

Naw - this invalidates the searches I made earlier. Not that it would have helped as it sounds like the salt mod is difficult to guess.

Seems like we are all helping each other out (in true Christmas spirit!) so I reveal that I use JohnTheRipper to get 10k+ passwords/sec per core. You can't use it out of the box, but you will find a special modded version helpful for GPG  

We're playing n equal grounds here so I'd say let out the 3rd hint at 100 verifications! We need it!

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.

[K1773R]

Naw - this invalidates the searches I made earlier. Not that it would have helped as it sounds like the salt mod is difficult to guess.

Seems like we are all helping each other out (in true Christmas spirit!) so I reveal that I use JohnTheRipper to get 10k+ passwords/sec per core. You can't use it out of the box, but you will find a special modded version helpful for GPG  

We're playing n equal grounds here so I'd say let out the 3rd hint at 100 verifications! We need it!

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.

care to share jtr for GPG?

[phr33]

I think JohnTheRipper can run using opencl. At least experimental. I sold off all my GPUs a coulpe of months ago so I can't try it out though.

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.

[phr33]

care to share jtr for GPG?

Google is your friend!

But, what the h-ll... It's Christmas, right?
http://www.ubuntuvibes.com/2012/10/recover-your-gpg-passphrase-using-john.html

[K1773R]

care to share jtr for GPG?

Google is your friend!

But, what the h-ll... It's Christmas, right?
http://www.ubuntuvibes.com/2012/10/recover-your-gpg-passphrase-using-john.html

i didnt google to be honest as i asked for what solution hes using, well i guess its going to be the same. ty anyways

[BkkCoins]

Well, it is Xmas and I doubt I'm going to see this thru to the end anyway - so here's my Xmas gift...

( I tried to give the clue nasty before above!)

See nasty for C code to adapt below. If I decide not to bother then I'll give up my enhancements to nasty to let others play. I've added code to do the salt pattern and hashing and allow selecting a gpg key when it's not the default one on the keyring. I may alter it to support multiple threads if it proves not too hard, or perhaps a start pwd value so I can split it onto multiple machines each doing some range.

http://www.vanheusden.com/nasty/

(Note he states this could be 100x faster if done differently. I gather he's talking about using underlying decrypt code and testing per byte so it can be cut short sooner. But I have not looked into that.)

I guess I should be looking for jtr as well.

edit: Found. nice. even supports GPUs, will test that now...

[phr33]

care to share jtr for GPG?

Google is your friend!

But, what the h-ll... It's Christmas, right?
http://www.ubuntuvibes.com/2012/10/recover-your-gpg-passphrase-using-john.html

i didnt google to be honest as i asked for what solution hes using, well i guess its going to be the same. ty anyways

Yep - That's what I'm using

[cedivad]

I would like to get into this but i'm GPG ignorant to the point that i dont ven know what command to launch to verify if a guessed password will open it. I think to have understood that he used the private key he posted to encrypt the secret, but how did he encrypt the private key?
:/

[phr33]

edit: Found. nice. even supports GPUs, will test that now...

Nice! I blame myself for not keeping at least on GPU to play with opencl with. Just out of curiosity, could you post the speeds you get with a GPU cracking GPG?

Just let me know if you need any help with building etc.

Thanks!

[CIYAM]

...but how did he encrypt the private key?

The GPG private key was of course encrypted by GPG itself (using standard settings) with a password that is actually an SHA256 hash (as hex) - the script shown in the OP was what I used to convert a 4 character password into the hash (with the key point that I modified a line of the script that adds "salt" to the weak password to strengthen it before hashing).

I have put the script into a "code block" in order to make the OP clearer (the script itself was unchanged from that in the original OP version).

[K1773R]

edit: Found. nice. even supports GPUs, will test that now...

Nice! I blame myself for not keeping at least on GPU to play with opencl with. Just out of curiosity, could you post the speeds you get with a GPU cracking GPG?

Just let me know if you need any help with building etc.

Thanks!

john supports OpenCL and CUDA, altough only some hashalgos/implementations, GPG not (as far ive read) yet.

[phr33]

...but how did he encrypt the private key?

The GPG private key was of course encrypted by GPG itself (using standard settings) with a password that is actually an SHA256 hash (as hex) - the script shown in the OP was what I used to convert a 4 character password into the hash (with the key point that I modified a line of the script that adds "salt" to the weak password to strengthen it before hashing).

I'm sure you are all aware, I just like to point out that the security of any real crypto system never should rely on the secrecy of the salt or key derivation function. It should be based on the secret key only. But in this game we know that this secret key is weak and the main problem is the unknown parts of the key derivation function a.k.a. security by obscurity.

So in a cryptographic sense the salt does not add any strength.

[K1773R]

...but how did he encrypt the private key?

The GPG private key was of course encrypted by GPG itself (using standard settings) with a password that is actually an SHA256 hash (as hex) - the script shown in the OP was what I used to convert a 4 character password into the hash (with the key point that I modified a line of the script that adds "salt" to the weak password to strengthen it before hashing).

I'm sure you are all aware, I just like to point out that the security of any real crypto system never should rely on the secrecy of the salt or key derivation function. It should be based on the secret key only. But in this game we know that this secret key is weak and the main problem is the unknown parts of the key derivation function a.k.a. security by obscurity.

So in a cryptographic sense the salt does not add any strength.

the salt is what we have to "crack" unlike otherwise the pw

[phr33]

the salt is what we have to "crack" unlike otherwise the pw

Yes - we are lucky that it's not that hashing or encryption algo that is the target!

[phr33]

Wow, didn't realize we are at 97 confirms already! I guess I'll be home when we hit 100 and will give my scripts a go if we get "a really good hint".

[K1773R]

Wow, didn't realize we are at 97 confirms already! I guess I'll be home when we hit 100 and will give my scripts a go if we get "a really good hint".

what kind of CPU are you using for 10200h/s? which clock?

[phr33]

what kind of CPU are you using for 10200h/s? which clock?

That's a good 'ol i5 2500k @ stock clock. I compiled jtr with 'make linux-x86-64-native'.

In some of my later runs I saw the speed drop to ~10'000. Not sure if the 10'200 was a glitch or my box just was a bit more busy with other crap during the later run. But the whole key space took about 22 minutes so the speed is there somewhere.

::EDIT
62^4 / 10'200 = 1448 s = 24.1 minutes
62^4 / 10'000 = 1478 s = 24.6 minutes

So acctually the average speed must have been like 11'100 /s

[K1773R]

what kind of CPU are you using for 10200h/s? which clock?

That's a good 'ol i5 2500k @ stock clock. I compiled jtr with 'make linux-x86-64-native'.

In some of my later runs I saw the speed drop to ~10'000. Not sure if the 10'200 was a glitch or my box just was a bit more busy with other crap during the later run. But the whole key space took about 22 minutes so the speed is there somewhere.

r u sure u get 10k? i got a 2700k OC at 5GHz, and i only get 7500! compiled the same way lol

[phr33]

what kind of CPU are you using for 10200h/s? which clock?

That's a good 'ol i5 2500k @ stock clock. I compiled jtr with 'make linux-x86-64-native'.

In some of my later runs I saw the speed drop to ~10'000. Not sure if the 10'200 was a glitch or my box just was a bit more busy with other crap during the later run. But the whole key space took about 22 minutes so the speed is there somewhere.

r u sure u get 10k? i got a 2700k OC at 5GHz, and i only get 7500! compiled the same way lol

Oh my. Well yes I'm pretty sure. An obviously I use dictionary mode to cope with the custom key derivation function...

[K1773R]

what kind of CPU are you using for 10200h/s? which clock?

That's a good 'ol i5 2500k @ stock clock. I compiled jtr with 'make linux-x86-64-native'.

In some of my later runs I saw the speed drop to ~10'000. Not sure if the 10'200 was a glitch or my box just was a bit more busy with other crap during the later run. But the whole key space took about 22 minutes so the speed is there somewhere.

r u sure u get 10k? i got a 2700k OC at 5GHz, and i only get 7500! compiled the same way lol

Oh my. Well yes I'm pretty sure. An obviously I use dictionary mode to cope with the custom key derivation function...

i use a previously generated wordlist (generated by a tool i wrote), how r u using the dictionary mode?