Date: Mon, 7 Dec 2015 15:32:55 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: hashcat CPU vs. JtR Hi atom, Thank you for your reply. On Mon, Dec 07, 2015 at 06:37:13AM +0100, atom wrote: > For me it's oclHashcat that counts Sure, and I agree. I started my message with "Most value of hashcat is in oclHashcat", and I started my tweet on the topic with "oclHashcat is the real thing". However, I felt that there got to be some value in hashcat CPU as well - in fact, I still think there may be cracking modes that we're missing. My comparison wasn't intended to diminish any of your results. Rather, it was to see what you have that we don't (e.g., efficient multi-threading for fast hashes is still one of those things) and to provide some info (and request more from the community) on when to use one tool or the other if running on a CPU. And yes, except for GPU-unfriendly hash types it is obvious that using a GPU is going to be faster, if one does have a GPU. Also, I intended to, but forgot to mention one possible reason why one may prefer to use hashcat CPU over JtR: if the person normally uses oclHashcat, they may be more used to hashcat's command-line options and exact feature set, so if they have to run on a CPU on some occasion, they may prefer to use hashcat for that reason. (For me, this currently works the other way around: since I normally use JtR, I may prefer to use JtR even if oclHashcat is faster for a given hash type. But now that you've open-sourced it, I think I need to find time and learn to use oclHashcat for what it does better.) > and which I've refactored completely > about 5 times till I found the architecture of today. Impressive. JtR didn't go through this many refactorings - there was just one major refactoring for version 1.5 in 1998. I certainly felt the need to refactor it again (some years ago), but we never got around to, proceeding with evolutionary changes only. > In theory, a pure CPU > integration into oclHashcat would be easy. Just add a new Platform, write > the basic macros and for each hash-mode write a function that uses the same > parameters as the OpenCL kernels do and simply copy/paste the OpenCL kernel > code. I did that once, just to find out if it would work, to end up with an > NTLM BF speed of over >900MH/s on my i7-4770K. That's impressive speed, indeed. Testing JtR's current AVX2 code on a i7-4770K (stock clocks), I get on one core: [solar@...l run]$ ./john -test -form=nt Benchmarking: NT [MD4 256/256 AVX2 8x3]... DONE Raw: 88371K c/s real, 88371K c/s virtual Running "-form=nt -mask='?a?a?a?a?a?a?a?a' -fork=8" against one NTLM hash gives 28.9M per process, so 231M total. Yours is almost 4 times higher. I attribute this difference to you doing NTLM step reversal, which we still mostly don't, and to you having a dumb brute-force mode, which we don't (mask is as close as we have). Sounds right, or do you think there's more that we're missing? Alain Espinosa reports comparable speeds to yours for Hash Suite (~500M on i5-4670; no results on i7-4770K to compare directly), but it's non-free (although its core's source code is open source under GPLv2+ via Hash Suite for Android). Both your results and Alain's remind us that we still have plenty of room for improvement for JtR on CPU. You might not care (since you rightly point out that GPUs are a lot faster anyway), but it is still a valid direction for JtR project - possibly even more so if your project is not interested in pursuing this direction. This would result in greater coverage of possible machines and use cases by our two projects combined (now that users can use hashcat and JtR interchangeably to a greater extent than before, due to hashcat becoming open source). > I'm really wondering why you even started to compare. I hope I've addressed this above. > Maybe you don't know, but many people mean oclHashcat when they > talk about hashcat, it's just an alias. That's why my long-term plan is to > add CPU support to oclHashcat, then obsolete hashcat and then rename > oclHashcat into hashcat. Sounds cool. I actually did know that "oclHashcat is the real thing", but I think that you're getting quite some new users now due to the announcement, some of whom are not aware. Some of them may genuinely expect hashcat CPU to run faster than JtR, without even checking whether this is in fact the case. And it actually is the case if they crack fast hashes with multiple threads, rather than slow hashes or/and with --fork, which my message also pointed out. Alexander
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.