k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw: 91247 c/s real, 92160 c/s virtual now thats a NICE improvement  EDIT: 35 seconds for FULL scan brute forcing is faster than creating the wordlist, awesome  Those GPU sure can run! The issue I mentioned before was regarding the "trying: xxx" output. There is none in your new dump so I don't know if you fixed the problem or not. It looked like it only tried with half of the hash. just checked it, its the same for the GPU, do not ask me why! the wordlist hashes are right but the output isnt, did you run into this problem too? for the GPU it "looks" crazy too: guesses: 0 time: 0:00:00:35 DONE (Wed Dec 26 11:42:23 2012) c/s: 414364 trying: 7277b9b8b5034fc - eea8eca3d152537 and the hash from the hashfile is 7277b9b8b5034fc4e715be0e9e61bf3aac30cce46396a30b5272d89e19418a61, ah dammit! Yes - you need to modify jtr to use this long passwords how did you fix this? google results are unrelated to this problem (or atleast all i have read so far). good that i dont delete my wordlists so afterwards i can just recheck... |
|
|
|
Has anyone tried to use c to create the dictionary?
i do it in java with JNI mixed. What's your speed? It would take me something like 1 day to write the 14 million combinations there are... 2 seconds to create the wordlist (4 chars) 17 seconds to create all sha256 sums 1.5 seconds to write it down to disk (916MB) |
|
|
|
Has anyone tried to use c to create the dictionary?
i do it in java with JNI mixed. |
|
|
|
The implementation of SecureRandom is probably platform-dependant. Do we know the jvm/platform used to generate 1BTZ?
if it was a collision, win for sure  Not for sure. It's still possible there are some java runtimes out there that have insecure implementations of SecureRandom. maybe some old ass java. |
|
|
|
k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw: 91247 c/s real, 92160 c/s virtual now thats a NICE improvement EDIT: 35 seconds for FULL scan brute forcing is faster than creating the wordlist, awesome Those GPU sure can run! The issue I mentioned before was regarding the "trying: xxx" output. There is none in your new dump so I don't know if you fixed the problem or not. It looked like it only tried with half of the hash. just checked it, its the same for the GPU, do not ask me why! the wordlist hashes are right but the output isnt, did you run into this problem too? for the GPU it "looks" crazy too: guesses: 0 time: 0:00:00:35 DONE (Wed Dec 26 11:42:23 2012) c/s: 414364 trying: 7277b9b8b5034fc - eea8eca3d152537 and the hash from the hashfile is 7277b9b8b5034fc4e715be0e9e61bf3aac30cce46396a30b5272d89e19418a61, ah dammit! |
|
|
|
k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw: 91247 c/s real, 92160 c/s virtual now thats a NICE improvement Nice work! That should put you in the range were you can brute force quite a number of equation modifications. Have at it! just in case i find the privkey for the 10BTC, i gonna share a piece of it to the guys who helped. |
|
|
|
k1773r@COOLERMASTER:~/git/JohnTheRipper/src$ ../run/john -fo:gpg-opencl -t
OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Benchmarking: OpenPGP / GnuPG Secret Key [OpenCL]... DONE
Raw: 91247 c/s real, 92160 c/s virtual now thats a NICE improvement EDIT: 35 seconds for FULL scan brute forcing is faster than creating the wordlist, awesome |
|
|
|
The next hint will be a little more specific about the equation change - let me know how soon you think you need this hint (if no other consensus then I will be giving it at a 200 confirmations).
I can obviously only speak for myself, but I simply see too many possibilities to brute force at the moment. Or rather that I see no good way of automating the guessing of the equation modification. Replacing the "=" and "at least" with ">=" was the only logical change I could come up with. Next up is a ton of "two times %s..." etc. i already ran it with >= as single symbol. @BkkCoins il have to test that, didnt knew its alread working. EDIT: how did u get --format=gpg-opencl to run? i compiled the gpu john but it dosnt know this format :S EDIT2: nvm a make clean helped. |
|
|
|
i get a different outupt style from john:
"guesses: 0 time: 0:00:11:32 28.21% (ETA: Wed Dec 26 11:16:29 2012) c/s: 6016 trying: c6520e7584da05897a51081fcdfe7dc3"
which john version are u using?
i tested 1.7.9-jumbo-7+unstable [linux-x86-64-avx] and 1.7.9-jumbo-7+unstable [linux-x86-64-native]
Oh that does not look too good. Apart from the lower speed there's something not quite right. I'll let you think about it. There is not that much info in there so you should be able to find it rather quickly!  i can only think ur talking about the version, so again which version do you use? i got mine from github. The version number is fine unstable part? i tryd with the official jumbo release and it cant load the GPG stuff. |
|
|
|
So now the next hint (and as promised it should not make things too easy): somany possibilites is the equation true or false? |
|
|
|
i get a different outupt style from john:
"guesses: 0 time: 0:00:11:32 28.21% (ETA: Wed Dec 26 11:16:29 2012) c/s: 6016 trying: c6520e7584da05897a51081fcdfe7dc3"
which john version are u using?
i tested 1.7.9-jumbo-7+unstable [linux-x86-64-avx] and 1.7.9-jumbo-7+unstable [linux-x86-64-native]
Oh that does not look too good. Apart from the lower speed there's something not quite right. I'll let you think about it. There is not that much info in there so you should be able to find it rather quickly! i can only think ur talking about the version, so again which version do you use? i got mine from github. |
|
|
|
I have a couple of more CPU flags than you:
smx pcid x2apic and tsc_deadline_timer
But that should not cause any performance loss..
as i said, this is really wierd stuff going on... |
|
|
|
|
i get a different outupt style from john:
"guesses: 0 time: 0:00:11:32 28.21% (ETA: Wed Dec 26 11:16:29 2012) c/s: 6016 trying: c6520e7584da05897a51081fcdfe7dc3"
which john version are u using?
i tested 1.7.9-jumbo-7+unstable [linux-x86-64-avx] and 1.7.9-jumbo-7+unstable [linux-x86-64-native]
|
|
|
|
No, that's what I ment with dictionary mode. I did a new run and got ./john --wordlist=dict1.txt jtr.private.hash
and got guesses: 0 time: 0:00:23:34 DONE (Wed Dec 26 10:30:52 2012) c/s: 10446
damn! so u create a wordlist with the sha256sums too and the jtr.private.hash is made from gpg2john right? i dont get it why ur somuch faster :S flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid kernel: 3.0.0 Yep! I think you more or less have to as jtr won't mangle the password in this custom (and partly unknown!) way we need. And yes jtr.private.hash is the output of gpg2john. crazy, crazy. this is really wierd. |
|
|
|
No, that's what I ment with dictionary mode. I did a new run and got ./john --wordlist=dict1.txt jtr.private.hash
and got guesses: 0 time: 0:00:23:34 DONE (Wed Dec 26 10:30:52 2012) c/s: 10446
damn! so u create a wordlist with the sha256sums too and the jtr.private.hash is made from gpg2john right? i dont get it why ur somuch faster :S flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid kernel: 3.0.0 |
|
|
|
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? |
|
|
|
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 |
|
|
|
I looked at VanityAddress.jar: Random Key is generated in class VanityAddr using com.google.bitcoin.core.ECKey. import com.google.bitcoin.core.ECKey;
...
key = new ECKey();
ECKey constructor is implemented as: import java.security.SecureRandom;
...
private static final SecureRandom secureRandom = new [b]SecureRandom()[/b];
...
public ECKey()
{
ECKeyPairGenerator generator = new ECKeyPairGenerator();
ECKeyGenerationParameters keygenParams = new ECKeyGenerationParameters(ecParams, secureRandom);
generator.init(keygenParams);
AsymmetricCipherKeyPair keypair = generator.generateKeyPair();
ECPrivateKeyParameters privParams = (ECPrivateKeyParameters)keypair.getPrivate();
ECPublicKeyParameters pubParams = (ECPublicKeyParameters)keypair.getPublic();
this.priv = privParams.getD();
this.pub = pubParams.getQ().getEncoded();
this.creationTimeSeconds = (Utils.now().getTime() / 1000L);
}
So the random number generator used was: java.security.SecureRandom. This class provides a cryptographically strong random number generator (RNG).
A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1. Additionally, SecureRandom must produce non-deterministic output. Therefore any seed material passed to a SecureRandom object must be unpredictable, and all SecureRandom output sequences must be cryptographically strong, as described in RFC 1750: Randomness Recommendations for Security.
The implementation of SecureRandom is probably platform-dependant. Do we know the jvm/platform used to generate 1BTZ? if it was a collision, win for sure |
|
|
|
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? |
|
|
|
...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 |
|
|
|
|
Show Posts
