[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151207123255.GA2635@openwall.com>
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.
