Date: Wed, 14 Dec 2011 12:57:00 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: faster Lotus5 hash cracking (was: JtR CUDA ????) On Wed, Dec 14, 2011 at 10:13:23AM +0800, Gu George wrote: > I have tried to crack some Lotus Domino hashes by John-1.7.7-jumbo. I used > following command: .\john.exe --incremental -format:lotus5 > .\noCrackedHash_1.txt, BTW, there's a newer build for Windows here: http://openwall.info/wiki/john/custom-builds#Compiled-for-Windows As far as I am aware, it is not any faster at Lotus5 hashes, though. > and the benchmark is about 94508K c/s. I guess this is not the benchmark, but rather speed seen while cracking. It depends on the number of hashes loaded for cracking a lot. > I have > sucessfully carcked about 100 hashes in about 2 weeks, but there are about > 300 hashes which are not carcked. Sounds reasonable. > My PC has an Intel i7,8 core CPU@...z. You mean quad-core, 8 logical CPUs. > So, my question is: is there a more fast version of John-Ripper, such as > CUDA support? For this hash type, no. > I have checked http://openwall.info/wiki/john/GPU, it seems > current patches do not support Lotus5 format. That's correct. > Another question: Is it possible to configure John-Ripper to run more > faster in my PC? Yes: you need to run 8 instances of it in parallel, configured to try different candidate passwords and using different --session names. If doing this for 8 instances is difficult, then do it for at least 4 - e.g., you may split by length: http://openwall.info/wiki/john/parallelization#IncrementalAllN You can also try building with MPI support, but that's more difficult. I guess we should implement OpenMP parallelization for this hash type, but we haven't done so yet. Alexander P.S. Your reuse of the old thread for a mostly unrelated topic was in fact undesirable.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.